Home Development of Websites Using vulcanization for polymer modules

Using vulcanization for polymer modules

by admin

Using vulcanization for polymer modules
The project I’m working on now has a widget-like client architecture.And the system widgets can use any library for their implementation, such as ReactJS, PolymerJS, VueJS, d3JS and others.Some of the widgets in the system are implemented as web components based on PolymerJS
So here is one approach for optimizing polymer widgets.

Contents :

1.Description of the problem
2.What are some of the difficulties that arise?
3.How can they be solved?
4. vulcanize-polymer-module library
4.1. Structure
4.2. Description of bower.json
4.3. package description.json
4.3.1. Installing utilities
4.3.2 Setting up RollupJS
4.4. vulcanize-utils.js
5. Conclusions

1. Description of the problem

One of the main problems of polymer applications is the multiple loading, the components used and all the dependent components, which in turn can consist of auxiliary styles, behaviors which are also loaded additionally. As a result, the console in the network partition will be "flooded" with these files. In view of all this, the first loading of this widget can be quite long, depending on the number of used compound web-components.
Polymer applications use curing for this purpose. It is implied that a given application, has an entry point in the form of e.g, index.html where the main component-container is deployed, e.g. <App/> In this file, the polymer core itself and the container component file are connected <App/> and then hierarchically connect all used components, which themselves are separate html-files. The vulcanization process itself consists in "gluing" all used components and the polymer core into one file, which will eventually be the entry point for index.html

2. What difficulties arise?

  1. The first difficulty is that I don’t have a polymer application, but several composite components(let’s call them smart components – CC)that are wrapped in a system widget, which means there is no single entry point.
  2. The second difficulty is that during work with the application you may not call widget page at all, and therefore none of polymer components will be simply not needed in current session, not to mention the core polymer itself.
  3. The third is that one UC uses one set of atomic ( paper- , iron- and others)components(let’s call them silly components – GCs)and another set. And there may be overlaps, that is, two different CC use the same GC

3. How can they be solved?

If you consider the first difficulty, I could vulcanizeeach one separately CC , but then if you take the third problem possible duplication of the same GC , and there will definitely be a duplication of kernels if you consider a situation where at least two UK Therefore, another solution is needed.
If we consider the second difficulty, we need to make the core polymer and GCs loaded only once, the first time one of the UK , and at the time of accessing the second one, there is no need to reload everything, but only to load dynamically the UK
If we consider the third difficulty, we need to make a list of all the silly components used in the smart ones, which we will eventually vulcanize along with the polymer itself.

4. vulcanize-polymer-module library

All the above mentioned theses I formulated in the form of vulcanize-polymer-module library.
I want to tell about it in details.

4.1. Structure

├── imports.html
├─ vulcanize-utils.js
├── rollup.config.js
├── bower.json
└─ package.json

4.2. Description of bower.json

In it, we describe all the GC that we need as dependencies, including also the polymer core itself.
For example, section dependencies might look like this :

 "dependencies": {"polymer": "Polymer/polymer#^2.0.0", "polymer-redux": "^1.0.0", "iron-flex-layout": "PolymerElements/iron-flex-layout#^2.0.0", "paper-button": "PolymerElements/paper-button#^2.0.0", "paper-badge": "PolymerElements/paper-badge#^2.0.0", "paper-icon-button": "PolymerElements/paper-icon-button#^2.0.0", "paper-input": "PolymerElements/paper-input#^2.0.0", "paper-item": "PolymerElements/paper-item#^2.0.0", "paper-checkbox": "PolymerElements/paper-checkbox#^2.0.0", "paper-tabs": "PolymerElements/paper-tabs#^2.0.0", "paper-listbox": "PolymerElements/paper-listbox#^2.0.0", "iron-a11y-keys": "PolymerElements/iron-a11y-keys#^2.0.0", "iron-list": "PolymerElements/iron-list#^2.0.0", "iron-icons": "PolymerElements/iron-icons#^2.0.0", "paper-progress": "PolymerElements/paper-progress#^2.0.0", "vaadin-split-layout": "vaadin/vaadin-split-layout#^2.0.0", "vaadin-grid": "^3.0.0", "iron-pages": "PolymerElements/iron-pages#^2.0.0", "iron-collapse": "PolymerElements/iron-collapse#^2.0.0", "iron-overlay-behavior": "PolymerElements/iron-overlay-behavior#^2.0.0", "vaadin-context-menu": "^3.0.0"} 

Since I use redux in conjunction with polymer, I have included the library polymer-redux

4.3. package description.json

Here we have the dependencies we need to build, such as RollupJS which is used for intermediate cleanup of the output file code. The commands used for curing are also described, let’s take a closer look at them.

 "scripts": {"build": "rollup -c", "vulcanize": "vulcanize imports.html --inline-scripts --inline-css --strip-comments", "run-vulcanize": "npm run vulcanize > imports.vulcanize.html", "vulcanized": "vulcanize imports.html --inline-scripts --inline-css --strip-comments | crisper --html imports.vulcanized.html --js imports.vulcanized.js > imports.vulcanized.html", "html-minifier": "html-minifierimports.vulcanized.html --remove-optional-tags --collapse-whitespace --preserve-line-breaks -o imports.vulcanized.min.html", "build-all": "npm run vulcanized npm run build npm run html-minifier"} 

Commands, in order and priority of their use :

  • build-all – is the main command that starts the whole vulcanization process.
  • vulcanized – performs the vulcanized itself, that is, combining all the components and the core into one file, then splits the entire assembly separately into .js and .html files. vulcanize and crisper )
  • build – clearing the code of the js file from comments.(used RollupJS )
  • html-minifier – html-minifier.(uses html-minifier )

4.3.1. Installing utilities

As you can see there are a lot of additional utilities that we need to install to the system first.
Installing utilities

npm install -g vulcanizenpm install -g crispernpm install -g html-minifier

4.3.2 Setting up RollupJS

Since rollup is only used to clean the js-code I use only one plugin for it- rollup-plugin-cleanup Plugin rollup-plugin-progress is used to visualize the build process.

import progress from 'rollup-plugin-progress';import cleanup from 'rollup-plugin-cleanup';export default {entry: 'imports.vulcanized.js', dest: 'imports.vulcanized.js', plugins: [cleanup(), progress({}), ]};

4.4. vulcanize-utils.js

To solve the second requirement, a utilitarian method was written loadVulcanized which loads UK , but before that it loads the vulcanized file, and it does this once and in case of a repeated call it loads only the UK
Let’s take a closer look at its parameters.
loadVulcanized = function(url, urlVulcanized, controller, html, store)

  • url – The path to the smart component. Is mandatory.
  • urlVulcanized -path to the vulcanized assembly. The default path to this assembly is /vulcanize-polymer-module/imports.vulcanized.min.html
  • controller – In my case, it is a system widget controller. Optional.
  • html – The html object of the smart component. Makes sense if a controller is specified.
  • store – redux store. Optional.

5. Conclusions

Of course you can use polymer-cli with the parameter build but building with it assumes that a polymer project is being built, and since we use components in more than one container <App/> then we have to build each CC separately and the build files will have a duplicate of the polymer core and composite GC Therefore, the approach described in the paper has sufficient efficiency in systems using several UI libraries together, due to a single entry point for all polymer-based GCs.
One possible disadvantage can be considered as redundancy GCs in the vulcanized file, because it contains all GCs of all GCs used in the system, but not all GCs can be used during the session of work, which means that not all GCs will be used in the downloaded vulcanized file.
Also as a small inconvenience, you can consider the fact that after adding a new component, you have to restart the build and then do a repository update(push), and other users have to update this library via bower update.
In spite of all this this library solves its task in this project, which means it can be useful for someone else.
So what fork out , welcome.

You may also like