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

61–70 of 84 posts

Re: How Redux Works: A Counter-Example

#61

Post by acemarke »

pookieinc wrote: post #56
acemarke wrote: post #46

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…

Is there is a similar repo of links for redux, specifically as it works with Angular? Thanks!

My links list does have a "Using Redux Without React" category page, which points to some articles on using it with Angular, Ember, etc: https://github.com/markerikson/react-redux-links/blob/master... .

That said, I'm already very busy just trying to keep up with the React+Redux community, and don't have time to keep tabs on everything that's going on in the Angular world as well. If you do find any kind of similar collection that's more focused on Angular+Redux, please let me know!

Re: How Redux Works: A Counter-Example

#62

Post by jordache »

acemarke wrote: post #53
jordache wrote: post #51

this is a relatively terrible explanation of redux when compared to this: https://code-cartoons.com/a-cartoon-intro-to-redux-3afb77550...

Lin Clark's cartoons are always excellent, but these articles serve different purposes. "A Cartoon Intro to Redux" is more about the conceptual aspects, while Dave's post is both concepts and actual code usage.

Dave's post is targeted at 'demystifying'. For this context, Lin's cartoon explanation excels.

If Dave's post was scoped to optimizing redux implementation, detailed code samples would be appropriate.

Re: How Redux Works: A Counter-Example

#63

Post by hesarenu »

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…

You could always try something simpler like mobx.

Re: How Redux Works: A Counter-Example

#64

Post by whitefish »

arximboldi wrote: post #54
whitefish wrote: post #49

Earlier quoted context omitted.

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.

Then your controller needs to know about 1) all existing views and 2) all effects of model update logic. Again, you end up with low decoupling with points that you can only change with global knowledge (and lots of potential effect interleaving). If you already have a "plain data" model, the next logical step is to just get rid of stateful controller and use a simple data-flow Redux-like flow for updating the UI. I g…

Sorry, that’s not making sense. In the MVC I am used to there’s only one controller active at one time and that controller owns the entire screen.

Re: How Redux Works: A Counter-Example

#65

Post by acemarke »

tootie wrote: post #59
acemarke wrote: post #52

Earlier quoted context omitted.

Can you clarify what you mean by "terrible interface" for Redux? What structure is "confusing"? Is this a concern with docs, the core Redux store API, the React-Redux API, or something else? Any suggestions for how we can improve things?

I think it's mostly react-redux. There's arcane boilerplate in the connect function, mapDispatchToProps looks like a leaky abstraction, actions being passed as objects with a string in them is super brittle. I don't have a fix, but I think just being able to inject a link to the store and then having an API that can be manipulated directly from the component would more comprehensible and cut down on the layers of ind…

Appreciate the feedback. Could you give specific examples of what you mean by "arcane boilerplate" and "leaky abstractions"? We don't have any plans to change the actual API, but I would genuinely be interested in any suggestions or concerns you have with it.

It's also worth noting that I personally highly recommend consistently writing separate action creator functions [0], and using the "object shorthand" argument to `connect` instead of writing a separate `mapDispatch` function.

That said, it also seems like part of what you're concerned with is the fundamental design of Redux. The use of plain object actions as a layer of indirection is deliberate [1], and it's what enables capabilities like time-travel debugging. Actions need to be serializable for that to work, and therefore strings are the best solution for the action's `type` field [2].

You certainly don't have to keep _everything_ in Redux. You should consider whether a given bit of state should live in Redux, or in a component's state [3]. But, if you _are_ going to keep data in Redux, then actions and reducers are necessary for the Redux data flow. They don't have to be in separate files [4], but they need to exist to update the store.

[0] http://blog.isquaredsoftware.com/2016/10/idiomatic-redux-why...

[1] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...

[2] https://redux.js.org/docs/faq/Actions.html#actions-string-co...

[3] https://redux.js.org/docs/faq/OrganizingState.html#organizin...

[4] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...

Re: How Redux Works: A Counter-Example

#66

Post by hakonber »

dimillian wrote: post #20

Switched our entire native app stack to a redux backend (Swift and Kotlin), never been happier. Sure there is more code in the end, but the decoupling and simplicity to use is just too good. Especially on iOS when you know how complex it is to maintain a controller hierarchy with a (now dead) dependency chain.

Did you use ReSwift and ReKotlin, or something else?

Re: How Redux Works: A Counter-Example

#67

Post by ryanbrunner »

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…

There's consensus on Redux - that's not what I'm talking about. There seems to be a fair amount of desire for something that simplifies "straightforward" state management. The Redux maintainers don't seem to be interested in this, preferring it to be something created by the community. As far as I can see though, no one is filling that gap.

Re: How Redux Works: A Counter-Example

#68

Post by ryanbrunner »

travmatt wrote: post #15
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…

Have you ever tried MobX? I haven’t tried it, but have heard it is kind of in that mid point between react state and redux

Yeah, personally I use it - I think it hits the sweet spot of making simple things simple while still allowing for complexity perfectly.

It's a shame I can't really teach it, however - the fact is, it doesn't have enough mindshare right now and part of the reason people take courses is to learn marketable skills. For better or for worse, nearly every React shop is looking for devs who know Redux.

Re: How Redux Works: A Counter-Example

#69

Post by acemarke »

ryanbrunner wrote: post #67
dceddia wrote: post #27

Earlier quoted context omitted.

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…

There's consensus on Redux - that's not what I'm talking about. There seems to be a fair amount of desire for something that simplifies "straightforward" state management. The Redux maintainers don't seem to be interested in this, preferring it to be something created by the community. As far as I can see though, no one is filling that gap.

I'm a Redux maintainer, and I'm _absolutely_ interested in making it easier for people to get started with Redux. I opened up an issue thread earlier this year to get community feedback and ideas on how we can do that: https://github.com/reactjs/redux/issues/2295 .

We don't plan to modify the Redux core itself, but I would _love_ to be able to list some tools as "approved" or "blessed" ways to get started easier.

Sadly, I just don't have enough free time to go build much of anything like that myself, but I will happily work with anyone in the community who's interested in doing so.

I also hope to revamp the Redux docs "Ecosystem" page to more specifically point to certain tools as recommended solutions to specific problems, but again haven't had time to do so yet.

Re: How Redux Works: A Counter-Example

#70

Post by arximboldi »

whitefish wrote: post #64
arximboldi wrote: post #54

Earlier quoted context omitted.

Then your controller needs to know about 1) all existing views and 2) all effects of model update logic. Again, you end up with low decoupling with points that you can only change with global knowledge (and lots of potential effect interleaving). If you already have a "plain data" model, the next logical step is to just get rid of stateful controller and use a simple data-flow Redux-like flow for updating the UI. I g…

Sorry, that’s not making sense. In the MVC I am used to there’s only one controller active at one time and that controller owns the entire screen.

We were precisely talking about composition and now you say there is only one? I guess you are talking about small apps where you have small dedicated views?

That is a very narrow definition of MVC. I am talking of large interactive software with multiple views on large hierarchical data trees data with different levels of focus and granularity. The kind of software I am thinking of big programs like Photoshop, Premiere, an IDE, Ableton Live...

Disclaimer: I worked for Ableton for quite a 5 few years, and have spent most of my career building interactive software (I work as independent consultant now). Most of the software of that time and age is built around MVC. It kinda works, but as a lot of people in the industry building software of that size will tell you: scale brings the the pain. Because of composoability. In the C++ world, see also talks from Sean Parent--who worked on Photoshop--and is also a strong proponent of "value-based" approaches (he is a great source of inspiration for me). Sean claims that something like 70% of bugs in Photoshop are in UI-related code typical MVC wiring up stuff.

In the end, just pick the right tool for the job. If you are writing small apps and MVC does not explode at that size and fits nicely with the underlying frameworks, go ahead and use it (I strongly suspect you are an iOS dev and understand how conformity with the native framworks is very important there).

But if you are building something large, highly interactive, with lots of views and concurrency, try to move to a more declarative/unidirectional flow/functional approach. It is still an open field and there are many alternative approaches, but it builds down to composability, denotational reasoning and decoupling of effects/logic.

Post reply on HN