Imposed cognitive load of creating a simple React/Redux component

twitter.com

4 points·tjchear··3 comments

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.

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.

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.

Reply on news.ycombinator.com