Earlier quoted context omitted.
Because you can use the React-Redux `connect()` function to wrap any component in your tree with a "container component" that automatically subscribes to the Redux store, extracts the data you want for that component, and passes it straight in. That way, the upper components in your application don't need to know that a leaf component happens to need a specific value and pass it down through N levels of components -…
That sounds completely opposite to the React functional philosophy and is akin to using global variables in a regular program. Have fun testing that!
Idiomatic Redux: Implementation and Intent
41–50 of 88 posts
Re: Idiomatic Redux: Implementation and Intent
#42Whenever a Redux thread pops up, there's inevitably complaints about "boilerplate". I'd like to pre-empt those complaints a bit by pointing out that, per part 2 of my post, it's entirely up to you how much abstraction you use in your own Redux app. If you want use Redux for a particular use case, someone has probably already written an addon or utility to help solve that problem, and I've got them listed in my Redux…
Mobx is an alternative. Simple and less boilerplate.
Re: Idiomatic Redux: Implementation and Intent
#43Earlier quoted context omitted.
It sounds like the author is some kind of guru who became enlightened and willing to share the "tao" of "idiomatic" way of JS library. Can't you see how pretentious it it?
Well, _I_ am the author, _and_ a Redux maintainer, _and_ I've spent a ton of time discussing and using Redux :) I can legitimately say I'm _an_ expert on Redux, its implementation, and its use. The original point of writing it is that I see many people complaining about things like "having to use action creators" and "having to edit many files", when Redux itself doesn't actually require you to do those things. So ye…
Redux takes a simple concept, and turned it into something thats really hard to apply to the projects these people are writing; by reinventing words into a propriety language.... No one talks about about there state as a function of "reducers". And when they think they have their head around "actions" they realise that no, its not a 1-to-1 relationship with what the user is doing.
If redux didnt try and re-invent event-sourcing with its own "idomatic TAO way", it could of leveraged off the plethora of well written documentation on the subject.
Instead, Dan, thought he could improve event sourcing and make it palatable for the masses by -replacing "events" with "actions" [1] -making the state an anemic domain model[0] -persisting snapshots instead of an event log then adding on congnitive load by implementing a diffing algorithm for UI updates which requires specialised knowledge. [1]
Re: Idiomatic Redux: Implementation and Intent
#44Thumbs up on Redux, your boilerplates are my sanctuaries.
Re: Idiomatic Redux: Implementation and Intent
#45I've just started another side project using React with redux. One of my goals is to keep my code as simple as possible while still being able to build a large application. To keep it simple, I'm not using react-redux (I often try to avoid this), and I generally pass the entire store down through all child components, again to keep it simple. My top level app with its simple navigation code subscribes to the redux st…
I'm _very_ curious: why do you feel you need to "avoid" React-Redux? There was a similar thread on Reddit a few days ago, asking why the OP should bother using React-Redux [0]. I'll paste the main part of my reply: > First, while you can manually write the code to subscribe to the Redux store in your React components, there's absolutely no reason to write that code yourself. The wrapper components generated by React-…
Second and third points both concern performance. See my OP: it's a premature optimization. How many people honestly run into rendering performance issues when building a single page app? Why introduce extra complexity for performance you don't need?
Fourth point: no, I don't manually import the store into my components. My top level app component subscribes to the store (3-4 lines of code), and passes the data in the store down into its child components, including my routing component and all the rest. Most of them are dumb stateless functions that just render from their props and call the occasional action function.
Action functions themselves aren't on props and don't do any binding of any kind. They are just functions that provide a simple abstraction on top of store.dispatch. Again, simplicity.
Regarding confusing developers: I disagree with this statement 100%. We have two React apps at work, one that uses the simple approach without react-redux, and another that pulls in most of the usual ecosystem: react-redux, react-router, redux-form, and so on. The cognitive overhead is larger; reasoning about the code is harder; the greater number of libraries means we've had bugs in those libraries that cause difficult to solve problems.
It's just an opinion of mine, but in my experience, React and redux by themselves can get you a very long way before you need to pull in other libraries.
Re: Idiomatic Redux: Implementation and Intent
#46Earlier quoted context omitted.
Because you can use the React-Redux `connect()` function to wrap any component in your tree with a "container component" that automatically subscribes to the Redux store, extracts the data you want for that component, and passes it straight in. That way, the upper components in your application don't need to know that a leaf component happens to need a specific value and pass it down through N levels of components -…
That sounds completely opposite to the React functional philosophy and is akin to using global variables in a regular program. Have fun testing that!
Re: Idiomatic Redux: Implementation and Intent
#47Re: Idiomatic Redux: Implementation and Intent
#48Earlier quoted context omitted.
Mobx is an alternative. Simple and less boilerplate.
This comment is always the first, every time, but they're both very different. Mobx is mutable binding, redux is one way, functional data flow. They have their tradeoffs, but when I look at mobx I get reminded of managing crazy state trees in ember and why I went to react/redux in the first place. YMMV.
Re: Idiomatic Redux: Implementation and Intent
#49Earlier quoted context omitted.
That sounds completely opposite to the React functional philosophy and is akin to using global variables in a regular program. Have fun testing that!
You can test the base component or test the connected component with a dummy state. If your state is shallow, this is very easy to do.
Re: Idiomatic Redux: Implementation and Intent
#50Earlier quoted context omitted.
Perhaps redux really might benefit from communicating heavily with beginners.
Well, I do spend a ton of time answering questions from Redux beginners in many places online: Reactiflux, Stack Overflow, Reddit, etc. That's why my first contribution to Redux was writing the Redux FAQ [0], because I kept seeing the same questions being asked over and over. Ditto for the "Structuring Reducers" docs section as well [1]. So, I'd say I've got a pretty good idea what kinds of questions people are askin…