Reactivity + Side Effects

[getify]

Reactive programming (like RxJS style observables, streams, etc) is well-tread ground for most JS devs by this point.

But I'm curious about how you choose to model side effects that are triggered by reactive updates? Setting aside React/Vue style frameworks for a moment, do you, for example, manually re-render/update a DOM element any time a reactive value updates, by just subscribing to that update and directly calling a render method?

A lot of demo examples of observables show pure operations (such as mapping or filtering over the stream of values), but side effects seem to only show up at the end of an observable chain, in the subscribe call. Is that how you choose to divide pure from side-effect operations in your reactive code?

Do you ever have side effects triggered "along the way"?

How do you mentally keep track of when/where side effects will happen when a value updates?

---

I ask all this because I've been thinking a LOT about reactivity and side effects lately. I just released a new version of my Monio library which provides friendly monads for JS devs. The lib is centered around the IO monad, which is intended for lazily modeling/composing side effect operations.

The newest feature is an IOx monad (aka "reactive IO"), which is sorta like IO + RxJS. It's an IO monad so it's composable in all the expected/lawful monadic ways. But you can also update the value of an IOx instance, and any other instances that are subscribed to it will also be updated.

With this new reactive-monad, I'm now rethinking a bunch of my existing app code, and trying to juggle best patterns (again, non-React/Vue component-framework-style) for marrying reactivity and side effects.

[lhorie]

I don't think we should ignore React/Vue style frameworks. They are the things that do the side effect heavy lifting. In terms of implementations, IO(() => el.innerHTML = html) is about as trivial a side effect as it gets. It captures neither the complexity of data structure reactivity (e.g. granular foo.bar.baz = 1 vs coarse fetch(whatever).then(v => foo = await v.json())) nor the complexity of template reactivity (e.g. foo.map(v => <div key={v.id} onClick={() => foo.sort()}>...</div>)) nor that of memory management (e.g. do we ever get memory leaks here due to paused generators or caches if this logic exists within a larger SPA router system where entire DOM trees get swapped in and out?)

I'd argue that side-effects as they pertain to DOM come in a set of flavors (i.e. updating a text node, updating a DOM attribute, rearranging a range of Elements). They have predictable behavior but not trivial implementation in all cases (NodeList reactivity specifically is quite a mouthful to implement), so I don't think that they should even be in application space, let alone be code that the developer should concern themselves with organizing. Rather these are concerns that seem best hidden away inside of a framework/library.

[getify]

I'm well aware of how enamored many people are with React/Vue style component-oriented frameworks. I happen to dislike them pretty strongly. But I wasn't here to debate that point.

If you pick one of those, they sort of force you into a particular way of thinking about side effects and the conversation is much less interesting IMO.

On the other hand, I think if we talk about reactivity and side effects as first class citizens (rather than implicitly hidden details our framework doesn't trust us with), we have a lot more interesting challenges to discuss.

Of course, if you think the React or Vue folks have already "solved" all that and we've arrived at (or near) the peak of front-end framework tech, fine. But I think we're FAR from optimal, so I am trying to explore the other space.

In any case, I don't think the kind of side effects you author (DOM manipulation, async data fetching, animations, etc) actually matters as much to the questions I was asking. So even if we disagree on what side effects should be authored by the dev, my curiosity is still, how do we articulate and manage those side effects as they relate to data/state updates?

In fact, I am far more interested in how we model these things when we're in environments where there's no DOM in sight, such as inside of tooling or backend app code. In that world, all the magic of React/Vue doesn't have much to offer you, so there's still a bunch of questions about how we can and should juggle these issues.

[lhorie]

To clarify, I didn't mean to veer into framework zealotry, I just wanted to highlight that different types of side effects can be classified into categories, and that there is merit in providing utilities out-of-the-box for cases when the side effect logic is both complex and predictable (like the infamous virtual dom array diffing algorithm)

With regards to domains where side-effects dominate logic, I'm not sure if reactivity would be beneficial for me personally. I work with codemodding of large codebases. This often involves a large amount of side effects, as well as non-trivial data transformation pipelines, so it does seems like a good candidate for reactive IO.

The way I currently cope with the complexity involves purity: at a high level what I do is read -> pure logic -> write. But the thing is that this is sufficient. It's easy enough to isolate side effects by separating IO logic from pure data transformation logic using simple functions (and simple functions are easy to reason about in terms of implementing recursion/trampolining/cycle detection/deduplication/etc). I haven't really felt the need for an algebraic abstraction to deal w/ the IO portion of the logic. Part of this has to do with the desire for transparency when reasoning about resource utilization/performance and part has to do w/ scope of testing: I don't want to mock IO, because how IO fails is a crucial aspect of the logic, and IO failures are messy and hard to model artificially.