
Imposed cognitive load of creating a simple React/Redux component - tjchear
https://twitter.com/TjChear/status/1219380505675616256
======
sibeliuss
This diagram covers initializing the library, which is a few lines of code and
a few functions, as is often the case when initializing libraries. On the
surface, it misrepresents things as they are commonly used post setup by
mixing the entire redux flow into one diagram.

setup -> actionCreator calls dispatch -> update store (reducer) -> update
connected component.

The latest version of Redux also address some of the verbosity between actions
and reducers and so on, too, to address feedback.

~~~
tjchear
I made the diagram to help me remember the concepts and how they relate to
each other, and as my title suggests, it also illustrates the cognitive load
imposed by having to remember the pieces I have to add/change whenever I make
changes to the state machinery, not so much how state change flows through the
various pieces.

I appreciate the effort to reduce the verbosity, but so far I've been served
well with react context and useState. I can only hope that my failure to
understand the necessity for all the various named concepts comes down to
insufficient critical mass of the complexity of my webapp.

~~~
sibeliuss
With big apps Redux scales exceptionally well, and the terminology (a design
pattern, really) allows devs unfamiliar with the codebase to immediately start
contributing. The design also allows for middleware (and access to a vast
middleware ecosystem), performant lookup, caching, and more. There's a lot
more to it than global state access throughout a component tree.

All of the write ups out there about "why you don't need redux" are all right
on. You typically don't. You'll know when you do, however. And it's worth
preemptively diving in if planning for a large application.

