Learn how to use Redux step-by-step • Hacker News Board

Re: Learn how to use Redux step-by-step

#31

Post by acemarke » Sun, Sep 10, 2017, 2:31 PM UTC

tehlike wrote: post #28

always_good wrote: post #20

Earlier quoted context omitted.

One benefit is that you have explicit events that create specific state changes. Your app is a succession of these events that certainly help when debugging and thinking about the potential states your app can be in. Like other state management solutions, it also 'writes' all your shouldComponentUpdate methods for you.

Sounds like event sourcing, for ui.

There's been many comparisons made to event sourcing, but the actual semantics of the dispatched actions are up to you. You might dispatch `USER_LOGGED_IN`, or you could dispatch `SET_USER_LOGGED_IN_STATUS` (ie, "past-tense event that occurred" vs "present-tense imperative set some state"). Redux doesn't care how you name your actions. There's been lots of arguments over how action semantics should be viewed. I recapped some of the discussion in my post 'The Tao of Redux, Part 2 - Practice and Philosophy" ( http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... ).

Re: Learn how to use Redux step-by-step

#32

Post by tehlike » Sun, Sep 10, 2017, 3:38 PM UTC

acemarke wrote: post #31

tehlike wrote: post #28

Earlier quoted context omitted.

Sounds like event sourcing, for ui.

There's been many comparisons made to event sourcing, but the actual semantics of the dispatched actions are up to you. You might dispatch `USER_LOGGED_IN`, or you could dispatch `SET_USER_LOGGED_IN_STATUS` (ie, "past-tense event that occurred" vs "present-tense imperative set some state"). Redux doesn't care how you name your actions. There's been lots of arguments over how action semantics should be viewed. I recap…

Sure, with event sourcing there is another level of difference between commands, query, events. But the similarity is there.

Re: Learn how to use Redux step-by-step

#33

Post by devdad » Sun, Sep 10, 2017, 7:26 PM UTC

eropple wrote: post #30

devdad wrote: post #23

Earlier quoted context omitted.

Not the one being asked, but I usually go with breakpoints in Dev Tools.

Breakpoints cannot replay . They can pause and continue playing. The inability to examine a time series of data after-the-fact and resume from any point makes this approach significantly, significantly worse. Like, I've done it just as you have, and I'd under no circumstances go back. It's so bad that I've basically built action-pattern systems in other languages (before using Redux, actually). Functional tooling and…

I guess you must be having a whole different set of problems than me. I also use Redux, have not found time travel to be a boost to my productivity. I choose Redux because of the simplicity around state management, and having it all centralised in a store is a nice pattern. (Don't really get other commenters claiming that this isn't new - I don't see the relevance).