11 ms·

You have a 200 KLOC React app? That's amazing to me. Just you? Is it public facing?

jbreckmckye 9y ago
If it's a Redux app, there'll be a lot of boilerplate in that. Not 200 KLOC's worth, but a fair bit. I recently inherited a moderately sized Redux app with over 1300 source files! It's not a trivial app but it's not a word processor or videogame, either...
- acemarke 9y ago
  As a Redux maintainer, I'll toss out my obligatory reminder you can use as much or as little abstraction on top of Redux as you want. Don't like writing action constants by hand? Use `redux-actions` to generate action creators that have an overriden `toString()`. Don't like touching multiple files? Use the "ducks" pattern. Want something that adds additional layers on top so you don't have to write a lot of reducers and action creators by hand? Use Kea or redux-tiles or redux-scc. I'll also post a link to the slides and livestream video for my React Boston talk this last weekend, where I talked about the Redux ecosystem and gave an overview of useful Redux libs that can help with various use cases: http://blog.isquaredsoftware.com/2017/09/presentation-might-need-redux-ecosystem/ http://blog.isquaredsoftware.com/2017/09/presentation-might-... .
  - edoloughlin 9y ago
    It's been 10 months since I last used React and I'm already way out of touch. Does anyone else feel exhausted just reading that list?
    - chrshawkes 9y ago
      yes
    - root_axis 9y ago
      I dislike this attitude. That list is not exhausting, it's a list of specific tools that solve specific problems, if you don't have the problem don't concern yourself with the tool.
      - lllr_finger 9y ago
        And this attitude is equally frustrating. Tools and libraries exist to save developers time. The cognitive overhead of building and maintaining your own framework piecemeal can be detrimental to shipping code, especially if you don't have pragmatic and decisive leadership on your team.
        root_axis 9y ago
        > And this attitude is equally frustrating It shouldn't be. If you don't like a tool, don't use it. Nobody is forcing you to use redux, you don't need it, even if you're building a complex react app, setState works just fine, seriously. > The cognitive overhead of building and maintaining your own framework piecemeal can be detrimental to shipping code So don't do that. Identify the problem, then use the tools that solve the problem, if you can't figure out which tool is the right one for the job that's your problem, not the fault of the tool. If I need to drill a hole in my wall I don't complain about how many drills are on the market, I just use the simplest tool to get the job done or hire someone who knows what they're doing > especially if you don't have pragmatic and decisive leadership on your team. The tool is not responsible for someone failing to use it correctly, that's absurd.
        lllr_finger 9y ago
        > Nobody is forcing you to use redux, you don't need it This is hand-waving to deflect Redux from legit criticisms, and is part of the reason I find both responses frustrating and unnecessarily dismissive. You need to build your own framework for React SPAs because they're intentionally un-opinionated about the pieces you use. Just look at the scaffolding in place for create react app and all the various libraries. I would much rather solve real problems than discuss how to get Immutable to play nicely with Typescript or argue thinks vs. middleware. "Get good" is a poor response to anyone wanting to see the wildly used/discussed state management solution for React get better, and implies that there aren't good devs out there with experience outside of JavaScript saying there is a better way. You're right though - there are choices. I didn't like how the JavaScript ecosystem was progressing so I made a choice to not deal with it anymore professionally and it's been a very rewarding career change.
    - vithlani 9y ago
      I hear you, brother. It is getting to the point that you seriously consider dropping the thing wholesale. This Redux offshoot discussion here is seriously affecting the positive mind share that React deserves at this point of time (licensing change and R 16).
  - vanderZwan 9y ago
    I didn't quite get redux when I first (had to) use it, and I still wonder if I'm doing it wrong, because I do 99% of my dispatches with one simple action. I ended up making a dead-simple merge(oldObj, newObj) function that's halfway between Object.assign({}, ..) and lodash.merge() (it doesn't merge arrays)[0]. It makes it easy for me to update deeply nested state trees, provided the nested data is simple enough. As a result, 99% of my dispatches uses one action type, PLAIN_MERGE, and a dumb state tree indicating what I'm updating, like so: const handleChange = (values) => { dispatch({ type: PLAIN_MERGE, state: { scatterPlots: { plotSettings: { [selectedPlot]: { [axis]: clipValues: { lowerBound: values[0], upperBound: values[1], }, }, }, }, }, }, }); }; That might be some deep nesting, but it actually reflects the structure of the interface too, so it's kinda self-documenting. The associated reducer is simply return merge(state, action.state). Again, maybe I'm missing something but it seems like a pretty simple and effective solution to me? [0] https://gist.github.com/JobLeonard/c4292594ce4d439ab20ec109f315db3f https://gist.github.com/JobLeonard/c4292594ce4d439ab20ec109f...
    - acemarke 9y ago
      That's a technically legal use of Redux. Redux doesn't care if you have an action object that only contains a type + some values and do all the work on the reducer side, or precalculate the new state before dispatching the action and have the reducer simply blindly merge in whatever was provided. Redux simply calls the root reducer function, and saves the root state value it returns. There's actually prior art for what you're doing (per the articles at [0] and [1]). The code will work, and the changes should show up in the Redux DevTools. Dan even described that as a possibility in some of the earlier Redux issues ([2], [3]). Now, having said all that: I _personally_ would say that a "single SET_STATE action" approach goes against the intended spirit of Redux. One of the core principles behind Redux is that it should make it very easy for you to understand when, why, and how your state was updated, and what part of the application triggered that state update. If you only have a single SET_STATE action type, then reading the action history log in the DevTools won't tell you much useful. You can see the action contents and the diffs, but the action log itself won't have any semantic meaning, and you can't easily trace back to where the action was dispatched because the entire codebase is dispatching the same action type. Redux also doesn't care if you do "setter-style" action naming like SET_USER_NAME and SET_USER_ADDRESS, or "event sourcing"-type naming like "USER_ATTRIBUTES_UPDATED". However, either of those approaches is going to at least provide _some_ semantic meaning, making the action log easier to read and the origin of the action easier to trace. I'd encourage you to read through the "Structuring Reducers" section in the Redux docs [4]. In particular, the "Normalizing State Shape" page [5] talks about why we recommend normalizing your data into a flatter structure, rather than keeping it nested. Finally, you might want to read through my two-part blog post "The Tao of Redux" [6], which goes into detail on the history and design of Redux, the intent for how it _should_ be used, and why common usage patterns exist. [0] https://medium.com/@jeswin/implementing-redux-is-tedious-but-it-doesnt-have-to-be-33702a1fb1dd https://medium.com/@jeswin/implementing-redux-is-tedious-but... [1] https://medium.com/@benevolentNinja/minimal-redux-setup-e6a10fcbcb68 https://medium.com/@benevolentNinja/minimal-redux-setup-e6a1... [2] https://github.com/reactjs/redux/issues/155#issuecomment-113951420 https://github.com/reactjs/redux/issues/155#issuecomment-113... [3] https://github.com/reactjs/redux/pull/140#issuecomment-113954870 https://github.com/reactjs/redux/pull/140#issuecomment-11395... [4] http://redux.js.org/docs/recipes/StructuringReducers.html http://redux.js.org/docs/recipes/StructuringReducers.html [5] http://redux.js.org/docs/recipes/reducers/NormalizingStateShape.html http://redux.js.org/docs/recipes/reducers/NormalizingStateSh... [6] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... , http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...
  - jbreckmckye 9y ago
    > As a Redux maintainer, I'll toss out my obligatory reminder you can use as much or as little abstraction on top of Redux as you want. Tell that to the previous developer. To be blunt, if your library isn't very usable without helper utils or wrappers, it probably isn't really doing its job. This is my first time using Redux, and my experience has been quite negative. This project has so many reams and reams of code that just doesn't clearly _do_ anything. Line after line of throat clearing and pseduostructure. I accept that this may just be a poorly written application. I've looked over the Express code and that's not much better, which is remarkable given that all it does is proxy API requests. But all these action creators and reducers and constants seem to have added a lot of indirection to what is still thoughtless and illiterate code. We are seriously talking about rewriting the whole thing. For a one year old project that's quite damning. Can you point me to an open source codebase that might convince me Redux-done-right makes for readable code?
    - acemarke 9y ago
      I'm sorry to hear that your experience has been negative so far. There's a commonly repeated phrase that "Redux is a pattern, not a framework". Redux doesn't have anything built in for actually updating the state, or defining an application architecture. Redux primarily provides a pattern for separating the write logic from the rest of the app conceptually, and adding centralized behavior on top of that via middleware and store enhancers. So, how you build and organize your application around that pattern is up to you. Similarly, Redux does not _require_ that you use action creators, action type constants, or that you separate everything into multiple files by code type. Those are common _conventions_. It's absolutely legal for a Redux-connected React component to do: this.props.dispatch({type : "ADD_TODO", text : "Buy milk"}) However, there _are_ reasons why those patterns exist in the first place. So, a few thoughts. First, I'd encourage you to take the time to read through my two-part blog post "The Tao of Redux" [0], which goes into detail on the history and design of Redux, the intent for how it _should_ be used, and why common usage patterns exist. Second, while I don't have a specific Redux codebase to point to as a "shining example of best practices" strictly off the top of my head, I do have a list of some selected Redux applications that may be worth looking at. Some of them are purpose-built examples, and others are "real" apps. See the list at [1] - I know that there's some good codebases in that list. I'll also suggest taking a look at "Project Mini-Mek", the sample application for my own blog tutorial series [2]. My React/Redux links list has a large section of articles discussing good Redux architecture and best practices [3]. Some of those articles might be helpful. Finally, I'd be happy to spend some time discussing your current app's codebase, and perhaps offer some suggestions on ways you can make it better or easier to deal with. HN isn't a good place for that. However, I spend most evenings hanging out in the Reactiflux chat channels on Discord. Please feel free to ping me there, and we can discuss things further. The invite link for Reactiflux is at [4]. [0] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... , http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... [1] https://github.com/markerikson/redux-ecosystem-links/blob/master/apps-and-examples.md https://github.com/markerikson/redux-ecosystem-links/blob/ma... [2] https://github.com/markerikson/project-minimek https://github.com/markerikson/project-minimek [3] https://github.com/markerikson/react-redux-links/blob/master/redux-architecture.md https://github.com/markerikson/react-redux-links/blob/master... [4] https://www.reactiflux.com https://www.reactiflux.com
  - marcins 9y ago
    Here's the links for all those things mentioned if you don't want to have to look them up like I did: https://github.com/erikras/ducks-modular-redux https://github.com/erikras/ducks-modular-redux https://github.com/keajs/kea https://github.com/keajs/kea https://redux-tiles.js.org/ https://redux-tiles.js.org/ https://github.com/TheComfyChair/redux-scc https://github.com/TheComfyChair/redux-scc https://github.com/reduxactions/redux-actions https://github.com/reduxactions/redux-actions
    - acemarke 9y ago
      Thanks! I usually try to add links to things myself, but my comment already had a whole bunch :) I'll also point out that those tools are all listed in my Redux Addons catalog at https://github.com/markerikson/redux-ecosystem-links https://github.com/markerikson/redux-ecosystem-links , albeit nested inside the different category pages, and I did just highlight them all in my ReactBoston talk over the weekend (slides and video at http://blog.isquaredsoftware.com/2017/09/presentation-might-need-redux-ecosystem/ http://blog.isquaredsoftware.com/2017/09/presentation-might-... ).
  - darknoon 9y ago
    I’ve spent a few months writing code in a moderately large redux app and hadn’t heard of any of these. Maybe more could be done to call them out in redux docs?
    - acemarke 9y ago
      Agreed. I made a comment elsewhere in the thread linking to an issue I filed for revamping the "Ecosystem" page, and asking for help from the community to improve the docs (since my own free time is limited): https://news.ycombinator.com/item?id=15343818 https://news.ycombinator.com/item?id=15343818 . You may also want to check out my React Boston talk about the Redux ecosystem, also linked upthread: https://news.ycombinator.com/item?id=15342225 https://news.ycombinator.com/item?id=15342225 .
- b34r 9y ago
  Oh ffs.

If it's a Redux app, there'll be a lot of boilerplate in that. Not 200 KLOC's worth, but a fair bit. I recently inherited a moderately sized Redux app with over 1300 source files! It's not a trivial app but it's not a word processor or videogame, either...

acemarke 9y ago
As a Redux maintainer, I'll toss out my obligatory reminder you can use as much or as little abstraction on top of Redux as you want. Don't like writing action constants by hand? Use `redux-actions` to generate action creators that have an overriden `toString()`. Don't like touching multiple files? Use the "ducks" pattern. Want something that adds additional layers on top so you don't have to write a lot of reducers and action creators by hand? Use Kea or redux-tiles or redux-scc. I'll also post a link to the slides and livestream video for my React Boston talk this last weekend, where I talked about the Redux ecosystem and gave an overview of useful Redux libs that can help with various use cases: http://blog.isquaredsoftware.com/2017/09/presentation-might-need-redux-ecosystem/ http://blog.isquaredsoftware.com/2017/09/presentation-might-... .
- edoloughlin 9y ago
  It's been 10 months since I last used React and I'm already way out of touch. Does anyone else feel exhausted just reading that list?
  - chrshawkes 9y ago
    yes
  - root_axis 9y ago
    I dislike this attitude. That list is not exhausting, it's a list of specific tools that solve specific problems, if you don't have the problem don't concern yourself with the tool.
    - lllr_finger 9y ago
      And this attitude is equally frustrating. Tools and libraries exist to save developers time. The cognitive overhead of building and maintaining your own framework piecemeal can be detrimental to shipping code, especially if you don't have pragmatic and decisive leadership on your team.
      - root_axis 9y ago
        > And this attitude is equally frustrating It shouldn't be. If you don't like a tool, don't use it. Nobody is forcing you to use redux, you don't need it, even if you're building a complex react app, setState works just fine, seriously. > The cognitive overhead of building and maintaining your own framework piecemeal can be detrimental to shipping code So don't do that. Identify the problem, then use the tools that solve the problem, if you can't figure out which tool is the right one for the job that's your problem, not the fault of the tool. If I need to drill a hole in my wall I don't complain about how many drills are on the market, I just use the simplest tool to get the job done or hire someone who knows what they're doing > especially if you don't have pragmatic and decisive leadership on your team. The tool is not responsible for someone failing to use it correctly, that's absurd.
        lllr_finger 9y ago
        > Nobody is forcing you to use redux, you don't need it This is hand-waving to deflect Redux from legit criticisms, and is part of the reason I find both responses frustrating and unnecessarily dismissive. You need to build your own framework for React SPAs because they're intentionally un-opinionated about the pieces you use. Just look at the scaffolding in place for create react app and all the various libraries. I would much rather solve real problems than discuss how to get Immutable to play nicely with Typescript or argue thinks vs. middleware. "Get good" is a poor response to anyone wanting to see the wildly used/discussed state management solution for React get better, and implies that there aren't good devs out there with experience outside of JavaScript saying there is a better way. You're right though - there are choices. I didn't like how the JavaScript ecosystem was progressing so I made a choice to not deal with it anymore professionally and it's been a very rewarding career change.
  - vithlani 9y ago
    I hear you, brother. It is getting to the point that you seriously consider dropping the thing wholesale. This Redux offshoot discussion here is seriously affecting the positive mind share that React deserves at this point of time (licensing change and R 16).
- vanderZwan 9y ago
  I didn't quite get redux when I first (had to) use it, and I still wonder if I'm doing it wrong, because I do 99% of my dispatches with one simple action. I ended up making a dead-simple merge(oldObj, newObj) function that's halfway between Object.assign({}, ..) and lodash.merge() (it doesn't merge arrays)[0]. It makes it easy for me to update deeply nested state trees, provided the nested data is simple enough. As a result, 99% of my dispatches uses one action type, PLAIN_MERGE, and a dumb state tree indicating what I'm updating, like so: const handleChange = (values) => { dispatch({ type: PLAIN_MERGE, state: { scatterPlots: { plotSettings: { [selectedPlot]: { [axis]: clipValues: { lowerBound: values[0], upperBound: values[1], }, }, }, }, }, }, }); }; That might be some deep nesting, but it actually reflects the structure of the interface too, so it's kinda self-documenting. The associated reducer is simply return merge(state, action.state). Again, maybe I'm missing something but it seems like a pretty simple and effective solution to me? [0] https://gist.github.com/JobLeonard/c4292594ce4d439ab20ec109f315db3f https://gist.github.com/JobLeonard/c4292594ce4d439ab20ec109f...
  - acemarke 9y ago
    That's a technically legal use of Redux. Redux doesn't care if you have an action object that only contains a type + some values and do all the work on the reducer side, or precalculate the new state before dispatching the action and have the reducer simply blindly merge in whatever was provided. Redux simply calls the root reducer function, and saves the root state value it returns. There's actually prior art for what you're doing (per the articles at [0] and [1]). The code will work, and the changes should show up in the Redux DevTools. Dan even described that as a possibility in some of the earlier Redux issues ([2], [3]). Now, having said all that: I _personally_ would say that a "single SET_STATE action" approach goes against the intended spirit of Redux. One of the core principles behind Redux is that it should make it very easy for you to understand when, why, and how your state was updated, and what part of the application triggered that state update. If you only have a single SET_STATE action type, then reading the action history log in the DevTools won't tell you much useful. You can see the action contents and the diffs, but the action log itself won't have any semantic meaning, and you can't easily trace back to where the action was dispatched because the entire codebase is dispatching the same action type. Redux also doesn't care if you do "setter-style" action naming like SET_USER_NAME and SET_USER_ADDRESS, or "event sourcing"-type naming like "USER_ATTRIBUTES_UPDATED". However, either of those approaches is going to at least provide _some_ semantic meaning, making the action log easier to read and the origin of the action easier to trace. I'd encourage you to read through the "Structuring Reducers" section in the Redux docs [4]. In particular, the "Normalizing State Shape" page [5] talks about why we recommend normalizing your data into a flatter structure, rather than keeping it nested. Finally, you might want to read through my two-part blog post "The Tao of Redux" [6], which goes into detail on the history and design of Redux, the intent for how it _should_ be used, and why common usage patterns exist. [0] https://medium.com/@jeswin/implementing-redux-is-tedious-but-it-doesnt-have-to-be-33702a1fb1dd https://medium.com/@jeswin/implementing-redux-is-tedious-but... [1] https://medium.com/@benevolentNinja/minimal-redux-setup-e6a10fcbcb68 https://medium.com/@benevolentNinja/minimal-redux-setup-e6a1... [2] https://github.com/reactjs/redux/issues/155#issuecomment-113951420 https://github.com/reactjs/redux/issues/155#issuecomment-113... [3] https://github.com/reactjs/redux/pull/140#issuecomment-113954870 https://github.com/reactjs/redux/pull/140#issuecomment-11395... [4] http://redux.js.org/docs/recipes/StructuringReducers.html http://redux.js.org/docs/recipes/StructuringReducers.html [5] http://redux.js.org/docs/recipes/reducers/NormalizingStateShape.html http://redux.js.org/docs/recipes/reducers/NormalizingStateSh... [6] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... , http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...
- jbreckmckye 9y ago
  > As a Redux maintainer, I'll toss out my obligatory reminder you can use as much or as little abstraction on top of Redux as you want. Tell that to the previous developer. To be blunt, if your library isn't very usable without helper utils or wrappers, it probably isn't really doing its job. This is my first time using Redux, and my experience has been quite negative. This project has so many reams and reams of code that just doesn't clearly _do_ anything. Line after line of throat clearing and pseduostructure. I accept that this may just be a poorly written application. I've looked over the Express code and that's not much better, which is remarkable given that all it does is proxy API requests. But all these action creators and reducers and constants seem to have added a lot of indirection to what is still thoughtless and illiterate code. We are seriously talking about rewriting the whole thing. For a one year old project that's quite damning. Can you point me to an open source codebase that might convince me Redux-done-right makes for readable code?
  - acemarke 9y ago
    I'm sorry to hear that your experience has been negative so far. There's a commonly repeated phrase that "Redux is a pattern, not a framework". Redux doesn't have anything built in for actually updating the state, or defining an application architecture. Redux primarily provides a pattern for separating the write logic from the rest of the app conceptually, and adding centralized behavior on top of that via middleware and store enhancers. So, how you build and organize your application around that pattern is up to you. Similarly, Redux does not _require_ that you use action creators, action type constants, or that you separate everything into multiple files by code type. Those are common _conventions_. It's absolutely legal for a Redux-connected React component to do: this.props.dispatch({type : "ADD_TODO", text : "Buy milk"}) However, there _are_ reasons why those patterns exist in the first place. So, a few thoughts. First, I'd encourage you to take the time to read through my two-part blog post "The Tao of Redux" [0], which goes into detail on the history and design of Redux, the intent for how it _should_ be used, and why common usage patterns exist. Second, while I don't have a specific Redux codebase to point to as a "shining example of best practices" strictly off the top of my head, I do have a list of some selected Redux applications that may be worth looking at. Some of them are purpose-built examples, and others are "real" apps. See the list at [1] - I know that there's some good codebases in that list. I'll also suggest taking a look at "Project Mini-Mek", the sample application for my own blog tutorial series [2]. My React/Redux links list has a large section of articles discussing good Redux architecture and best practices [3]. Some of those articles might be helpful. Finally, I'd be happy to spend some time discussing your current app's codebase, and perhaps offer some suggestions on ways you can make it better or easier to deal with. HN isn't a good place for that. However, I spend most evenings hanging out in the Reactiflux chat channels on Discord. Please feel free to ping me there, and we can discuss things further. The invite link for Reactiflux is at [4]. [0] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... , http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... [1] https://github.com/markerikson/redux-ecosystem-links/blob/master/apps-and-examples.md https://github.com/markerikson/redux-ecosystem-links/blob/ma... [2] https://github.com/markerikson/project-minimek https://github.com/markerikson/project-minimek [3] https://github.com/markerikson/react-redux-links/blob/master/redux-architecture.md https://github.com/markerikson/react-redux-links/blob/master... [4] https://www.reactiflux.com https://www.reactiflux.com
- marcins 9y ago
  Here's the links for all those things mentioned if you don't want to have to look them up like I did: https://github.com/erikras/ducks-modular-redux https://github.com/erikras/ducks-modular-redux https://github.com/keajs/kea https://github.com/keajs/kea https://redux-tiles.js.org/ https://redux-tiles.js.org/ https://github.com/TheComfyChair/redux-scc https://github.com/TheComfyChair/redux-scc https://github.com/reduxactions/redux-actions https://github.com/reduxactions/redux-actions
  - acemarke 9y ago
    Thanks! I usually try to add links to things myself, but my comment already had a whole bunch :) I'll also point out that those tools are all listed in my Redux Addons catalog at https://github.com/markerikson/redux-ecosystem-links https://github.com/markerikson/redux-ecosystem-links , albeit nested inside the different category pages, and I did just highlight them all in my ReactBoston talk over the weekend (slides and video at http://blog.isquaredsoftware.com/2017/09/presentation-might-need-redux-ecosystem/ http://blog.isquaredsoftware.com/2017/09/presentation-might-... ).
- darknoon 9y ago
  I’ve spent a few months writing code in a moderately large redux app and hadn’t heard of any of these. Maybe more could be done to call them out in redux docs?
  - acemarke 9y ago
    Agreed. I made a comment elsewhere in the thread linking to an issue I filed for revamping the "Ecosystem" page, and asking for help from the community to improve the docs (since my own free time is limited): https://news.ycombinator.com/item?id=15343818 https://news.ycombinator.com/item?id=15343818 . You may also want to check out my React Boston talk about the Redux ecosystem, also linked upthread: https://news.ycombinator.com/item?id=15342225 https://news.ycombinator.com/item?id=15342225 .
b34r 9y ago
Oh ffs.