When a rewrite isn’t: rebuilding Slack on the desktop

Re:When a rewrite isn’t: rebuilding Slack on the desktop by jscheel on Monday July 22, 2019 @02:34PM (#20500852)

Thanks for the articles! We've been using Redux since August of 2016 at Groove. For us, we've found that Redux makes sense when you have state that needs to be shared. If you are dealing with some specific, tightly coupled component state, it sometimes makes sense to keep that particular piece of state local to the component (at least for our use-case). The biggest issues we've run into during our time with Redux have been 1. not being atomic enough with our connected components (sometimes passing massive objects down the component tree instead of selecting what we need at each point), 2. running into leakiness in react-redux (such as function arity changing short-circuit caching behavior in the mapping functions, forgetting to invalidate components when using select factories, etc), and 3. not normalizing our store enough (which contributes to #1). As we continue to mature in Redux, we are slowly fixing #1 and #3 in our codebase. We are still sometimes getting bitten by weirdness in react-redux though. I'm not sure I have a solution, but I think there is still a lot of opportunity for improvement there. And not just in react-redux, in helping developers understand how to properly build performant redux-driven apps in general.

[ Parent | on HN ]

Re:When a rewrite isn’t: rebuilding Slack on the desktop by acemarke on Monday July 22, 2019 @02:47PM (#20501006)

Yep. The Redux "Three Principles" docs page [0] emphasizes the "single source of truth" aspect. It's a good selling point, but has unfortunately led to a lot of folks interpreting that as "you _must_ keep _everything_ in Redux". (Doing so is a valid design decision, and I've certainly talked to folks who deliberately did that to make everything trackable and time-travel-able. But, most UI state probably doesn't need to go in Redux, particularly form state [1].)

In reality, there should be a good balance between global and local state. I wrote a Redux FAQ entry that tries to give some rules of thumb for determining what state goes where [2].

When we do the docs revamp, hopefully we can make that kind of thinking more explicit.

I'd be very interested in hearing more details on any issues you may be having with React-Redux, and I'm happy to offer advice for you or anyone else on using it better. HN comments aren't a great place for that, but please file an issue for discussion or contact me in the Reactiflux chat channels on Discord in the #redux channel.

I'd also greatly appreciate any feedback folks would have on weaknesses with the current docs, so we can improve those issues with the docs revamp.

We've had open issues to cover writing a "Performance" docs page for a long time, but no one got around to contributing that, and there's been too many other higher priorities for us to write it. My React/Redux links list does have a section of articles on improving Redux perf [3], if that helps, and there's an FAQ section on that topic [4]. In general, connect more components [5], and use memoized selectors [6] to read data and do transforms.

[0] https://redux.js.org/introduction/three-principles

[1] https://redux.js.org/faq/organizing-state#should-i-put-form-...

[2] https://redux.js.org/faq/organizing-state#do-i-have-to-put-a...

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

[4] https://redux.js.org/faq/performance

[5] https://redux.js.org/faq/react-redux#should-i-only-connect-m...

[6] https://blog.isquaredsoftware.com/2017/12/idiomatic-redux-us...

[ Parent | on HN ]

Re:When a rewrite isn’t: rebuilding Slack on the desktop by azernik on Monday July 22, 2019 @06:05PM (#20502742)

> The Redux "Three Principles" docs page [0] emphasizes the "single source of truth" aspect. It's a good selling point, but has unfortunately led to a lot of folks interpreting that as "you _must_ keep _everything_ in Redux".

After a couple of years working with Redux, I think my interpretation has settled down to:

Redux should be the single source of truth for the pieces of information you decide to put in there.

[ Parent | on HN ]

Re:When a rewrite isn’t: rebuilding Slack on the desktop by acemarke on Monday July 22, 2019 @06:14PM (#20502794)

Exactly! I've used literally that phrase in some of the talks that I've done. We clearly will need to include that in the revamped docs.

[ Parent | on HN ]

Re:When a rewrite isn’t: rebuilding Slack on the desktop by fnordsensei on Monday July 22, 2019 @05:26PM (#20502473)

I recently came to the conclusion that I’ve been going a bit overboard with this in ClojureScript's (let’s call it equivalent) version of Redux, re-frame.

Rather than putting absolutely everything in the global DB, I now try to restrict that to things that are actually global, such as the user profile data and such.

[ Parent | on HN ]

Re:When a rewrite isn’t: rebuilding Slack on the desktop by jscheel on Monday July 22, 2019 @03:32PM (#20501488)

Awesome, I'll hit you up in Discord.

[ Parent | on HN ]