migrate to Polymer 3
The following list reflects the findings so far that are necessary or advisable for a complete, extensible and scalable migration.
First a list of shortcomings with the firsts componentized version:
- we use a central dependencies-dev file to list all UI resources of the map. This means we are loading all or nothing which results in a rather large initial download
- the pubsub implementation has some issues or cannot fully cover our needs. We'll already decided to go for polymer-redux here
- by centralizing the import it is rather unclear what is actually depended
- the current version is not a single-page app which may lead to some complications with the toolchain (polymer-cli, modulizer etc.) which rather expects this pattern
move to best practices
Following practices are considered good practice when developing Polymer apps:
follow PRPL pattern to quickly load initial app, precache needed resources and lazy load optional routes.
use single-page pattern with routing for individual views
import dependencies in the respective component
use unidirectional data flow for view synchronization
dealing with third-party components
Third-party components must be upgraded to their respective Polymer 3 versions. There is NO way to make Polymer2 run in paralell with Polymer3.
If no updated version exists for a component we can decide wether to migrate it ourselves if no alternatives exist on webcomponents.org. Migrations might be contributed back as pull requests or we decide to host a fork ourselves.
polymer build step
The new resource loading with JS modules brings in 'named packages'. These are prefixed with '@' (e.g. @polymer). However these modules cannot be resolved by the browser at runtime. For this to work relative pathes with './' or '../' must be used. The modulizer can output the right pathes. However there are some pathes inside of Polymer itself that use the named module notation that will fail at runtime.
To circumvent this issue a single build step can be used to expand the references in @polymer module. However then the app must be served with that compiled version which would cause certain necessary adaptions of our current deployment (creation of xars, gulp integration).
An alternative might be the use of a specific controller.xql rule that matches all pathes starting with 'components/@' and redirecting those to 'components/node_modules/@[modulename]