Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Redux Works: A Counter-Example

daveceddia.com

Post reply on HN
Print view View original

41–50 of 84 posts

Re: How Redux Works: A Counter-Example

#41

Post by beaconstudios »

krishanath wrote: post #34
beaconstudios wrote: post #33

Earlier quoted context omitted.

MVC isn't especially easier than event sourcing (which is basically what redux is) once you get to larger applications. I think the two map quite nicely onto Fowler's design stamina theory ( https://martinfowler.com/bliki/images/designStaminaGraph.gif ) in that redux is harder to work with for small apps but the complexity scales linearly. MVC is easy for small apps but has a tendency towards spaghetti in larger code…

>> MVC is easy for small apps but has a tendency towards spaghetti in larger codebases. Disagree. There is no reason to believe MVC tends towards spaghetti in large codebases. Controllers and views implement a small portion of the application's functionality. When the applications get larger individual controllers and views do not even know that the application got larger, so this scales very well.

the things I find scale badly in MVC are primarily related to general OOP scalability issues - dependency hell, bloated classes, loss of separation of concern, and the big one being poor cohesion and state mutation propagation. I think my argument is broadly more like "OOP is needlessly hard", something that isn't really inherent to MVC.

Re: How Redux Works: A Counter-Example

#42

Post by acemarke »

sailfast wrote: post #17

I appreciate the author's work to explain this, and I like starting without Redux as a demonstration - definitely a good idea to figure out what React does on its own first. That said, I found the reverse approach to Redux to be more confusing than the actual Redux documentation and the tutorials that Dan Abramov has already put together around Redux which explains things quite lucidly. Example: https://egghead.io/le…

Dan's teaching style is very much "from first principles". You can see that in his Egghead videos, as well as the "Middleware" page in the Redux docs [0].

I've seen feedback that Dan's teaching style is the greatest thing ever, and feedback that it requires a giant leap of faith that "we write thing A, and thing B, and thing C, and magically they all work together at the end". Clearly, different people have different learning styles. Dan and Andrew _did_ try to write the docs in a way that would be accessible for people with varying backgrounds, but it's tough to write docs in a way that works for everyone.

If you or anyone else has suggestions for improving the docs, please let me know! I'm always open to ideas for improvements. Please ping me on Twitter at @acemarke, or file an issue / PR in the repo.

[0] https://redux.js.org/docs/advanced/Middleware.html

[1] https://github.com/reactjs/redux/pull/140#issuecomment-11371...

[2] https://twitter.com/dan_abramov/status/622568094939090944

Re: How Redux Works: A Counter-Example

#43

Post by acemarke »

leshow wrote: post #3
ergo14 wrote: post #2

It is interesting how people have the idea that react === Redux/flux. Where in fact Redux is unopinionated and works with other libraries/frameworks just fine.

How often do you see redux used with anything other than react? Or are you just talking about redux working with react alternatives like preact/inferno, etc? You're not wrong, but practically 99% of people pair it with react.

Redux is actually used noticeably outside of the React community.

Redux can be used with any UI layer, and there's bindings for many frameworks and UI layers besides React [0].

Redux has picked up popularity within the Angular community, both in its original form and the NgRx reimplementation. The ember-redux bindings are also starting to gain a bit of a following. Vue's VueX lib is inspired by Redux, and there's Vue-specific bindings for Redux itself.

[0] https://github.com/markerikson/redux-ecosystem-links/blob/ma...

Re: How Redux Works: A Counter-Example

#44

Post by arximboldi »

krishanath wrote: post #34
beaconstudios wrote: post #33

Earlier quoted context omitted.

MVC isn't especially easier than event sourcing (which is basically what redux is) once you get to larger applications. I think the two map quite nicely onto Fowler's design stamina theory ( https://martinfowler.com/bliki/images/designStaminaGraph.gif ) in that redux is harder to work with for small apps but the complexity scales linearly. MVC is easy for small apps but has a tendency towards spaghetti in larger code…

>> MVC is easy for small apps but has a tendency towards spaghetti in larger codebases. Disagree. There is no reason to believe MVC tends towards spaghetti in large codebases. Controllers and views implement a small portion of the application's functionality. When the applications get larger individual controllers and views do not even know that the application got larger, so this scales very well.

I disagree.

It doesn't because encapsulated mutation does not compose. Typical example: your data model fires signals notifying change as soon as you change them, then thew view updates. All good, until you have to build transactional updates and then you get flicker, broken invariants due to partial values being propragated, etc, etc. You need to understand how everything is wired up together to really know what is going on because effects are interleaved with logic, even when each component individually feels decoupled and nice.

What Redux/value-based data model does is to really separate those concerns. Your update logic is a function that just can mess all it wants with the new values it produces. It is composable because you can just build logic by calling smaller logical unit and you know everything you need to know by looking at the inputs and outputs.

It is way simpler (and less!) code in all but the most trivial of the examples.

Re: How Redux Works: A Counter-Example

#45

Post by com2kid »

dceddia wrote: post #32
ashark wrote: post #22

Earlier quoted context omitted.

It's downright embarrassing to walk through a Redux-using project with someone competent who's not immersed in the JS world. Source: had to do this recently. It helps if you translate "action creator", "action", and "reducer" to terms that are less misleading in the first two cases, and less uselessly-generic in the last one, but only a little. I tolerate it for basically "no-one got fired for buying IBM" reasons, i.…

I would expand that to say, it's embarrassing/difficult to explain the JS ecosystem to experienced non-JS devs. From "why are there 132MB of packages for hello world?" to "why is there a build process at all", people outside the UI+JS world have a tough time seeing why there's so much complexity for "just the UI". Also, side note, it's hilarious (and maybe telling) that we both referenced the "no-one got fired for bu…

> "why is there a build process at all", people outside the UI+JS world have a tough time seeing why there's so much complexity for "just the UI".

Having come from cross-plat C++, the JS build system(s) are impressing me, at least the one around React Native.

One data point. :)

Re: How Redux Works: A Counter-Example

#46

Post by acemarke »

I'm a Redux maintainer, and this is a great introduction to Redux. I love Dave's ability to break things down into easily understandable pieces, and his clear writing style.

I also saw a similar "React and Redux: An Introduction" tutorial published just within the last couple days [0].

For anyone who's looking to learn more about Redux, I'd encourage you to check out my React/Redux links list [1], which has sections pointing to more Redux tutorials [2], Redux architecture and best practices [3], and much more.

If you've picked up the basics of Redux and want to see how it works at a larger scale, I recommend the "Building a Simple CRUD App with React and Redux" series [4], and my own "Practical Redux" tutorial series [5].

Also, my "Idiomatic Redux" blog series [6] looks at things like the history and intent behind Redux, common usage patterns and why they exist, and why I consider certain patterns to be the "right" way to use Redux.

Finally, I am always happy to answer questions about learning and using React and Redux! Please feel free to ping me on Twitter at @acemarke. Also, come by the Reactiflux chat channels on Discord [7]. There's always plenty of people around who can answer questions. I'm usually on there evenings US time.

[0] http://jakesidsmith.com/blog/post/2017-11-18-redux-and-react...

[1] https://github.com/markerikson/react-redux-links

[2] https://github.com/markerikson/react-redux-links/blob/master...

[3] https://github.com/markerikson/react-redux-links/blob/master...

[4] http://www.thegreatcodeadventure.com/building-a-simple-crud-...

[5] http://blog.isquaredsoftware.com/series/practical-redux/

[6] http://blog.isquaredsoftware.com/series/idiomatic-redux/

[7] https://www.reactiflux.com

Re: How Redux Works: A Counter-Example

#47

Post by arximboldi »

Nice thing about this architecture is that it really is agnostic to your stack and as long as you have some way to build "values" you are good to go.

I have recently been working on a Redux for C++ experimental library with time-travel and all. As an example I built a mini-emacs text-editor with it. Should post about it here whenever I flesh out the README and all (or the MeetingCpp talk about it gets published). In the meantime you might want to check these links:

The library: https://github.com/arximboldi/lager

The Counter-Example: https://github.com/arximboldi/lager/tree/master/example/coun...

The text editor: https://travis-ci.org/arximboldi/ewig

Show-case of a time-travelling debugger: https://twitter.com/sinusoidalen/status/926382341433577472

Re: How Redux Works: A Counter-Example

#48

Post by acemarke »

robmcm wrote: post #4

There is a certain paradox with teaching something like Redux, in that it's designed to make complex systems easy to understand and manageable. Yet when trying to demonstrate with a simple example, it appears hugely over complex and unnecessary. I think a pre-requisite to learning something like Redux (or any micro-architecture) is to first try building something without it. Once you understand the pains of undiscipl…

Yeah, Dan Abramov made a great comment a few months ago, which I posted on Twitter ( https://twitter.com/acemarke/status/901329101088215044 ):

> Dan Abramov, just now : "if you want to teach someone why to use an abstraction, you should first make them feel the pain of not having it"

But yes, it's tough to try to show the value of Redux while at the same time keeping the example simple enough to illustrate the basic mechanics.

Re: How Redux Works: A Counter-Example

#49

Post by whitefish »

arximboldi wrote: post #44
krishanath wrote: post #34

Earlier quoted context omitted.

>> MVC is easy for small apps but has a tendency towards spaghetti in larger codebases. Disagree. There is no reason to believe MVC tends towards spaghetti in large codebases. Controllers and views implement a small portion of the application's functionality. When the applications get larger individual controllers and views do not even know that the application got larger, so this scales very well.

I disagree. It doesn't because encapsulated mutation does not compose. Typical example: your data model fires signals notifying change as soon as you change them, then thew view updates. All good, until you have to build transactional updates and then you get flicker, broken invariants due to partial values being propragated, etc, etc. You need to understand how everything is wired up together to really know what is…

If your model layer objects are firing events you have problems already because it obscures the call graph. I try to avoid that style. The controller should update the model objects, then if a view update is needed it should be triggered by the controller not the model layer object.

Re: How Redux Works: A Counter-Example

#50

Post by tootie »

dceddia wrote: post #7
robmcm wrote: post #4

There is a certain paradox with teaching something like Redux, in that it's designed to make complex systems easy to understand and manageable. Yet when trying to demonstrate with a simple example, it appears hugely over complex and unnecessary. I think a pre-requisite to learning something like Redux (or any micro-architecture) is to first try building something without it. Once you understand the pains of undiscipl…

This paradox I think is what turns people off Redux when they first learn it. "All this code... for what benefit?" Of course it's total overkill for something like a counter, or a todo list, but it's tough to teach an introduction to something by starting with "here's a huge enterprise app, let's dive in" :) I tried to call this out in the article to make sure people are aware that improving simple Counter examples i…

I understand the value of redux but I'd lump it in with git as an invaluable and elegant solution with a terrible interface. The structure is very confusing up front and makes no sense to an outsider. I learned react in about 15 minutes because it's so intuitive, but redux keeps making me scratch my head.

IMO, It's a fundamental flaw with JavaScript that interfaces aren't rigorous or discoverable and redux is a willing victim.

Post reply on HN