3 ms·

This looks really great, and I've got an immediate use for something like this. I've been using ag-grid for presentation of grid-based data, but this looks ide

by uptown 10y ago

This looks really great, and I've got an immediate use for something like this. I've been using ag-grid for presentation of grid-based data, but this looks ideal for more-interactive views. I look forward to putting it through its paces. Somewhat off-topic, but for those working in React, have you built large systems using Redux? I'm fairly early in what is likely to ultimately be a large-ish application, and while I've got Redux working, I feel working with it is definitely adding cognitive load to each feature I implement. Just wondering whether it's worth the effort and would appreciate feedback from those who may have more experience weighing the pros and cons of using Redux with their application.

Etheryte 10y ago
It's important to remember that not all of your state needs to be in Redux. Redux is supposed to supplement local state, not replace it. Create namespaces in your store, it helps a ton with maintainability in the long run. Name your mutations consistently: describe what you're doing to what kind of data as briefly as you can. Keeping these few guidelines in mind, building huge applications using any flux-like pattern is quite straight-forward and easy to reason about.
lpa22 10y ago
I have made several relatively large systems using Redux, and it has become a necessity in order to handle complexity of new features. Overcoming the initial cognitive load takes a week or two, but as your system grows, your productivity and code organization is greatly improved. I also recommend Immutable for handling the state object and reselect for computing your container state properties. Those technologies together are a pleasure to develop with.
- rattray 10y ago
  How does https://github.com/kolodny/immutability-helper https://github.com/kolodny/immutability-helper compare to Immutable in your experience? The latter seems potentially more performant and lighter-weight; curious what its disadvantages might be (the syntax?)
  - acemarke 10y ago
    I personally recommend against using Immutable.js, for a number of reasons (which I wrote as a Reddit comment a while ago [0] ). There's some additional info on Immutable.js-related perf in my links list [1] FYI, there's also a bunch of other immutable update utility libs besides immutability-helper. I have a list of them in my Redux addons catalog [2]. [0] https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abramov_redux_is_not_an_architecture_or/d51g4k4?context=3 https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra... [1] https://github.com/markerikson/react-redux-links/blob/master/react-performance.md#immutable-data https://github.com/markerikson/react-redux-links/blob/master... [2] https://github.com/markerikson/redux-ecosystem-links/blob/master/immutable-data.md#immutable-update-utilities https://github.com/markerikson/redux-ecosystem-links/blob/ma...
    - rattray 10y ago
      Interesting, thanks for sharing. I took a look at your list of links recently, actually – it was helpful. I'm considering syntax-level support for `immutability-helper`, which seems like the best all-around solution aside from its syntax. This is for a JS Dialect I'm building called LightScript[0]. Would look something like: store.people[0].friends[0].name~~set("Alice") which would compile to: update(store, { people: { [0]: { friends: { [0]: { name: { $set: "Alice" } } } } } }) Would love thoughts/feedback (here or on the project Gitter[1]) [0] http://lightscript.org http://lightscript.org [1] https://gitter.im/lightscript/Lobby https://gitter.im/lightscript/Lobby
      - helb 10y ago
        One thing i like about immutability-helper is their mongo-style syntax. Yeah, MongoDB might kinda suck for multiple reasons, but the query syntax is quite nice IMO.
acemarke 10y ago
Redux does deliberately add some indirection and overhead to things, but that tends to stay constant as the app increases in complexity. In other words, if you're just writing a TodoMVC app, then it's probably going to seem like a pain. As the app scales, the consistency and behavior usually winds up as a net benefit. The Redux FAQ has an entry on "scaling" [0], and my React/Redux links list has a large section on Redux architecture and best practices [1]. [0] http://redux.js.org/docs/faq/Performance.html#performance-scaling http://redux.js.org/docs/faq/Performance.html#performance-sc... [1] https://github.com/markerikson/react-redux-links/blob/master/redux-architecture.md https://github.com/markerikson/react-redux-links/blob/master...
kcorbitt 10y ago
I've built a relatively large React app using Redux for state management. Etheryte's point is valid -- if state is only used within a single component (or maybe shared with its immediate children), you're probably better off leaving it local to that component. And if it turns out you're wrong later and actually do need it somewhere else you can refactor and pull it into Redux at that time. If you have more than a few bits of state to manage, use multiple reducers and split your state into logical groups. Within each reducer, I use immutable.js `Record`s as the main state container. I also use Flow to strongly-type these reducers and get autocomplete and type checking of my state, but the benefits of that are mostly orthogonal to the benefits of using Redux. You should almost never try to "denormalize" data (store the same thing in multiple places) or eg. use Redux state to initialize a component's local state. Trying to keep these in sync will kill your mental model. Instead, use selectors to keep components in sync, and if a particular view is costly to compute as a function of your state you can memoize it (I use https://github.com/reactjs/reselect https://github.com/reactjs/reselect for that). But that's extra complexity that should only be added in the few cases that warrant it. I found that by organizing my code this way I was able to keep the parts of the app that I needed to make any particular change in my head easily, which did incredible things for developer velocity and happiness. :)
hakanito 10y ago
I just refactored our fairly large (15k LoC) redux codebase into MobX for exactly this reason. Result, shaved off 10k LoC and started enjoying dev life again

by uptown 10y ago

Etheryte 10y ago

It's important to remember that not all of your state needs to be in Redux. Redux is supposed to supplement local state, not replace it. Create namespaces in your store, it helps a ton with maintainability in the long run. Name your mutations consistently: describe what you're doing to what kind of data as briefly as you can. Keeping these few guidelines in mind, building huge applications using any flux-like pattern is quite straight-forward and easy to reason about.

lpa22 10y ago

I have made several relatively large systems using Redux, and it has become a necessity in order to handle complexity of new features. Overcoming the initial cognitive load takes a week or two, but as your system grows, your productivity and code organization is greatly improved. I also recommend Immutable for handling the state object and reselect for computing your container state properties. Those technologies together are a pleasure to develop with.

rattray 10y ago
How does https://github.com/kolodny/immutability-helper https://github.com/kolodny/immutability-helper compare to Immutable in your experience? The latter seems potentially more performant and lighter-weight; curious what its disadvantages might be (the syntax?)
- acemarke 10y ago
  I personally recommend against using Immutable.js, for a number of reasons (which I wrote as a Reddit comment a while ago [0] ). There's some additional info on Immutable.js-related perf in my links list [1] FYI, there's also a bunch of other immutable update utility libs besides immutability-helper. I have a list of them in my Redux addons catalog [2]. [0] https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abramov_redux_is_not_an_architecture_or/d51g4k4?context=3 https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra... [1] https://github.com/markerikson/react-redux-links/blob/master/react-performance.md#immutable-data https://github.com/markerikson/react-redux-links/blob/master... [2] https://github.com/markerikson/redux-ecosystem-links/blob/master/immutable-data.md#immutable-update-utilities https://github.com/markerikson/redux-ecosystem-links/blob/ma...
  - rattray 10y ago
    Interesting, thanks for sharing. I took a look at your list of links recently, actually – it was helpful. I'm considering syntax-level support for `immutability-helper`, which seems like the best all-around solution aside from its syntax. This is for a JS Dialect I'm building called LightScript[0]. Would look something like: store.people[0].friends[0].name~~set("Alice") which would compile to: update(store, { people: { [0]: { friends: { [0]: { name: { $set: "Alice" } } } } } }) Would love thoughts/feedback (here or on the project Gitter[1]) [0] http://lightscript.org http://lightscript.org [1] https://gitter.im/lightscript/Lobby https://gitter.im/lightscript/Lobby
    - helb 10y ago
      One thing i like about immutability-helper is their mongo-style syntax. Yeah, MongoDB might kinda suck for multiple reasons, but the query syntax is quite nice IMO.

acemarke 10y ago

Redux does deliberately add some indirection and overhead to things, but that tends to stay constant as the app increases in complexity. In other words, if you're just writing a TodoMVC app, then it's probably going to seem like a pain. As the app scales, the consistency and behavior usually winds up as a net benefit. The Redux FAQ has an entry on "scaling" [0], and my React/Redux links list has a large section on Redux architecture and best practices [1]. [0] http://redux.js.org/docs/faq/Performance.html#performance-scaling http://redux.js.org/docs/faq/Performance.html#performance-sc... [1] https://github.com/markerikson/react-redux-links/blob/master/redux-architecture.md https://github.com/markerikson/react-redux-links/blob/master...

kcorbitt 10y ago

I've built a relatively large React app using Redux for state management. Etheryte's point is valid -- if state is only used within a single component (or maybe shared with its immediate children), you're probably better off leaving it local to that component. And if it turns out you're wrong later and actually do need it somewhere else you can refactor and pull it into Redux at that time. If you have more than a few bits of state to manage, use multiple reducers and split your state into logical groups. Within each reducer, I use immutable.js `Record`s as the main state container. I also use Flow to strongly-type these reducers and get autocomplete and type checking of my state, but the benefits of that are mostly orthogonal to the benefits of using Redux. You should almost never try to "denormalize" data (store the same thing in multiple places) or eg. use Redux state to initialize a component's local state. Trying to keep these in sync will kill your mental model. Instead, use selectors to keep components in sync, and if a particular view is costly to compute as a function of your state you can memoize it (I use https://github.com/reactjs/reselect https://github.com/reactjs/reselect for that). But that's extra complexity that should only be added in the few cases that warrant it. I found that by organizing my code this way I was able to keep the parts of the app that I needed to make any particular change in my head easily, which did incredible things for developer velocity and happiness. :)

hakanito 10y ago

I just refactored our fairly large (15k LoC) redux codebase into MobX for exactly this reason. Result, shaved off 10k LoC and started enjoying dev life again