3 ms·

So I just started a new side project, and I'm using JS without a framework for the first time in over 5 years. I poured over several state management libraries

So I just started a new side project, and I'm using JS without a framework for the first time in over 5 years. I poured over several state management libraries before just deciding to write a naive solution on my own. I've got a very simple stateful class - the data model itself is private, and it has a custom getter/setter for access. The setter broadcasts a custom event for each top-level key that changed. Super simple, easy to understand, and the limitation forces me to keep my state as shallow as possible. Am I missing something? I expected to run into trouble but so far it's been easy breezy.

wlib 4y ago
I made a library in which state management started the same way. A simple approach is great for performance-sensitive parts and it's easy to write, but there is very little helpful structure to it. Reactivity fails very easily, consider a dependency graph like this: a -> b a -> c b,c -> d In this case, updating `a` would cause d to be calculated (and reactions run) twice. Also, update batching is absolutely necessary for anything non-trivial. At least for what I made, I don't think it's too complex for what it provides. It transparently integrates with the event loop and only runs what it needs to, at the cost of (min-brotli) 432 bytes at the moment. Compare the "naive" SimpleReactive with the complete FunctionalReactive version here: https://github.com/Technical-Source/bruh/blob/main/packages/bruh/src/reactive/index.mjs https://github.com/Technical-Source/bruh/blob/main/packages/...