Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using axLazyElement with differential builds #71

Open
gs-smuthyam opened this issue Dec 17, 2020 · 6 comments
Open

Using axLazyElement with differential builds #71

gs-smuthyam opened this issue Dec 17, 2020 · 6 comments

Comments

@gs-smuthyam
Copy link

Hi There,

This is more of a doubt rather an issue.

Does the lib support loading of a element which is built using differential build? If yes, is there an example which we can refer to ?

@tomastrajan
Copy link
Member

Hi @gs-smuthyam ! So differential build produces multiple JavaScript bundles right ? So out of the box you have to provide url for your element so you will point only to a single bundle. You could try to point to both and use module: true for the modern one.

Don't remember what is the exact exclusive <script> tag syntax to execute only one and not the other based on browser feature support.

If current state of things is not enough additional flag could be added.

@gs-smuthyam
Copy link
Author

Hi @tomastrajan

Thank you for the reply, will try adding both as you mentioned and update here. But the code appears to be loading them independently as I can see in the code

@tomastrajan
Copy link
Member

@gs-smuthyam yes, but that also how angular differential loading works, right? It adds two sets of script tags to index.html and only one set gets executed based on browser feature support.

The only question that remains is if the lib constructs mutually exclusive script tags for module: true vs false currently and if not, what is still missing and should be added (will be enabled with additional flag, eg differential: true ).

@gs-smuthyam
Copy link
Author

gs-smuthyam commented Dec 28, 2020

Hi @tomastrajan,

Yeah the build constructs main-es15.js & main-es2015.js and in browser the script tags would be

<script src="main-es2015.js" type="module"></script>
<script src="main-es5.js" nomodule></script>

So below are possible options to choose

  1. Accept a collection of scripts (JSON) <stcript, module/nomodule>[]

  2. Based on the new flag (differential: true), identify the browser & intelligently rename the script file and load only that. Personally, I would not prefer this approach since this will make things dependent on the library.

Currently to solve our product flow, we are going ahead with this approach as a workaround. Check the browser type and load the appropriate script file.

@tomastrajan
Copy link
Member

Hi @gs-smuthyam !

So currently the "problem" is that lib does NOT use nomodule for module: false (which is default) so if two urls are used then both elements will be loaded.

How about this?

<my-element *axLazyElement="url-es5.js; nomodule: true"></my-element>
<my-element *axLazyElement="url-es2015.js; module: true"></my-element>

That way it's fully explicit and can be documented as a technique to use differential loading?

@gs-smuthyam
Copy link
Author

Hi @tomastrajan,

We can try out this. If we can make this work, this would be awesome. Indirectly it is same as the one proposed in previous comment ( being able to load multiple script files which user mentioned )

However, I'm afraid, this might not work especially imagine we are dealing with a dashboard where you have number of widgets in place and each of them are identified with unique #id. The moment we add two lazyElements the lib code would try to identify the tag with unique name and will find ambiguity.

I have tried with using multiple elements as you mentioned in modern browser, however ran into tag / unique name ambiguities. So ended up with evaluating and keeping only one axLazyElement by evaluating the browser for the time being.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants