Importing modules

[cjorasch]

Stencil version:

 @stencil/[email protected]

I'm submitting a:

• bug report

Current behavior:
The current approach for handling module imports can lead to a number of problems during component rendering.

The eventual support for ES6 imports or dynamic imports will hopefully solve these issues, but, since it has been a long wait for them to arrive, I thought it was worth describing the issues to help make sure they are known.

The specific issues are:

• Large amounts of duplicated code.
• Invalid instanceof type guards.
• Inconsistent global state.
• Code import sequence errors.

Large amounts of duplicate code:

If components import anything from other typescript files then the code that is referenced gets copied into the component bundle. This even happens if you import an interface from a file that in turn imports from other library files.

For example, if you are building a CRM app you may have classes to represent Contacts, Accounts, Opportunities, etc. If you want to use these classes in components then all of the code comes with it. I was converting an existing Ionic app and simple components ended up with 10,000 lines of code because of a single reference.

If you are able to model everything so that only pure interfaces are needed (Redux, etc.) then this can be avoided but this is really the same as saying that you can't import any code into components.

Invalid instanceof type guards:

One subtle impact of duplicated code is that you end up with multiple instances of the same class each of which uses the same class name. This can lead to instanceof checks failing.

For example:

function formatShape(shape: Circle | Square) {
  if (shape instanceof Circle) {
    console.log('Circle: ' + shape.radius);
  } else {
    console.log('Square: ' + shape.size);
  }
}

If shape was created from another context with it's own definition of the Circle class then the initial check will fail (because it is a different implementation of Circle). This leads to thinking it is a Square and accessing members that are not available.

Inconsistent global state:

Imported code sometimes relies on variables that retain state. A simple example is a sequence number generator that increments a counter as it assigns new numbers.

If there are multiple instances of the code then each will have their own state and will generate overlapping sequence numbers.

This simple case could be handled by redux but you do not always control all of the code you are using so the only way to eliminate risk would be to import no code at all.

Code import sequence errors:

I have spent lots of time getting bit by this one, but, unfortunately, do not have a simple reproducible case.

The issue is that I am importing from a module which in turns imports other modules. In some cases the code that is inlined into the compiled component ends up with the modules defined in the wrong order. In this case the code fails (because later code has not yet executed).

[jgw96]

Hey! Thanks for putting this issue together! We are definitely aware of these issues and I have personally run into some of them in demos and tests I have built. We know it has been a long wait for ES modules support (which will solve the issues you describe) but we are getting very close and will not be releasing 1.0 until they have been implemented. You can follow this issue #162 to get all the updates I try to post regularly. The good thing is that the wait is going to be worth it as ES modules allow us to dramatically simplify the compiled web components the Stencil compiler outputs, simplify our automatic lazy loading, and allow us to ship even less code than we already do.