Fork me on GitHub
#reagent
<
2018-10-28
>
lilactown19:10:22

one of the problems I’ve encountered when developing with reagent is that it makes it really attractive to use global state vars in order to avoid props drilling

lwhorton21:10:38

take a look at re_frame. subscriptions make this a non-issue, and the framework as a whole adds a whole lot more power to boot

lilactown21:10:15

no, re-frame makes it worse by forcing you to use a single global state var for everything 😉

lilactown21:10:49

the anti pattern is not scoping your state to the tree being rendered

lwhorton21:10:41

if you leave your data in one giant map as data, not as a view tree, your app will remain much more flexible to extension and growth

4
lilactown21:10:14

by referencing a global var, it makes it hard to do things like render a stateful component in a devcard. unit testing also becomes much harder

lilactown21:10:44

I also disagree with that, but that's somewhat unrelated 🙂 a giant map does not compose well

lilactown21:10:28

but it's unrelated; redux uses the single-app-db while also allowing one to scope their app-db to a particular render tree

lilactown21:10:04

e.g. you can have multiple instances of an app running on one page. or do server-side rendering without worrying about bleeding data between requests

lilactown21:10:37

global vars (and a giant map for state) make certain things easier, but they have serious downsides once you start to scale

lilactown19:10:06

in raw React this is supposedly fixed by using Context, but using render props is super verbose and awful, especially when you’re consuming multiple context

lilactown19:10:59

the new React Hooks API makes it REALLY ergonomic in a CLJS setting. very similar to using reframe, but your state is scoped to the render tree!!

lilactown19:10:34

in fact, here’s how to use the new useReducer hook to start building a tree-scoped re-frame clone 😄