4 ms·

The Component State Chimera

• sktrdie 7y ago
  This is confusing to be honest. They talk about how keeping state in a component cannot allow you to do specific things. And the only way to achieve some things is to hoist the state (which leaks the state). This is fine by me but I totally fail to understand how the introduction of "state machines" solves the problem. The code is already a state machine. For instance you can have a component use an explicit state machine (say via xstate) and have it encapsulate state the same exact way (and with the same drawbacks) that he talks about. You can have component A use a state-machine and component B use another... you still have problems with leaking their state if they need to communicate. So not totally sure about the final comparison or what the actual solution is to the problem of "state leaking a component". Did I miss something or does the article feel incomplete?
  • 9935c101ab17a66 7y ago
    Yah, it meanders and seems unfocused. I'm pretty sure the person who submitted it is the original author, as their only other activity is to submit another JS library from the same github organization (not sure if that violates any rules) https://github.com/contrarian?tab=repositories https://github.com/contrarian?tab=repositories
  • donfestive 7y ago
    The "The Component State Chimera" explains that component state in an illusion. It does not present a way to cope with this realization, perhaps that is why it feels incomplete. I will publish the solution shortly :)