Live data from Hacker News

Progressive React

houssein.me

51–60 of 88 posts

Re: Progressive React

#51
post #20

Earlier quoted context omitted.

Is there a way to cutdown the bloat?

Not in a substantial way. The boilerplate is a consequence of the functional “workaround”: representing a mutation as the result of applying a state transition to a complex state, and then computing what to display as a function of both the current and previous states. The way to reduce the boilerplate is to use a mutable paradigm, but then you lose the simplifications that the immutable paradigm gives you.

There's a fantastic library called Immer [0] that uses ES6 Proxies to let you write "mutative" update logic that is tracked and turned into a safe immutable update.

We recommend using Immer as the best way to write immutable logic with Redux [1], and our new Redux Toolkit package [2] automatically uses Immer internally to let you write reducers like this:

    const reducer = createReducer(initialState, {
      updateItem(state, action) {
        state.first.second[action.payload.id].fourth = action.payload.value
      }
    })

[0] https://immerjs.github.io/immer/

[1] https://redux.js.org/style-guide/style-guide/#use-immer-for-...

[2] https://redux-toolkit.js.org

Re: Progressive React

#52

As someone who has web apps in production written in backbone.js, Angular, and React, I can say selectors with Reselect to transform all the data being passed into props, Sagas to manage all async workflows, and Ramda with Redux reducers is pure fire. There is no business logic in components or containers unless it is tied directly to the view and layout, not for the data. It is such an easy way to reason about huge…

Only problem with Redux is it can be misused quite easily. The codebase at work has performance issues because of Redux, rerender issues because of reselect (not confirmed yet) and imo very very hard to read code because of Redux-Thunk. The state management was implemented by one person and everyone else is terrified of touching that part of the codebase. Im not blaming redux for this, this is clearly a problem with…

Hi, I'm a Redux maintainer. If you've got any specific concerns I can help with, I'd be happy to try to offer advice.

Out of curiosity, what issues have you been seeing with using thunks?

I'd specifically encourage you to check out our new official Redux Toolkit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once:

https://redux-toolkit.js.org

You might also want to look at the new "Style Guide" page we've added to the docs, which lists our recommended patterns and practices for using Redux:

https://redux.js.org/style-guide/style-guide

Re: Progressive React

#54

As someone who has web apps in production written in backbone.js, Angular, and React, I can say selectors with Reselect to transform all the data being passed into props, Sagas to manage all async workflows, and Ramda with Redux reducers is pure fire. There is no business logic in components or containers unless it is tied directly to the view and layout, not for the data. It is such an easy way to reason about huge…

I've had good experiences using a simple combination of lit-html and the sam pattern. I'm not an evangelist yet, I want to try and throw some more complex edge cases at it first but so far, I've had no complaints.

1. https://lit-html.polymer-project.org

2. https://sam.js.org

Re: Progressive React

#55

Earlier quoted context omitted.

Only problem with Redux is it can be misused quite easily. The codebase at work has performance issues because of Redux, rerender issues because of reselect (not confirmed yet) and imo very very hard to read code because of Redux-Thunk. The state management was implemented by one person and everyone else is terrified of touching that part of the codebase. Im not blaming redux for this, this is clearly a problem with…

Hi, I'm a Redux maintainer. If you've got any specific concerns I can help with, I'd be happy to try to offer advice. Out of curiosity, what issues have you been seeing with using thunks? I'd specifically encourage you to check out our new official Redux Toolkit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creatin…

I'm still new to redux and I'm learning using angular ngrx. I realize ngrx is just inspired by redux. What's the team relationship? Are these the same maintainers, is there a ngrx toolkit?

Re: Progressive React

#56

Earlier quoted context omitted.

Yeah, this made my whole browser lag (buttons-shading-five-seconds-after-hover-level lag). FireFox Quantum on Windows 10 with a pretty badass CPU. Also slow in Opera. Also slow in Vivaldi. And it crashed Chrome Canary. For a web-tech post, this is pretty fucking bad.

Works fine in Firefox in iOS...

Works fine in Firefox on Deepin as well.

Re: Progressive React

#57

Earlier quoted context omitted.

Only problem with Redux is it can be misused quite easily. The codebase at work has performance issues because of Redux, rerender issues because of reselect (not confirmed yet) and imo very very hard to read code because of Redux-Thunk. The state management was implemented by one person and everyone else is terrified of touching that part of the codebase. Im not blaming redux for this, this is clearly a problem with…

Hi, I'm a Redux maintainer. If you've got any specific concerns I can help with, I'd be happy to try to offer advice. Out of curiosity, what issues have you been seeing with using thunks? I'd specifically encourage you to check out our new official Redux Toolkit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creatin…

Thunks can be an anti-pattern. They encourage multiple dispatches to redux which can leave people designing "set data" style reducers rather than more meaningful ones. Parent comment suggests sagas and that's much better. An action in a component dispatches one thing and the saga can co-ordinate all of the logic.

Re: Progressive React

#58

Earlier quoted context omitted.

I’m mostly with you there but I’ve found saga to be a double-edged sword. The library offers some KILLER features and when you’ve got the right use case, it’s perfect, but it’s so easy to abuse. Because it does so much, I found myself putting more and more responsibilities on it and wound up with some very magical feeling, hard to troubleshoot code. What changed everything for me was adding GraphQL and getting the ma…

I'm a Redux maintainer. Sagas are a great power tool, but most apps don't need them [0]. We recommend that most apps stick to thunks as the default [1], and our new official Redux Toolkit package [2] adds thunks automatically to your store setup. I've used sagas in a couple apps that truly did have very complex async workflows, and they were great for that use case. But yeah, using sagas _just_ for something like dat…

As someone that had inherited a redux-thunks project, for me thunks are like calling fetch() directly inside your components callbacks, with extra steps. Really bad for testing and isolating code.

I haven't tried saga, just rxjs with redux which was definitely good. I've also worked with Elm, which supposedly inspired redux. Elm does it perfectly, I don't know why Redux missed async.

Re: Progressive React

#59

Earlier quoted context omitted.

I’m mostly with you there but I’ve found saga to be a double-edged sword. The library offers some KILLER features and when you’ve got the right use case, it’s perfect, but it’s so easy to abuse. Because it does so much, I found myself putting more and more responsibilities on it and wound up with some very magical feeling, hard to troubleshoot code. What changed everything for me was adding GraphQL and getting the ma…

I'm a Redux maintainer. Sagas are a great power tool, but most apps don't need them [0]. We recommend that most apps stick to thunks as the default [1], and our new official Redux Toolkit package [2] adds thunks automatically to your store setup. I've used sagas in a couple apps that truly did have very complex async workflows, and they were great for that use case. But yeah, using sagas _just_ for something like dat…

> I'm a Redux maintainer. Sagas are a great power tool, but most apps don't need them

I’m super happy that you’re here saying that. I’d go farther than “most apps” to “almost no apps” but, though I’ve mostly worked with apps where I wish they hadn’t used sagas, I have a lot of admiration for the saga concept and library.

Post reply on HN