First Lit & Friends Community Call!

[justinfagnani]

Hello friends,

We're excited to announce our first ever Lit & Friends Community Call next Thursday 6/9 at 9:30am PDT on Google Meet! Please join members of the Lit team to talk about all things Lit and web components.

Agenda

As this is our first community call, we don't have a set agenda yet. We may discuss recurring agenda items and overall structure at the first few calls. If you want to discuss something specific, please add the idea in a comment below.

Topics don't need to be limited to Lit, though they should be relevant. They may include web component standards, tooling such as Open WC, and more. We will prioritize existing open issues, pull requests, and discussions in the Lit repo, and address other topics time-permitting.

Info

Lit Community Call
Thursday, June 9 · 9:30 – 10:30am

Google Meet joining info
Video call link: https://meet.google.com/zas-osqa-rmi
Or dial: ‪(US) +1 253-289-7019‬ PIN: ‪155 520 209 14‬#
More phone numbers: https://tel.meet/zas-osqa-rmi?pin=7351877644603

Code of Conduct
This call is covered by our Code of Conduct

[UserGalileo]

Hi guys! Great idea! :D

I don't know if I'll make it in time, so just in case, I'll leave here a summary of my other discussion about forms :)

A new package for Forms?

It'd be great to have a dedicated package for forms.

Some of the features it could have:

• 2-way binding between Model and View
• Field states (dirty, touched, blurred...)
• Field disabled states
• Imperative manipulation via JS (setField, patchValue, enable, disable, setDirty...)
• Listeners
• Configuration options (eg. updateOn input vs blur)
• Dynamic forms (arrays) with methods to move/insert/push/remove...
• A substitute (or directive?) to intercept submissions and handle async tasks with fetch (could allow Progressive Enhancement similar to Remix?)
• Validation:
  • Synchronous and Asynchronous validators with pending state
  • Cross-field validations
  • Dynamic validators (setValidators(...))
  • Schema validation (eg. yup)
  • a11y best practices (eg. automatic HTML attributes for required, minlength...)

Forms handling comes in many flavors depending on the framework or the library: which way should we choose?

1. Template-driven

With this variation, the source of truth would be the template itself, but with additional info stored in a Controller (or Directives?). This approach would be similar to React Hook Form.

With this approach, it's the template that dictates whether or not to add a field to the model.

Example:

form = new Form<User>(this, {
   ... // config
});

<form>
  <input type="text" ${this.form.bind('name')}>
  <input type="text" ${this.form.bind('surname')}>
  <button>submit</button>
</form>

<!-- Or perhaps even... -->
<form ${this.form.bind()}>
  <input type="text" name="name">
  <input type="text" name="surname">
  <button>submit</button>
</form>

Accessing/Manipulating the form:

// Properties
this.form.value 
this.form.dirtyFields
this.form.touchedFields
this.form.blurredFields
this.form.disabledFields

// Methods
this.form.setField(key, value);
this.form.patchValue(partialFormValue);
this.form.reset(key?);
this.form.setDirty(key, isDirty);
this.form.setTouched(key, isTouched);
this.form.setBlurred(key, isBlurred);
this.form.disable(key);
this.form.enable(key);
this.form.valueChanges(key?): Observable

Advantages:

• Easy and straightforward for simple forms
• Feels closer to the standards: could allow for Progressive Enhancement a-la Remix in the future

Disadvantages:

• Type-safety can very much be an issue
• Much worse DX with complex forms
  • Think about how React Hook Form handles simple arrays: https://react-hook-form.com/api/usefieldarray
• If we want to support nested fields, we would have to introduce conventions such as a dotted syntax (user.name). However, at this point there couldn't be Progressive Enhancement since native forms don't allow nested values... So no nesting?
• How should we handle validation? A lot of devs (myself included) are not satisfied with a native approach. We could leave this part in user-land or provide some API, but again, what about Progressive Enhancement? The form could be sent to the server in an invalid state.

Summary: this would be the easiest approach and the closest to the platform, but I'd personally never use it in practice.

2. Model-driven

With this approach, the source of truth is the model and we just bind our controls to existing fields.

form = new Form<User>(this, {
  // Mandatory!
  defaultValues: {
    name: '',
    surname: '' 
  }
   ... // config
});

<form>
  <input type="text" ${this.form.bind('name')}>
  <input type="text" ${this.form.bind('surname')}>
  <!-- Error! TypeScript will tell us there's no "city" -->
  <input type="text" ${this.form.bind('city')}>
  <button>submit</button>
</form>

Advantages:

• Type-safe
• The model is predictable and the value doesn't depend on what's inside the template
• Could allow for some cool behaviors (such as binding 2+ controls to the same key)
• No Progressive Enhancement could mean we can validate the form however we want before sending the value to the server

Disadvantages:

• A bit more code required
• Disambiguating the difference between values can be an issue, examples:
  • []: is it an array of controls or a <select multiple>?
  • { city: '', street: '' }: is it a nested group or a custom control which accepts an object?
• No Progressive Enhancement if we don't trust the template

3: Model-driven, with explicit API

With this approach, we accurately describe the shape of our forms with appropriate APIs. It'd be inspired by Angular's Reactive Forms.

fb = new FormBuilder(this);

// Could be made easier if all we want is a control with a default value, like: `name: 'Michele'`
form = this.fb.group({
  user: this.fb.group({
    name: this.fb.control('Michele'),
    surname: this.fb.control('Stieven'),
    gender: this.fb.control<'M' | 'F'>('M'),
  }),
  agreement: this.fb.control(false),
  phones: this.fb.array<FormControl<string>>(),
  addresses: this.fb.array<FormGroup<{
    street: FormControl<string>
    nr: FormControl<string>
  }>>()
});

Advantages:

• You can do pretty much anything
• You don't need a FormGroup? Use a standalone FormControl. Same with FormArray.
• Clear and explicit: no issue disambiguating array values, nested values, custom controls...
• Fully type-safe (you cannot bind to non-existing fields, you cannot remove or add non-optional fields...)

Disadvantages:

• No Progressive Enhancement
• More verbose

This is one of my experiments, just to verify that this solution is working fine with Lit (seems to work great, but it's using RxJS internally for my convenience). Feel free to clone the repo, run npm i and npm run dev and you'll see a working example. This is the main file for the demo.

I tried to play around with Validation (both synchronous and asynchronous), custom controls and other stuff.

Summary

The team should decide if:

• It makes sense to have an official package for forms
• If yes, which road to follow

My personal favorite is of course the last one but I get it if it's too divergent from standards: if so, it'd be great to have a 3rd party lib (maybe without the RxJS dependency), I'm not a library author and I don't have the time (and experience) to maintain one, I put together some code to make sure it's viable but I pretty much stop here.

Also there are points which should be discussed that I don't feel comfortable deciding for myself, such as:

• External Validation vs Native Validation
• Asynchronous Validators: should they run if the field is already made invalid by a synchronous validator? (that's the case with Angular but it's a strange quirk)
• Should we include disabled fields in the final value?
• Would readonly be part of the API? In my experiment, it is, but since not every control allows that attribute, I've made some arbitrary decisions
• Etc...

It's a hard topic which I think could be best discussed by the team of great minds behind Lit :)

[daKmoR]

There is some existing prior art as far as I know...

• Based on the element internals https://github.com/open-wc/form-participation
• INGs form system with validation (angular inspired) https://lion-web.netlify.app/fundamentals/systems/form/overview/

maybe more?

[UserGalileo]

@daKmoR What I had found when I opened that discussion was the Vaadin solution, which IIRC is more Model-oriented but didn't fully convince me.

The first link is about native custom controls, which is awesome but it's a different thing which could be used as a plus

The second one... wow I didn't even know that Lion provided something like that!! I'm pretty much stunned. I don't know how I missed that since I've looked at Icons and Localize which are on the same page!

That's very similar to Angular's Template-driven forms. Although it uses wrappers so from what I see you don't get to work with native controls directly most of the times (reminds me of React's Formik), but that's just a different flavor. Very very cool, I'll give it a shot and actually this could very well obsolete my discussion if it works well :D Template-driven approaches never fully convinced me but if it works well that's awesome.

PS. Although none of the solutions I've found so far worry about Progressive Enhancement, which is what I wondered if the Lit team would like to invest on, even if I practically don't care about it at all cause it poses a lot of challenges

[lukaskoeller]

I would be interesting in hearing more about the integration of lit components into different frameworks like react, svelte etc. What is the best way to do that? What things to consider?

(E.g. I am experiencing an issue where components are mounted slightly later to my sveltekit app causing layout shifts since I am loading them async (not doing that leads to a window not defined reference error))

[justinfagnani]

We've been working on related things recently. If you join, I'd love to hear more about the window not defined error you're hitting.

[justinfagnani]

We've talked on the Lit team a bit about whether we should start up an RFC process. It'd be great to hear thoughts on this from people!

[justinfagnani]

Thanks everyone who joined! We had over 50 callers on our first call, wow!!

We'll schedule the next call soon, probably for about a month from now. Hopefully we'll have some updates on an RFC process, and we'll try to poll the community to see what the best times are for everyone too.

[kevinpschaaf]

Posting a slightly cleaned up version of minutes from the meeting today. We'll aim to take better notes in future calls!

• Current Lit team priorities
  • We track our work on the github lit project board - check here for our current focus areas
• WC wrapper discussion
  • @lit-labs/react wrapper: Expose named slots as props? (from Benny Powers)
    • Work in progres for this in [@labs/react] support multiple children with multiple slots #2985
    • We could also consider adding slotted content constraint types to the /** @slot */ annotation
  • @lit-labs/vue: Above discussion also overlaps with better typing for event 'payloads' in the vue wrapper (docs)
• @lit-labs/analyzer
  • This is being built out to support a number of use cases (framework wrapper generation, custom-elements.json (CEM) generation, linting, etc.)
  • What is the status of template analyzer?
    • Will likely extract template analysis out of @lit-labs/ssr into a standalone package (or as an API of the analyzer)
  • Lit team is taking over maintenance of lit-plugin, etc.
    • Will likely converge / use @lit-labs/analyzer over time
  • Over time, want to see other framework-specific analyzers consuming custom-elements.json manifests for dependencies
• CEM-based documentation
  • Could there be a standard viewer?
  • lit-element-starter kits have 11ty-based generators
  • open-wc's api-viewer-element set is a good building block for this
• Introducing an RFC process
  • Lit team considering adding formal RFC process to improve the community suggestion / contribution process
    • The forms discussion would be a good first candidate for trying out an RFC process
    • Details on this forthcoming
  • Should also consider adding an RFC process for polyfills also
    • Also considering logistics of moving ownership of webcomponents org to Web Components Community Group
• App-building helpers
  • Comment: Things like @lit-labs/context and @lit-labs/router are important to complete the story around building apps with web components
  • The Lit team is interested in incrementally building up primitives for app building where we can provide the most value (as opposed to immediate work on a full top-down opinionated app kit)
  • We intend to start discussion threads for each labs package for soliciting feedback, gauging interest / usage, blockers, etc. to help prioritize work in this area

[robrez]

Any chance of a VOD?