Fork me on GitHub

I just read through Reagent’s docs on state management and batching. Are there any other solid resources written about why Reagent decided to manage state on behalf of React? I feel like this is giving some clues


@tkjone i don't know about reagent, but as someone who lived through all the different versions of react state management, i just don't feel like i should trust them about this particular topic


For sure and to be fair, they (React) are purposefully unopinionated about how to manage state (whether this is good or bad is up for debate 🙂 ). What I am finding interesting about Reagent is that it’s not a straight wrapper. It also provides internal “guidance” on how components update via ratoms and such. In this way, we do not have to use things like setState. I am curious as to what prompted this idea of internally “managing” state like this vs. just using the tools that React provided.


Reagent has a particular approach to state management in mind


it doesn’t say it in name, but what it’s implemented is essentially a way of doing reactive programming (also called “data flow programming”)


where you have values that as they change over time, trigger computations of derived values (other atoms, or UI components)


it’s an interesting paradigm, lots of research exists and continues to be done


it’s only one way of approaching state management tho, and React is moving further away from this (and more opinionated) with it’s newer features (to be) released like Time Slicing + Concurrent Mode


Fundamentally, React stores state within the tree of the app and associates it with the instance of the component that created it within the tree. Where this differs from Reagent (and data-flow programming), is state is represented as a stand-alone value outside of the tree

Ahmed Hassan05:06:57

Does being outside of tree means it's local state?


Outside the tree means it is created outside of a component


Interesting. So would it be fair to say that part of what Reagent’s approach is 1. performing an optimization enabled by ClojureScripts built in immutable data structures (compare data structures by ref vs looking into the data structures for changes) 2. applying an opinionated state management methodology (data flow programming) and by extension of the above, the rationale for libraries like hx is because of hooks, but more broadly the upcoming React features, are possibly going to overlap/conflict with Reagents? > To more general readers not interested in the internals, my question above is not alluding to “Reagent is going to die”. I am just trying to figure out how to contextualize the technical design considerations


yes, specifically (2)


and yes, the rationale for hx is really to more tightly align with React and the path that it’s taking. that’s not to invalidate Reagent (it should continue to work), but the React strategy has benefits and features that it enables which I want to explore and leverage while I build apps

👍 4

we might find out in 5 years that Reagent had the right idea all along and React is jumping the shark, but at least then we’ll understand the tradeoffs

👍 4

this probably isn’t the right place to ask, but has anyone done private/guarded/conditional routes with secretary?


@lilactown last question: does React’s strategy have a name? As in, Reagent is doing “Data Flow Programming”, but would the name of what React is doing be?


I’m not sure, but I think it draws inspiration from things like Algebraic Effects and studies on modeling effects + concurrency in ML and other research languages