Comment by zero_shift | Hacker News Reader

Comment by zero_shift | Hacker News Reader

Parent Full thread

> Yes, Redux requires some amount boilerplate code

I think you're underplaying this. The Redux apps I've seen thread data through a great many layers - action creators, actions, reducers, sagas, schemas - and I think it's fair to say that compared to other projects, Redux apps have very long 'chains of operation' (I want to avoid value-laden terms like 'structure' or 'bureaucracy').

Is it worth it? I'm not sure. The Redux apps I've seen have used this 'highly formalized' approach to handle quite simple interfaces. Maybe I'd have different feelings if I was writing something bigger?

It's not that I hate Redux, or think it out and out 'sucks'; but I've worked on a lot of projects and first Redux ones I've worked on seem unusually difficult to reason about, and a few of my colleagues share my feelings. We feel like it is hard to reason exactly what an event or command exactly 'does', and that the diffusion of behaviour across files plays a part in that.

Ok, maybe I underplayed it a bit, and I certainly also had a different opinion when I started to get into Redux.

It is true that if you do Redux "by the book", as taught in the official documentation, then it is indeed quite verbose and confusing in the beginning. But once it makes "click" and you start to understand what the point of all these moving parts is, then it's possible to come up with thin abstractions on top of it to reduce the boilerplate. It would have been great if there was a common "standard" way how to do this, but on the other hand, having the flexibility and power to do things how you want, to make it fit your team and project, is quite nice.

For example, we never liked those huge switch statements in reducers. We just use plain objects, where the key corresponds to the action name, and the value is the reducer function. Not really a big deal, but it just shows that you have the freedom to lay out your Redux app however you see fit.

We also saw no real value in strictly splitting up actions, action creators and reducers among multiple files. We simply put actions, action creators and reducers that belong together in a single file.

And then there is the possibility to use middle wares, which can greatly help in debugging and tracing down actions.

So far everyone in my team is very happy with Redux (and React of course).

> We also saw no real value in strictly splitting up actions, action creators and reducers among multiple files. We simply put actions, action creators and reducers that belong together in a single file.

I think that's a much more pragmatic approach for smaller applications.

I knew this would trigger a remark ;) I'm absolutely aware of the importance of separation of concerns. And our SPA is not small.

I just became less dogmatic about it. We all have been taught how important it is to separate HTML/CSS/JS, but then came React along and put HTML into JS, many people were outraged, including me. I thought I'd never use that crap that violates basic principles of software design, but here I am and I'm loving it. In the context of UI it makes sense to me. Same with Redux.

Could you please give me an example in which cases you think it could become problematic to have actions, action creators and reducers in a single file? In an application that is not small?

Reply on news.ycombinator.com