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

31–40 of 84 posts

Re: How Redux Works: A Counter-Example

#31

Post by krishanath »

irl_zebra wrote: post #26
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…

I agree with this. I tried to learn React and Redux a while back, and didn't really grok it, so I built the React app without Redux. Ended up passing state up and down many, many layers of components and it got pretty hairy. So I added Redux to the mix and it was like a lightbulb went off in my head.

That's because you used React Router, which makes the router a view component. Router should be independent of view technology. If you had used React in the MVC style you would not have had to use Redux. Think about how session state works in the case of server-side applications. The same can be done on the client side too, by using React with an MVC framework.

Re: How Redux Works: A Counter-Example

#32

Post by dceddia »

ashark wrote: post #22
ryanbrunner wrote: post #13

Earlier quoted context omitted.

I think there's a fair criticism of Redux in here - most well designed tools can accomodate a learning curve, and scale up the complexity when needed. I can be productive in Express without knowing about middleware, or git without knowing how to rebase. Redux, on the other hand, expects you to dive into the deep end head first the first time you use it. I teach javascript development, and I'm noticing there's a prett…

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 buying IBM" quote...

Re: How Redux Works: A Counter-Example

#33

Post by beaconstudios »

krishanath wrote: post #29
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…

>> it appears hugely over complex and unnecessary Which it is, actually! Think about how MVC works in iOS, or ASP.NET MVC or JSP Model 2, etc. In the case of the latter two, your state is stored in the session as simple, regular objects. Have you felt the need for actions and reducers and immutability etc. when using session state? I have not. When programming JavaScript SPA, you can program in the style of MVC also.…

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

Re: How Redux Works: A Counter-Example

#34

Post by krishanath »

beaconstudios wrote: post #33
krishanath wrote: post #29

Earlier quoted context omitted.

>> it appears hugely over complex and unnecessary Which it is, actually! Think about how MVC works in iOS, or ASP.NET MVC or JSP Model 2, etc. In the case of the latter two, your state is stored in the session as simple, regular objects. Have you felt the need for actions and reducers and immutability etc. when using session state? I have not. When programming JavaScript SPA, you can program in the style of MVC also.…

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.

Re: How Redux Works: A Counter-Example

#35

Post by dceddia »

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…

First - thanks :)

Second - it's interesting you found the reverse approach to be confusing. I've heard from multiple people that loved it and said it made more sense to them that way. Different strokes and all that!

How experienced were you as a dev before you read the Redux docs + Dan's tutorials? I ask because I learned with those too, and they made sense to me (Dan's egghead videos were eye-opening), and I've been doing software for > 10 years professionally... but my suspicion is most beginners don't do as well with the top-down approach.

Re: How Redux Works: A Counter-Example

#36

Post by lewisl9029 »

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…

I've always been a huge fan of Redux, but lately I've become even more enthusiastic about Apollo Client 2.0 and the apollo-link-state project: https://github.com/apollographql/apollo-link-state

What this will let you do is basically extend your server-side GraphQL API with a set of local resolvers for queries and mutations, and let you query and mutate both your server-side and client-side state using a single consistent API (GraphQL, with client-side fields decorated with a @client directive), backed by a (mostly) automatically normalized local state cache (by default apollo-cache-inmemory, but customizable, so you can even implement a Redux based cache if you'd like more control).

A lot of the complexity in Redux today stems from the need to reconcile client-side state with server-side state, usually fetched through some kind of async actions paradigm like Thunks+Promises, Saga, Observables, etc, to be then manually merged into the local state after being transformed into a normalized form.

I personally think one of the biggest problems with the design of Redux is that the architecture derives most of its benefits from having a normalized state tree, but it also makes it all too easy for developers to store non-normalized data in the state tree. Although admittedly an architecture that does enforce a normalized state tree would be an order of magnitude more difficult to learn and work with in the wild-west of RESTful APIs that used to be the de-facto norm back in the days when it was designed (and it still is, though that may be slowly changing with the rapid adoption of GraphQL), where most server-side data you receive isn't easily normalizable to begin with.

A good GraphQL client like Apollo can already abstract away much of the complexity involved with async server requests through its Higher-Order Component-based API, which simply provides data to the wrapped component as props, so it doesn't need to know how to fetch that data. More importantly though, Apollo also ensures that all the server-side state it maintains in its cache is stored in a normalized manner, and GraphQL makes this fairly easy.

Apollo-link-state goes a step further and allows you to use the same abstractions for managing client-only state, and store it in a normalized form alongside your server-side state, to allow for a much more consistent and comprehensive state management API.

With all that said, apollo-link-state is still really young and I've only played around with it briefly in toy projects, so there's no guarantee it could scale as well to large teams as Redux has. I do still personally find it to be one of the most promising alternatives out there though.

Lastly, Relay Modern also supposedly has something called Client Schema Extensions, which I assume is similar to apollo-link-state, but wasn't able to find any documentation on it outside of a brief mention in its release notes: https://facebook.github.io/relay/docs/new-in-relay-modern.ht...

Re: How Redux Works: A Counter-Example

#37

Post by zebraflask »

krishanath wrote: post #29
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…

>> it appears hugely over complex and unnecessary Which it is, actually! Think about how MVC works in iOS, or ASP.NET MVC or JSP Model 2, etc. In the case of the latter two, your state is stored in the session as simple, regular objects. Have you felt the need for actions and reducers and immutability etc. when using session state? I have not. When programming JavaScript SPA, you can program in the style of MVC also.…

Agreed! Redux is cool but often overkill for basic CRUD apps, which the majority of JavaScript SPAs tend to be. My approach has been to take a long look at the app structure - if there's a way to refactor it to remove Redux (or what have you), that's probably the most sensible thing to do. Simple code > clever code where performance and maintainability are concerned.

I wouldn't mind a use case where Redux would be necessary or at least beneficial, for the practice, but I've yet to run across it after building half a dozen or more SPAs. These would be enterprise SPAs used in production, btw.

Re: How Redux Works: A Counter-Example

#38

Post by dceddia »

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.

It scales well in theory, and as long as the devs understand separation of concerns, and keep on top of refactoring, and don't overcomplicate things with extra layers of abstraction.

I've worked on some Angular (1) apps that became very messy over time. I think it all depends on the project. React/Redux can get messy too.

Re: How Redux Works: A Counter-Example

#39

Post by elliotec »

dceddia wrote: post #27
ryanbrunner wrote: post #13

Earlier quoted context omitted.

I think there's a fair criticism of Redux in here - most well designed tools can accomodate a learning curve, and scale up the complexity when needed. I can be productive in Express without knowing about middleware, or git without knowing how to rebase. Redux, on the other hand, expects you to dive into the deep end head first the first time you use it. I teach javascript development, and I'm noticing there's a prett…

The Redux learning curve is tough, especially for folks who don't already have a strong grasp of functional programming ideas. Immutability is weird. Breaking everything up into multiple places (dispatch, actions, reducers) is weird. Like you say, it's unfortunate that one must basically learn _all of it_ to get started using Redux. It does do a nice job of solving difficult problems though. > there needs to be some…

I think the answer to your question of "What drives this line of thinking" is simpler than you think:

- More popular libraries are better maintained and have more support

- More people use them (obviously), so more problems will already have already been solved the ${library} way

- Much easier to hire developers who know the more popular libraries

Re: How Redux Works: A Counter-Example

#40

Post by acemarke »

rahimnathwani wrote: post #12
dceddia wrote: post #7

Earlier quoted context omitted.

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…

> "here's a huge enterprise app, let's dive in" I'd love to see a complete project that uses redux, and would be horrible without it. Any pointers?? :)

I'm a Redux maintainer. Here's my two standard suggestions for more realistic sample apps:

- An 8-part "Build a Simple CRUD App with React and Redux" tutorial: http://www.thegreatcodeadventure.com/building-a-simple-crud-...

- My own "Practical Redux" tutorial series, which shows off specific useful React and Redux techniques within a sample app: http://blog.isquaredsoftware.com/series/practical-redux/

Also, my Redux addons catalog has a page listing many other interesting Redux-based apps, including purpose-built samples and real-world apps: https://github.com/markerikson/redux-ecosystem-links/blob/ma...

Post reply on HN