This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-06-26
Channels
- # announcements (6)
- # beginners (328)
- # boot (2)
- # cider (72)
- # clara (6)
- # cljdoc (4)
- # cljsrn (5)
- # clojure (78)
- # clojure-europe (3)
- # clojure-italy (22)
- # clojure-nl (4)
- # clojure-spec (3)
- # clojure-uk (114)
- # clojurescript (22)
- # clojurex (54)
- # copenhagen-clojurians (1)
- # core-async (20)
- # cursive (8)
- # data-science (1)
- # datomic (22)
- # duct (11)
- # emacs (32)
- # events (1)
- # figwheel (2)
- # fulcro (18)
- # graalvm (53)
- # graphql (39)
- # luminus (6)
- # nrepl (6)
- # off-topic (53)
- # om (1)
- # re-frame (8)
- # reagent (19)
- # reitit (3)
- # shadow-cljs (28)
- # spacemacs (10)
- # sql (37)
- # tools-deps (33)
- # vim (9)
- # xtdb (6)
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 http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs 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.
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 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
Does being outside of tree means it's local state?
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
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
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
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?