-
-
Notifications
You must be signed in to change notification settings - Fork 49
XML Compatibility issue between NS-Angular and NS-Core #1121
Comments
As far as I understand, the plugin is trying to use the NativeScript Core I won't recommend you using the above-mentioned workarounds as they add some partial NativeScript Core support in the Angular apps of the end-users. I believe that the proper solution would be making the UI plugin itself Angular compatible, instead of trying to add a NativeScript Core view in Angular apps. I suggest you take a look at the Support Angular in UI Plugins and Integrating UI Components With Angular articles. |
@DimitarTachev - Go grab a cup of coffee; not sure you are all the way awake... 😀 (This is meant to be a joke! 😀 ) The page you linked to: https://docs.nativescript.org/angular/plugins/angular-third-party literally tells me to do exactly what my workaround is. 😀 Which is why I tried that workaround, because I've done enough plugins to have ideas what might be a potential cause/solution. 😀 Angular components are almost always just wrapped NS-Core components; sometimes they have extra pieces, but very frequently; it is just a simple registerModule call. There are no issues using NS-Core components in Angular, Vue, Svelte, or even creating and disposing of them dynamically. Now honestly, I don't know if this is something worth fixing, but it is a regression as it was something that used to work in NS < 6. But it is a corner case, and probably only a corner case a plugin would run into as if you are doing a Angular app; you won't normally be using the NS-Core builder to do things. But plugins might; and this is where the question of compatibility needs to be decided. |
@NathanaelA , I didn't get that you are doing the first workaround in the plugin itself. 😄 In the legacy workflow (before NativeScript 6.0 and without --bundle), we were copying all of the app files allowing any dynamic executions. Once we've migrated to the Webpack workflow, we had issues with the NativeScript Core applications because the dependencies between the different views/components were not easily analyzable - you are able to navigate, build a dynamic view or reference UI from plugins by using simple strings (without importing/requiring any modules). The reasons why we've not implemented a similar approach for the Angular apps are:
I will mark the issue as a feature request but bear in mind that it would be a risky change. |
Environment
Provide version numbers for the following components (information can be retrieved by running
tns info
in your project folder or by inspecting thepackage.json
of the project):CLI: 6.3x
Cross-platform modules:
Android Runtime:6.3x
iOS Runtime: 6.3x
Plugin(s): Creating one 😀
Please, attach your package.json and webpack.config.js: STOCK -- just generated the demo apps with latest CLI.
Callstack
Describe the bug
I have a plugin that has its own custom XML/JS that it uses when it loads a model (using showmodal) the plugin works great on NS-Core. Unfortunately on Angular the webpack config breaks loading and the parse of NS-Core xml files.
The issue is that XML is treated differently between Angular webpack config and the NS-Core; when I manually changed my angular webpack.config.js file to be:
Instead of both XML and HTML being raw-loader; my plugin will then work properly on Angular.
To Reproduce
builder.Builder.parse(require("./camera.xml"),...
So the xml is pulled into the bundle/vendorExpected behavior
The plugin to work on all platforms equally well. 😀
Sample project
Need to check with client if I can share....
Workarounds
manually do this first:
global.registerModule("@nstudio/nativescript-camera-plus", () => require('@nstudio/nativescript-camera-plus'));
Before I call the
Builder.parse
function -- apparently the difference between the two webpack building methods; is the registerModule / namespaces are NOT discovered/added under angular; but they are added under NS-Core.The other work around is to switch xml-loaders; but I can't expect clients to do that, and not sure the side effects it will cause for Angular apps using XML screens rather than html screens.
The text was updated successfully, but these errors were encountered: