Lion v1 release tracker

[jorenbroekema]

Breaking, must have

• Localize breaking change, refactors, message format lite (@jorenbroekema )
• Removal of Ajax package, use Fetch package (open PR by Lars) or Redaxios instead (@jorenbroekema )
• Form registrar/registration "hack" removed, use events (fake via sibling command node for IE11) (@daKmoR / thijs)
• Fix consistency issues in public APIs (@tlouisse )
• Popper v2 breaking change (@jorenbroekema / gerjan)
• Remove LionSingleton (in favor of just.. ES Modules)
• Change default lion-datepicker to be a dropdown, not modal (check w designers a lot) (@gerjanvangeest )
• Validator default message generic (at the moment, it's usually wrong..) (@tlouisse )
• Lit v2/v3

Not breaking but MUST have

• Types!
• General subclasser documentation + semver for subclassers (is breaking a protected method a breaking change?) (@tlouisse )
• Lion logo & landing page (@daKmoR / @jorenbroekema )

Not breaking but should have

• lion-combobox/listbox
• Move from lerna to changesets, move to github actions (@jorenbroekema )
• Move non-webcomponent related packages to a tools folder (@jorenbroekema )
• Change overlay config while opened (@jorenbroekema )

Finally

• Release v1 for all packages excluding perhaps individual packages like providence, babel plugin, remark-extend, etc.

[tlouisse]

I would suggest to do this one as well: #677 (small breaking change)

[tlouisse]

About styling and extending strategies:

We should definitely consider a solid styling strategy (consistency + separation of concerns in code):

See:

• [Feature Request] Make templates more extendable #591
• Implement Shadow Part #1137

More info:

• https://polymer.slack.com/archives/CJGFWJN9J/p1613585834017000
• https://polymer.slack.com/archives/CJGFWJN9J/p1616599080029100
• https://polymer.slack.com/archives/CJGFWJN9J/p1617042491047900
• Clarifications needed for creating a custom Tailwind version of LION. #1174
• ...all other style discussions

[tlouisse]

Another candidate: choiceGroup/child state management

• refactor how listboxes(maybe choiceGroups in general) and their children synchronize state. It's a bit hard to maintain, since there's a shared responsibility for maintaining state between children and parent.
  This leads to a lot of complexity and hard to solve bugs:
  [choice-group] check multipleChoice change detection #1028 (comment)

[tlouisse]

Another thing that should be fixed before V1: member order independence

See:

• [input-datepicker] formatter does not work for pre-filled inputs  #1349
• https://github.com/webcomponents/gold-standard/wiki/Member-Order-Independence
• https://github.com/ing-bank/lion/blob/master/packages/form-core/src/utils/SyncUpdatableMixin.js#L11

[tlouisse]

And another thing that should be fixed: hasChanged for synchronous property effects

• all synchronous change events and 'propery effects' should only run when hasChanged is true, just like in async property effects (updated() callback)

[abdonrd]

Lit v2 will be released today! https://github.com/Lit/lit

https://twitter.com/buildWithLit/status/1384572662979043335

[alangdm]

I have a bit of a question, is there any place where you are discussing what will be the upgrade policy for using Lit v2?

[tlouisse]

Yeah, controllers are pretty powerful indeed. The only thing that they don't allow for is adding overide hooks like _defineOverlayConfig() on the prototype, so we have to see how we will use them exactly (maybe our current mixins could consume controllers). Anything you would expect to see as a controller in particular?

[alangdm]

To be honest, I haven't really thought about specific examples of what could be controllers

The main reason for my question is that we're about to release versions for a library of components based on Lion 🎉 .

We're currently thinking of what kind of label to add to the version. So, knowing whether the external-facing API of lion components is going to have major changes or not would be a great point to consider there

[tlouisse]

First of all: always nice to hear you're building your component library on top of Lion 🙂

Personally, I don't expect mixins to be refactored to controllers before v1 (and if they are later, probably not fully), because we need them to put properties on the prototype (and that's exactly where they 'hit' the public api).

Having said that, we may want to do a normalisation/polishing on all public/protected apis. Things like:

• events: camelCase vs kebab-case, with or without '-changed' suffix, with/without bubble, with/without composed
• properties:
  • imperative or declarative naming for configurable boolean options?(hideOnOutsideClick vs hidesOnOutsideClick)
  • align where possible with platform? (opened -> open, serializedValue -> value)?
• read only: formattedValue, touched, dirty etc... (we already do this in OverlayController)
• ...?

But whether and how we do this will also depend on things like:

• what's the impact for consumers?
• will it be possibly to create a compatibility layer?
• can we create codemods?

[alangdm]

@tlouisse
Thanks for the detailed explanation, I think this solves most of my doubts about the release

[daKmoR]

this list is mostly done and the remaining breaking changes are pretty small... even the lit 2 migration will have hardly any impact unless you are heavily using lit directives.

So the only bigger breaking change that is still open is the localization system... we are still evaluating in which direction to go - but this will probably be something that is using a controller... potentially even @lit/localize as there are only a few missing features which we potentially could contribute

[jorenbroekema]

Hey guys, should we add the shadow parts discussion to this? #1137

TL;DR:

Expose everything as named shadow parts. Allow extenders to unexpose in an easy developer friendly manner

Use cases:

• For smaller projects, use lion-elements directly and just put some shadow parts styles, rather than extending the component and defining your own custom element, which can really feel like overkill
• For design systems that want to be less restricted in what styling their app/feature developers can adjust. Right now, such "freedom"/"flexible"-heavy design systems would either have to add lots of props and logic to support all these allowed adjustments or encourage their users to extend the components which is both not very ideal. Allowing most parts to stay exposed will be far easier on the design-system maintainers' side of things as well as on their users.

Exposing all these parts changes all the templates and allows users of lion-extending design systems to use those parts unless the extending design system opts out (unexposes) of the shadow parts. This is quite breaking so it would be nice to have this done before v1.