Spots 
Hey everyone :) Been a while... I've been busy updating the libs, so those dozens of you who've enjoyed mmstack as it's grown will already know some of this. Still, getting it out on "paper" is usually good. Alrighty, let's get into it...effects. Never, ever, ever ever, ever EVER ever use effects ... ever
Look, I know, I've been there...an effect synchronizing a few signals couldn't hurt, right? It's just one. And yeah, I've seen systems full of 'em & they worked (mostly). The trouble comes when they start depending on one another. Soon we're juggling dozens, then hundreds of side effects, spread across files whose authors all thought they were adding just one. In the large systems I usually end up assigned to, it'd all collapse like a house of cards if I wasn't strict about it.
Signals aren't particularly special here...writes tucked into RxJS tap callbacks & side-effectful functions can make data flow and ownership just as difficult to follow. With effects we also have scheduling to account for. The source changes now; the effect that copies it somewhere else runs later.
That gap may never make it onto the screen, but we can still read the state while the values disagree. Add another effect & a few more signals:
Now imagine a submit method reading that label immediately after updating the name. Changing the order of a few .set() calls won't make the effects synchronous. I know this is a trivial example; in my experience it's usually much worse, with the source, the copied values & whatever reads them dispersed among many files and intertwined with the rest of the business logic. For these two values we can express the dependencies directly:
Read label() after changing the name & it derives from the current inputs. That's the rule I'd like to keep all the way down: derivation over synchronization. Mostly for my own sanity, & because I'd like the system to survive the PM's latest idea next Tuesday. So computeds all the way down?
Well...yeah, pretty much. Or derivations rather. For normal stuff a chain of computeds may be all we need. mmstack's derived gives us a writable view back into its source, while linkedSignal is useful when we want to hold local state & decide how it follows a changing source.
Say we have the usual table -> edit button -> dialog -> PATCH setup. The dialog starts from an item in the table's response, but the table can page away or refresh while we're editing. We'd like to keep the form open, and if the item comes back with new data, reconcile it with what we've already entered:
TodoState, createTodoState & reconcile are our application helpers here. The reconciliation returns the next form state. When the item disappears from the response, we hold the previous state. For a new dialog without an item, this example starts empty. An edit dialog should still distinguish loading, a failed request & an item that actually no longer exists before allowing submission.
There are plenty of forms of derivation, some in the framework (computed, linkedSignal, resources), others in libraries or our own code (indexArray, keyArray & so on). Finding or making the right one is usually the tricky part :) If the value belongs to the graph, that's where I'd spend the effort. Alrighty, now that we're never using effects - let's use some effects :D
Hey everyone :) Been a while...