4 ms·

I'm using Web Components for this stuff, and it works. If I need variant behaviour, I define a new tag and spec out the behaviour in JS. This removes the need f

I'm using Web Components for this stuff, and it works. If I need variant behaviour, I define a new tag and spec out the behaviour in JS. This removes the need for a vanilla JS routine that grabs the element with selectors and twiddles it. This feels like an improvement, even for a single tag :) But I'm not doing anything massively complicated yet, so I don't know how it scales for complex UI interactions.

danielvaughn 3y ago
My suspicion is that if you have a single page where there are lots of interdependent elements that update state together, then it may become difficult to maintain.
- marcus_holmes 3y ago
  I agree. But the strategies that Elm/React/Vue/etc use to deal with this can be copied without taking on all the rest of the baggage. Creating a Flux/Vuex-style state container and a bunch of mutator functions isn't hard.
christofosho 3y ago
For my learning, what kind of state management do you use or see commonly used with web components?
- sibit 3y ago
  I use something similar to React class components. Under the hood my set function calls Object.assign and I debounce the render function callback. You could implement it yourself in <80 lines of JavaScript[0]. I'm not sure what other people use but I've been using this style of state management for ~4 years and it's been fine so far. [0]: https://github.com/codewithkyle/supercomponent/blob/master/src/supercomponent.ts https://github.com/codewithkyle/supercomponent/blob/master/s... Edit: if signals are your jam you could us https://github.com/maverick-js/signals https://github.com/maverick-js/signals
- marcus_holmes 3y ago
  I currently have three large components that handle state between them, and a bunch of control components that don't care about state (they receive values as attributes, and trigger "change" events if changed by the user). The larger components contain their own state, and communicate by events (so component Foo emits a change event when its state changes, and component Bar listens for that event and fetches the new state by checking event.target.data). It's working reasonably well with this relatively small set of interactions. But I can see a point where I'll have to create a Flux/Vuex-style state store and use actions to mutate it.

danielvaughn 3y ago

My suspicion is that if you have a single page where there are lots of interdependent elements that update state together, then it may become difficult to maintain.

marcus_holmes 3y ago
I agree. But the strategies that Elm/React/Vue/etc use to deal with this can be copied without taking on all the rest of the baggage. Creating a Flux/Vuex-style state container and a bunch of mutator functions isn't hard.

christofosho 3y ago

For my learning, what kind of state management do you use or see commonly used with web components?

sibit 3y ago
I use something similar to React class components. Under the hood my set function calls Object.assign and I debounce the render function callback. You could implement it yourself in <80 lines of JavaScript[0]. I'm not sure what other people use but I've been using this style of state management for ~4 years and it's been fine so far. [0]: https://github.com/codewithkyle/supercomponent/blob/master/src/supercomponent.ts https://github.com/codewithkyle/supercomponent/blob/master/s... Edit: if signals are your jam you could us https://github.com/maverick-js/signals https://github.com/maverick-js/signals
marcus_holmes 3y ago
I currently have three large components that handle state between them, and a bunch of control components that don't care about state (they receive values as attributes, and trigger "change" events if changed by the user). The larger components contain their own state, and communicate by events (so component Foo emits a change event when its state changes, and component Bar listens for that event and fetches the new state by checking event.target.data). It's working reasonably well with this relatively small set of interactions. But I can see a point where I'll have to create a Flux/Vuex-style state store and use actions to mutate it.