Decorator Roadmap

[justinfagnani]

No description provided.

[rictic]

Looks great! A few comments, the only serious one is about context

[AndrewJakubowicz]

Nice! Just some minor clarifying comments.

[augustjk]

Minor suggestions. Overall LGTM.

[AndrewJakubowicz]

Thank you @justinfagnani! Applied your changes.

Also ignore the failing CLA. It is not able to figure out personal GitHub emails.

[augustjk]

Fixed CLA issue by amending commit and force pushing

[justinfagnani]

LGTM on allo changes!

[sorvell]

I think this should be updated based on the review of lit/lit#4895.

[justinfagnani]

@sorvell what needs to be updated? This mentions the plan of record that lit/lit#4895 implements, which is to use property options: https://github.com/lit/rfcs/pull/20/files#diff-a406be4bc64f6899edff250e261c51903172e65fe84a676f1dcac6c63c153dbaR119

[sorvell]

what needs to be updated?

Nice, I missed that part.

[maxpatiiuk]

Excited for this change - thanks for the continuous improvements!

The code size of components needs to be investigated since the TypeScript emit for standard decorators appears to be larger than experimental decorators. We might want to point this out and not recommend them as the default until browsers ship natively.

Regarding bundle size:

• These helpers can be externalized from each file (even from the package) using the following:
  • add noEmitHelpers:false and importHelpers:true to your tsconfig.jaon
  • add tslib dependency (not dev dependency) to your app/library package.json
  • This way, all runtime helpers are externalized into the tslib package, ensuring they are included only once in the final build, rather than once per package!

Add a non-core utility library that can dynamically create reactive properties

Very interested in this - could you provide more details on how that may look like and what the tradeoff is?

For reference, this is what we are doing at build time at present:

• Replace all @property() and @state() decorators with static properties - this way we don't need to ship decorators polyfill
  • This reduced the minified CDN build size in a package with 50 components from 398kb to 364kb (34kb!)
• To further improve bundle size, rather than declaring options as an object, the build plugin convers them to a very compact representation:

   static {
     this.properties = { autoDestroyDisabled: 5, capabilities: 0, displayType: 1, graphic: 0, hideAddButton: 5, hideAddSubmitButton: 5, hideCancelAddButton: 5, hideCancelUpdateButton: 5, hideDeleteButton: 5, hideErrorMessage: 5, hideProgressBar: 5, hideUpdateButton: 5, icon: 1, label: 1, position: 1, referenceElement: 1, state: 3, submitting: 4 };
   }

• We overwrite LitElement.createProperty to decode those compact numbers back to options objects. This is done using a typescript enum like this:

   export enum PropertyFlags {
     // Ordered based on frequency of usage to keep flags as short as possible
     ATTRIBUTE = 1 << 0,
     REFLECT = 1 << 1,
     BOOLEAN = 1 << 2,
     NUMBER = 1 << 3,
     STATE = 1 << 4,
     // Not part of vanilla Lit - added by us
     READ_ONLY = 1 << 5,
     // Inverted so that the more common case is "false"
     NO_ACCESSOR = 1 << 6,
   }

  • This further reduced our build size from 364kb to 354kb (7kb smaller, even after you count the code for decoding compact options)
  • Rarely, additional options need to be specified, which are encoded as a numbrer-object pair: [0, {converter: ... }]
  • Stencil is doing the same: https://github.com/ionic-team/stencil/blob/a7d38735a8572303fa2ea7e154e9a9dc3bf7eecb/src/utils/constants.ts#L1

Obviously, once static properties goes away, we will look for another solution for declaring properties in a very bundle size efficient way.