Deck.gl fails to initialize when run with AOT compilation with Angular #3567
Comments
|
I suspect that this has to do with tree shaking again. Is there a way you can inspect the compiled code to see if https://github.com/uber/luma.gl/blob/master/modules/webgl/src/init.js#L8 |
|
I like the clean example... If we get this example working, maybe it could be contributed as a |
|
@Pessimistress @ibgreen |
|
Looks like the default export of this file: https://unpkg.com/browse/@luma.gl/webgl@7.2.0/dist/esm/features/webgl-features-table.js is an empty object in prod mode. I replaced the transpiled code with source and it worked. @SterlingMcCall are you able to resolve modules to the es6 end point ( |
|
I'm not really sure what you are asking me to do in I did try changing all the |
|
@SterlingMcCall It's not going into your own package.json, but your compiler configuration. I'm not familiar with Angular so I can't say what exactly you need to change. In webpack it's documented here: https://webpack.js.org/configuration/resolve/#resolvemainfields |
|
@Pessimistress Thank you for the clarification. with the default angular webpack configuration worked and deck.gl now loads correctly. Is this the solution or is this more of a work-around? Do you know if this impacts browser compatibility? For anyone else in the same situation, I followed this article on how to modify the angular webpack config. I also pushed a new branch ( |
|
@SterlingMcCall The es6 distribution is the most compact and provides the best performance and debugging experience but it achieves this by intentionally limiting browser compatibility. It is built with babels preset-env with the following settings; https://github.com/uber-web/ocular/blob/master/modules/dev-tools/config/babel.config.js#L5 const ES6_TARGETS = {
chrome: '64', // Released: 2018-Jan-24, https://en.wikipedia.org/wiki/Google_Chrome_version_history
edge: '18', // Released: 2018-Nov-13, https://en.wikipedia.org/wiki/Microsoft_Edge
firefox: '60', // Released: 2018-May-9, https://en.wikipedia.org/wiki/Firefox_version_history
safari: '12', // Released: 2018-09-07 (OSX Mojave) - https://en.wikipedia.org/wiki/Safari_version_history
ios: '12', // Track Safari
node: '8' // Node 8 is LTS until December 31, 2019.
}; |
|
@ibgreen But if I'm resolving dependencies with esnext instead of es6 wouldn't it potentially be even more restrictive? |
|
No, we define the We should probably rename the |
|
@ibgreen I see. Is it possible to configure webpack to only resolve the esnext mainField for deck.gl and its dependencies like luma.gl? |
|
I don't know of any way to do that, however I also don't know of any other modules that expose the I guess technically we could add a unique entry to our package.json files (something like You could also run babel on our packages and transpile them further to your taste by modifying the |
|
The above discussion aside, ultimately we should fix your tree shaking issue, we just need to understand it better. To facilitate having folks here play around with this, I think we should just add your example in its current working state to Would you consider putting up a PR? If we can get it working well we could move it to |
|
@ibgreen Do you want me to make a PR for the working version with the modified webpack config or the non-working version? And my example is specific to Google maps, and more specifically uses the Angular Google Maps library to make it easier to integrate the map with Angular bindings, so it's not the most 'pure' implementation of Deck.gl with Angular. Does that matter? |
The main concern would be maintenance of this setup. As you probably know, we did have to do a lot of work to get google maps to integrate well with deck in our own google-maps module, here we need to deal with two complex, evolving dependencies: angular and angular-google-maps. But we could mark the angular example as a contributor-led effort. We can provide assistance but do not guarantee to keep it working for every new version of angular and angular-google-maps. A good README in the example summarizing some of the key takeaways from your integration effort would be most appreciated. FYI @donmccurdy |
|
@ibgreen I've been using the Angular Google Maps library for over 2 years and it's maintained relatively well. Plus, google doesn't make breaking changes to their maps library so I wouldn't be concerned. As far as integration efforts, it was hardly an effort. I was able to display test data over my existing application in about 20 minutes from first reading the deck.gl documentation. Due to the fact that Deck.gl operates independently of the Angular context, I can't image new Angular versions breaking compatibility with the exception of the build process. I can clean up the demo and submit a PR today or Monday most likely. |
|
@Pessimistress After further exploration in trying to make a clean demo, I discovered that it was not the custom webpack config with the modified Without modifying the default settings used by Angular 8, deck.gl works just fine. @ibgreen I can still work on contributing an example Angular 8 app, or the still broken Angular 7 app I originally created so that this bug can potentially be fixed for compatibility with older versions of Angular, and possibly prevent the incompatibility from being re-introduced. However, upgrading to Angular 8 seems like the most simple solution for those able to perform the upgrade. |
That is great news.
Let's go with v8! Given that we are just starting to explore Angular support in deck.gl, I would focus on the latest, working version, i.e. v8. and mention in a README file that older versions have issues. Later, if there is a huge uptake of angular users, and a lot of those users can't upgrade to Angular v8 for some reasons unrelated to deck.gl, we could always revisit this and try to create a working example for v7. |
Okay. I noticed most of the apps |
|
Good question. I'll let you make the call, but will say:
In my mind, it is not really deck.gl's job to show Angular/React etc best project scaffolding practices, though if 99% of Angular users are using this scaffold and it is hard to get it working with deck.gl based on a minimal example, then it could make sense. For instance, a lot of React users use |
|
I'm getting a similar issue with our Angular app while pushing to our Dev and Test environments. The app loads the map and displays layers while serving app locally. But when we push code to dev and test i'm getting reference error and blank page. Looks like it's being called from luma.gl. We are on Angular v7. Is it the best solution to upgrade to v8? I do not see any of the Angular demo apps within the 'Test' or 'Examples' repo.
|
|
The workaround for my issue is to switch aot and buildOptimizer to false in angular.json file. |
|
@lovanva When I upgraded my app from angular 7 to angular 8 the issues I had with with AOT compilation and deck.gl were resolved. I can't imagine you would want to run your app in prod without the AOT or build optimizer enabled as a long term solution, so upgrading to 8 would be worth a try if it's an option. |
Description
I am using the Deck.gl GoogleMapsOverlay with a Google map in an Angular application. It works just fine with the JIT compilation used most commonly by angular during development, but when the application is run with AOT compilation w/ Webpack as one would in a production environment, the resulting bundles don't load deck.gl correctly and all I see is the default google map. I believe it may be a treeshaking bug similar to #3213.
My current work-around is to load it via the CDN link (https://unpkg.com/deck.gl@latest/dist.min.js) but that increases the bundle size considerably and breaks all IDE code suggestion support and whatnot.
Repro Steps
I created a simple angular project which demonstrates the issue. Refer to the README to get running quickly.
https://github.com/SterlingMcCall/angular-deck-gl-error-demo
Environment:
Logs
The text was updated successfully, but these errors were encountered: