Live data from Hacker News

Idiomatic Redux: Implementation and Intent

blog.isquaredsoftware.com

41–50 of 88 posts

Re: Idiomatic Redux: Implementation and Intent

#41
post #33

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!

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

#42
post #9

Whenever 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.

Redux is an alternative. Easy to reason about and debug.

Re: Idiomatic Redux: Implementation and Intent

#43

Earlier 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…

The problem with redux is actually the dev-tools (and the ecosystem that spawned from the middleware). the newbies get wowed by "time travel debugging" and want to copy/paste there way to the $$$profit.

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]

[0] https://martinfowler.com/bliki/AnemicDomainModel.html

[1] https://martinfowler.com/eaaDev/EventSourcing.html

Re: Idiomatic Redux: Implementation and Intent

#44
Just want to put down my flag in the sand and say I love Redux. It is my tool of choice whenever dealing with anything that contains state and (with it's partner in crime, Redux Saga) anything that has to do with the real world (dreaded side-effects).

Thumbs up on Redux, your boilerplates are my sanctuaries.

Re: Idiomatic Redux: Implementation and Intent

#45
post #21

I'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-…

Because of the extra complexity and cognitive overhead introduced by connect. It obscures the one-way dataflow in React in a similar way using 'context' does, making it less explicit. There are benefits, but I like being able to trace the flow of state through my app in the code.

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

#46
post #33

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!

It's actually trivial to test, because all of the state is known at any time. So yes - kinda global state, but exact full state as input and exact full state out as output. Which you can test sliced into parts with as many tests as you want.

Re: Idiomatic Redux: Implementation and Intent

#47
The React ecosystem is growing out of control! JavaScript was a revolt against the overcomplicated Java ecosystem, but it is now worse than its original enemy with favors, opinions, and best tools for the job changing daily! Remember when JSON came out as an alternative to XML? Now all XML technologies have JSON equivalents - schema, pointer, etc. What was the point of the switch then - keep spinning wheels and not moving forward? With Babel being the centerpiece of JavaScript development today, can we at least apologize to GWT?

Re: Idiomatic Redux: Implementation and Intent

#48

Earlier 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.

The crazy state tree in redux is what made me go to mobx. I had events firing off updating multiple redux functions. It was very difficult to understand the flow. Mobx has simplified my changes to one place. To me they both the same managing client side state.

Re: Idiomatic Redux: Implementation and Intent

#49
post #33

Earlier 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.

My second problem with Redux, besides the common one about boilerplate, is precisely the mismatch between the recommended, RDBMS-like shallow store, and the typically tree-like OO nature of both the UI and the application logic. I understand that concrete containers act as adapters between the store and a given level of the application/UI tree, but this "impedance mismatch" is a real drag.

Re: Idiomatic Redux: Implementation and Intent

#50

Earlier 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…

Yeah you help so many people, thank you for all you do!
Post reply on HN