Polymerize v0.8.1 is out
Polymerize v0.8.1 is Out
A new version of
polymerize is out with many new features and changes under
More dart code less js
polymerize was generating a lot of
JS code and
html glue in order to
fix the gaps between the
@JS interop layer and what is needed to make dart DDC generated code work with
polymer version 2.x (like registration of elements and replacing the standard
html lib with
From this version the most code is generated in dart land and translated to JS by DDC. Only a few native JS library are kept
and used from dart by means of the
@JS interoperability layer.
This approach makes the code more easy to understand and to maintain and it ready to be used in the upcoming
A new package enters in the
polymerize family; it is
This package defines a few basic annotation that are common to any
@HtmlImport('rel/path/to/file.html')can be used to inject an html import in the final
htmlstub generated file. It can be used every where in the dart file : in the
librarydirective or in any top level declaration like
classor function declaration.
@initcan be used to annotated a function that you want to be executed at start time
Better module strategy
In the previous version a single
js file was generated for a whole package. Now a js module is generated for every
.dart file in your project or
This allow for a better control on what has to be dynamically loaded at runtime. Thus now using a singole component say in polymerize_elements will not
force you to load the whole
polymer_elements compoents but only those you are actually using.
Use of the real DDC
Now the current
dartdevc compiler that comes with the SDK is used instead of a library extracted from the git repository like in the
previous versions. This allows for a simpler and more transparent matching with the current SDK.
Workers for bazel !
polymerize uses the bazel workers protocol in order to speed up compilation. Some work needs to be done to improve because
at the moment a lot of memory is consumed by each workers forcing to kill them when they get to big (
bower in the workspace
In the previous version
bower was run as a
BUILD rule in the main
BUILD file. As Bazel doesn’t like rules that produces an unknown
number of outputs this was actually a dirty hack.
bower will define an external workspace and a
BUILD file will be created enumerating every asset that has to be part of the build.
This in turns need that if you want to force
bazel to recreate the
@bower external workspace from stratch you have to force a hard cleanup
of bazel (with
bazel clean --expunge).