Hacker News Reader

Comment by gedy | Hacker News Reader

I think you are missing out on the point that Redux can be very difficult to learn and build a real app around for many people.

> it's all of a few hundred lines of code

I hear this a lot, but it reminds me of folks praising Lisp for its simplicity - it may be 'simple' but many people have a hard time understanding it.

Maybe it's not for every app, but goes into this here: https://medium.com/@matheusml/great-question-bryan-waddingto...

View on HN

I have no problem with someone writing their own state management framework after forgetting or before learning the hard lessons that drove the design of Redux, particularly if it's easier to use for people just getting in to web development.

The problem I have is with an author tying their library to Redux, giving those same newer people the impression that it's a simpler, but just as powerful version of the same thing. If they had been upfront about the tradeoffs made here, I would be happy.

Yeah, there's some truth to that. There was actually a good article and related tweets by Justin Falcone a few months ago on that topic [0][1][2], which are excellent reading.

That said, I'm always looking for ways we can make it easier to get started with Redux, improve the learning process, and make the ecosystem better. I filed an issue earlier this year to get community feedback and discuss how we can simplify things [3]. Please feel free to add suggestions to that issue. I'm also always open to ways we can improve the docs as well.

[0] https://medium.freecodecamp.org/whats-so-great-about-redux-a...

[1] https://storify.com/acemarke/redux-pros-cons-and-limitations

[2] https://twitter.com/modernserf/status/886426115874717697

[3] https://github.com/reactjs/redux/issues/2295

Great read in links, thanks for sharing

It's very important that people understand _how_ and _why_ the flux pattern is valuable before they start using Redux, especially if coming from an MVC background. Once you understand that, the learning curve drops away revealing an extremely minimal and easy-to-use library.

Yes, but I don't see this same difficulty with say, MobX. People seem to 'get it' and are as productive as Redux from what I see.

> extremely minimal and easy-to-use library.

'Extremely minimal' is hyperbole and 'easy-to-use' is subjective. I disagree with this as an absolute statement. I think there's a trade off, and it potentially harms onboarding for some teams, see my sibling-ish comment.

I agree with your comment, but disagree that all of the concepts you listed need be understood completely when just getting started. Once the flow is recognized (which in my experience teaching others rarely takes more than a single pairing session) there's basically nothing left but a few functions that pass data in a circle. Everything else that you described comes later, and that later doesn't take long.

Not sure why you were downvoted, I agree. Redux brings a high 'concept count', for such a small amount of code. To talk the language of redux you have to understand: dispatch, actions, actions-types, actionCreators, reducers, mapStateToProps, mapDispatchToProps, middleware, provider/connect. You need to know these things, and best practices for them, and potentially some libraries around them to reduce boilerplate.

As soon as you dip your foot into the community you're also going to hear about 'selectors' (reselect) and popular middlewares like redux-thunk and redux-sagas for async, the latter of which brings a lot of concepts of its own, including generators, which you are likely using nowhere else in your codebase.

You probably also need to understand what react-redux is doing with shouldComponentUpdate.

All this should not be hand-waved away by quoting the LOC of redux.

Reply on news.ycombinator.com