redux

Sure! If you'd like to look at our plans and discussions, see these issues: https://github.com/reduxjs/redux/issues/2590 https://github.com/reduxjs/redux/issues/3313 I'm particularly hoping to do some brainstorming about the revamped docs structure and content over the next couple days.

Hi, I'm a Redux maintainer. The Redux FAQ specifically has an entry with rules of thumb to help decide when it makes sense to keep a given piece of state in Redux [0]. I do agree that the "Single Source of Truth" principle [1] is probably over-interpreted, and maybe needs some caveats somehow. That said, it's tough to simultaneously say "here's the basics of how Redux works", "here's the ideas behind why you _should_ use Redux", and also try to tell people when to _not_ use Redux. We're currently planning a revamp of the Redux docs content [2]. I'd appreciate it if you could fill out this survey on how we can improve the docs structure [3], or leave a comment in that issue thread with some suggestions. [0] https://redux.js.org/faq/organizing-state#do-i-have-to-put-a... [1] https://redux.js.org/introduction/three-principles [2] https://g

Yes, absolutely! Per my other comment in this thread [0], please check out our `redux-starter-kit` package [1]. I'd appreciate any feedback on whether or not it helps you, and what other capabilities would be beneficial to include. Lots of people throw around the word "boilerplate", but everyone seems to mean something different by it [2]. Can you clarify what _specific_ things you mean by that? [0] https://news.ycombinator.com/item?id=18605421 [1] https://github.com/reduxjs/redux-starter-kit [2] https://github.com/reduxjs/redux/issues/2295

We've got a work-in-progress PR on adding a docs page to discuss using TS with Redux: https://github.com/reduxjs/redux/pull/3201 . But, neither Tim nor I use TS ourselves (yet), so we're not experts and don't have the expertise to write this ourselves, or maintain the typings. That's gotta come from the community. The React-Redux typings are separate, in Definitely Typed. We're considering moving the Redux typings over there as well.

Since it's a Redux-related thread, I'll toss out one other sub-thread to let people know what we're working on, and ask for feedback. We've already completely revamped the React-Redux docs [0]. They're now published as a separate site, and we're writing all-new content, like guides on how to best use `connect`. There's plenty more topics we plan to cover, but it's a big improvement already. Meanwhile, we're also working on a new build setup for the Redux core docs. Once that's ready, we'll turn our attention to actually revamping the actual Redux docs content and structure. (There's an existing issue if you'd like some info on some of the plans [1]). So, with that in mind, I'd specifically like to ask: - What do you think are the biggest strengths and weakness of the current Redux docs at https://redux.js.org ? - What topics do we do

Hi, I'm a Redux maintainer. FWIW, a lot of people tell us Redux's docs are "great", but we've also had people tell us they aren't helpful. Kinda hard to figure out how to make improvements based on that kind of conflicting feedback :) We are actually looking at revamping the Redux docs in the near future [0]. If you've got any specific concerns or suggestions on how we can improve things, please let me know directly, or comment on that issue. Also, besides the docs, you may be interested in my suggested resources for learning Redux [1], including my own Redux workshop slides [2]. [0] https://github.com/reduxjs/redux/issues/2590 [1] http://blog.isquaredsoftware.com/2017/12/blogged-answers-lea... [2] https://blog.isquaredsoftware.com/2018/06/redux-fundamentals...

Hi, I'm a Redux maintainer. FWIW, we're looking at revamping the Redux docs in the near future (see https://github.com/reduxjs/redux/issues/2590 for plans ). If you've got any specific suggestions for improvements, please let us know! I'm always looking for ways we can make the docs better. As a side note, React is separate from Redux, and Redux is definitely not tied to React. Here's a recent post about a team that opted to use Redux with Vue: https://snipcart.com/blog/redux-vue .

It's because Redux was specifically written as "just another library implementing the Flux Architecture", and Flux used the term "action". See Dan's comments at https://github.com/reduxjs/redux/issues/891#issuecomment-147... and https://github.com/reduxjs/redux/issues/377#issuecomment-126... for justification and links to prior discussions.

Can't say I've seen enough to be confident on the best library but redux (https://github.com/reduxjs/redux) is just so simple, and has great, readable/understandable code.

I'm a Redux maintainer. FWIW, I'm always open to suggestions on how we can make using Redux easier and better for everyone (example prior discussion: https://github.com/reactjs/redux/issues/2295 ). We're currently working on a "starter kit" package that's intended to address some of the most common concerns about using Redux, and hope to make it an official Redux-branded package in the near future. I'd appreciate any feedback or ideas you have for improving it: https://github.com/markerikson/redux-starter-kit Also, since you mention stack traces: if anyone out there has a bit of free time on their hands, I'd _love_ to see the Redux DevTools core and extension updated to show a stack trace for where each action was dispatched: https://github.com/zalmoxisus/redux-devtools-extension/issue...

Yes, Redux by itself knows nothing about React. But, the vast majority of Redux users are using React, and it's a reasonable shorthand to just say "Redux" in this case. It's also how most end users would tend to refer to things. FYI, I'm a Redux maintainer. We are currently working on an internal refactoring of React-Redux's `connect` so that it will use the new `React.createContext` API instead of legacy context. We've got two open PRs with "competing" reimplementations, and I will actually be spending the rest of today hacking on those. The immediate goal is to make React-Redux at least compatible with React's upcoming "async rendering" capabilities. However, we do have some difficult problems to solve in order for Redux to take full advantage of the "Suspense" feature. We've got a decent idea what the problem space is, but we nee

Yep, sorry I should have included the reference. This post is by the redux-form creator, in which he states why it was a bad idea, and announces its 'spiritual successor': https://codeburst.io/final-form-the-road-to-the-checkered-fl... > Also, everyone high up in the React community, including both inventors of Redux [1], say that Redux is not the best place to keep form data. Oops. [1] https://github.com/reactjs/redux/issues/1287#issuecomment-17...

That must have been a pretty tight time window :) Per the releases page at https://github.com/reduxjs/redux/releases?after=v3.0.1 , you can see that 2.0 and 3.0 were only a couple weeks apart, and basically just tightened up the API around hot-swapping the root reducer. Since then, the most meaningful API change was 3.1.0, which redid the `createStore` signature to allow passing an enhancer as an argument (as opposed to the original more FP-style approach).

This is the thing that everyone seems to have forgotten. Redux didn't invent these terms out of nothing. Redux was specifically written as an implementation of the Flux Architecture, and the terms "store", "action", and "type" came directly from Flux. The term "reducer" had been in use with Clojure already, I think, and is based on the way these functions have the same signature as a callback you pass to `Array.prototype.reduce`. "State" is a generic term meaning "data in your app", and the term "tree" for a hierarchy of objects has been around for ever. (Oh, and you can write your reducer functions with _whatever conditional logic you want_ - switch statements just happen to be an obvious way to handle multiple values for a single field.) I covered a lot of the history and thought behind Redux's design in my post "The Tao of Redux,