[RFC] Integration with Lit

[ChrisShank]

There have been some discussions in the Discord with integrating xstate with the new lit package. @santicros has created a prototype using Lit’s ReactiveController. We were thinking of making a new package called @xstate/lit that would have similar feature parity to the other component packages.

One important thing to note is that the lit team is exploring making ReactiveController adapters for other frameworks so over time this package could end up providing xstate with first class support with many other frameworks (that are not already supported) for free!

Happy to hear your thoughts and/or concerns!

[justinfagnani]

This is awesome, and the controller is so simple! :)

I haven't yet used XState or other state machine libraries for building components, but it makes a ton of sense.

One thing I've wondered about, and I'd be very interested in seeing if XState integration could help with, is how to use XState to ensure that a component has well-defined behavior even when it's public interface is made of up independent properties. Mapping state to property getters seems relatively straightforward (I think!), probably same with mapping events to send() and at least pameterless methods to send(), but mapping property setters and methods with parameters to send() seems quite a bit more complex. Built-in element examples include script where src, type, defer, async and several other properties are co-related and whose changes cause certain actions.

One not on the prototype is that I'd recommend against hook-style naming like useMachine. Controller aren't restricted by the rule of hooks and linters could give false warnings on names like that. That controller is a class and would typically have a capitalized name, like MachineController. Controllers don't have to be classes though and/or you can have a factor function like _toggleMachine = connectMachine(this, toggleMachine);

[ChrisShank]

One thing I've wondered about, and I'd be very interested in seeing if XState integration could help with, is how to use XState to ensure that a component has well-defined behavior even when it's public interface is made of up independent properties. Mapping state to property getters seems relatively straightforward (I think!), probably same with mapping events to send() and at least pameterless methods to send(), but mapping property setters and methods with parameters to send() seems quite a bit more complex. Built-in element examples include script where src, type, defer, async and several other properties are co-related and whose changes cause certain actions.

I think the key with xstate is that everything outside of the state machine is an event. For example, when a property/attribute is updated that should translate to a certain event being sent to the machine. So I imagine that the willUpdate lifecycle hook will map the changed properties/attributes to an event (or events) sent to the state machine. ( Please note I haven’t used lit to deeply yet so I'm happy for any pointers here). If you have a good example of an lit component I am happy to try to refactor it so the behavior of the component is defined in xstate (we will need examples for the docs any way).

One not on the prototype is that I'd recommend against hook-style naming like useMachine. Controller aren't restricted by the rule of hooks and linters could give false warnings on names like that. That controller is a class and would typically have a capitalized name, like MachineController. Controllers don't have to be classes though and/or you can have a factor function like _toggleMachine = connectMachine(this, toggleMachine);

Thanks for the pointer, thats an easy change!

[ChrisShank]

Just noting that we should be able to support haunted for free with the proposed package! https://github.com/matthewp/haunted#usecontroller

[ChrisShank]

Here is a prototype of @santicros's MachineController working with with haunted! https://codesandbox.io/s/lit-xstate-machinecontroller-prototype-haunted-xhf78?file=/src/toggle-button.ts

cc @matthewp

(might even be able to get lucy + haunted to work together with this ReactiveControler package! Low-key would be a pretty 🔥 combo)

[matthewp]

😍

[santicros]

That's awesome!! 🔥

[tomByrer]

@xstate/lit seems interesting & I see lit getting some traction (maybe 1/3 of svelte now?).

I'm more interested in @xstate/jsx-lite which transliterates into React, Vue, Liquid, SolidJS, Figma, Angular, Svelte, etc. Backed by small company, though they recently poached Misko Hevery, Angular creator.

https://github.com/BuilderIO/jsx-lite

[ChrisShank]

Sort of up in the air now whether this should be called @xstate/lit or something like @xstate/reactive-controller. Obviously lit is enabling this, but I can also see how naming this package more agnostic could help users understand that this particular package does not just integrate with lit. @xstate/lit does sound very clean though haha 🤔

Any thoughts?

[tomByrer]

Oh that's interesting. Maybe wait until the reactive-controller sub-package has better docs?
Likely it will be released as @lit/reactive-controller, & "reactive-controller" makes me think of Reactive.JS, so maybe @xstate/lit-reactive-controller?

[santicros]

Interesting question!! Maybe a shorter combination of both with @xstate/lit-controller?

[ChrisShank]

Follow #2581 to see the implementation.

[PaulHax]

Officaly supported xstate and lit integration would be best, but we shamelessly copied Chris Shanks SelecterController from #2581 here:
https://github.com/InsightSoftwareConsortium/xstate-lit

Scratching the itch for now.