Develop Reference

Multiple todo lists in a React Application (parent -> child relationships)

I have found a serious flaw I think in ReactJS. Although I admit this flaw perhaps might be a flaw in my understanding :) I am trying to build a simple Todo application (using TodoMVC), and when you try to use something like Redux for state managment, you run into very, very hairy issues when trying to process nested JSON, i.e. a database response that typically would include a parent node ("projects"> and then child nodes "todos") related to the parent.
Redux seems to want you to "normalize" the data from the response so it's immuatable. Not to upset anyone, but this seems like the most ridiculous thing in the universe. So, we build a SPA app to process json responses from our data....and then...oh wait, we have to build an ORM on the client to munge all that data into a different format to process it.
If this is the state (sorry no pun intended), of React, Redux and the like, Javascript frameworks should be abandoned. I built something in Rails in like 20 minutes. Of course it's not a SPA, but it was simple to create this MVC structure... not only does it seem extremely difficult, hairy and overly complicated in React, when Redux is added, it gets into the area of absurdity. Perhaps that is why we only see very very simple tutorials with all these tools.... building huge apps with them isn't possible.
So basically, in just trying to code a simple few lines of this example above with react and redux, I was lead to this:
https://redux.js.org/recipes/structuring-reducers/normalizing-state-shape
Can someone prove me wrong? PLEASE. Just a simple codepen showing me you can have a parent "project" component, which you can add "todos" to as children and the ability to make MULTIPLE parent components, with MULTIPLE children without going down the rabbit hole above.
This is a serious flaw in my opinion if this is true. A showstopper.

Your question and understanding are wrong in a few ways.
For context, I'm a Redux maintainer, and I wrote the Redux "Normalizing State Shape" docs page you linked to.
First, you don't need to use Redux if you're using React. In fact, we recommend that most beginners should focus on learning React first, and only try learning Redux once they're comfortable with React.
Second, Redux is independent of React, although they're commonly used together. You can use Redux by itself, or with any UI framework (React, Angular, Vue, Ember, jQuery, vanilla JS, etc).
Third, normalizing is a recommended pattern, but it's not required. Per the docs page you linked, normalizing data has several benefits, but it's fine to keep your data nested if that works better for your application.
Fourth, there's many large complex apps that are written with React and Redux, not just todo examples. See the Apps and Examples list in my Redux addons catalog.
Both the React docs and Redux docs have links to many CodePen / CodeSandbox examples that demonstrate how to use them - see the Main Concepts and Tutorial pages in the React docs, and the Examples page in the Redux docs.
Also, the TodoMVC.com site has several React todo list examples you can look at.
I'd suggest that you take the time to go through the tutorials in the React docs. You may be interested in my suggested resources for learning React and learning Redux, as well as the articles and resources listed in my React/Redux links list.

React Context vs React Redux, when should I use each one? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
React 16.3.0 was released and the Context API is not an experimental feature anymore. Dan Abramov (the creator of Redux) wrote a good comment here about this, but it was 2 years when Context was still an Experimental feature.
My question is, in your opinion/experience when should I use React Context over React Redux and vice versa?

As Context is no longer an experimental feature and you can use Context in your application directly and it is going to be great for passing down data to deeply nested components which what it was designed for.
As Mark Erikson has written in his blog:
If you're only using Redux to avoid passing down props, context could
replace Redux - but then you probably didn't need Redux in the first
place.
Context also doesn't give you anything like the Redux DevTools, the
ability to trace your state updates, middleware to add centralized
application logic, and other powerful capabilities that Redux
enables.
Redux is much more powerful and provides a large number of features that the Context API doesn't provide, also as #danAbramov mentioned
React Redux uses context internally but it doesn’t expose this fact in
the public API. So you should feel much safer using context via React
Redux than directly because if it changes, the burden of updating the
code will be on React Redux and not you.
Its up to Redux to actually update its implementation to adhere with the latest Context API.
The latest Context API can be used for Applications where you would simply be using Redux to pass data between components, however applications which use centralised data and handle API request in Action creators using redux-thunk or redux-saga still would need Redux. Apart from this Redux has other libraries associated with it like redux-persist which allows you to save/store data in localStorage and rehydrate on refresh which is what the Context API still doesn't support.
As #dan_abramov mentioned in his blog You might not need Redux, Redux has useful applications like
Persist state to a local storage and then boot up from it, out of the box.
Pre-fill state on the server, send it to the client in HTML, and boot up from it, out of the box.
Serialize user actions and attach them, together with a state snapshot, to automated bug reports, so that the product developers
can replay them to reproduce the errors.
Pass action objects over the network to implement collaborative environments without dramatic changes to how the code is written.
Maintain an undo history or implement optimistic mutations without dramatic changes to how the code is written.
Travel between the state history in development, and re-evaluate > the current state from the action history when the code changes, ala TDD.
Provide full inspection and control capabilities to the development tooling so that product developers can build custom tools for their apps.
Provide alternative UIs while reusing most of the business logic.
With these many applications its far too soon to say that Redux will be replaced by the new Context API.

If you are using Redux only to avoid passing props down to deeply nested components, then you could replace Redux with the Context API. It is exactly intended for this use case.
On the other hand, if you are using Redux for everything else (having a predictable state container, handling your application's logic outside of your components, centralizing your application's state, using Redux DevTools to track when, where, why, and how your application's state changed, or using plugins such as Redux Form, Redux Saga, Redux Undo, Redux Persist, Redux Logger, etc…), then there is absolutely no reason for you to abandon Redux. The Context API doesn't provide any of this.
And I personally believe that the Redux DevTools extension is an amazing, underestimated debugging tool, which justifies by itself to keep using Redux.
Some references:
Redux Is Not Dead Yet!
You Might Not Need Redux
Do React Hooks Replace Redux?

I prefer using redux with redux-thunk for making API calls (also using Axios) and dispatching the response to reducers. It is clean and easy to understand.
Context API is very specific to the react-redux part on how React components are connected to the store. For this, react-redux is good. But if you want to, since Context is officially supported, you could use the Context API instead of react-redux.
So, the question should be Context API vs react-redux, and not Context API vs redux. Also, the question is slightly opinionated. Since, I am familiar with react-redux and use it in all projects, I will continue to use it. (There is no incentive for me to change).
But if you are learning redux just today, and you have not used it anywhere, it is worth giving Context API a shot and replace react-redux with your custom Context API code. Maybe, it is much cleaner that way.
Personally, it is a question of familiarity. There is no clear reason to choose one over the other because they are equivalent. And internally, react-redux uses Context anyways.

The only reasons to use Redux for me are:
You want a global state object (for various reasons, like debuggability, persistence...)
Your app is or will be big, and should scale to many developers: in such case you probably need a level of indirection (ie an event system): you fire events (in the past) and then people you don't know in your organisation can actually listen to them
You probably don't need the level of indirection for your whole app, so it's fine to mix styles and use local state/context and Redux both at the same time.

If you need to use middleware for various purposes. For example logging actions, error reporting, dispatching other requests depending
on the server’s response, etc.
When data coming from multiple endpoints influence single component/view.
When you want to have greater control over actions in your applications. Redux enables tracking actions and data change, it
greatly simplifies debugging.
If you don’t want server response to directly change the state of your application. Redux adds a layer, where you can decide how, when
and if this data should be applied. The observer pattern. Instead of
creating multiple publishers and subscribers across the whole app, you
just connect components to Redux store.
From: When to use Redux?

Javascript object instead of Redux?

I'm currently build my first real app in React and decided to use Redux along the way.
After implementing Redux, it seems like a difficult way to just set a component state to a plain application global javascript object? I've read that Redux does some performance stuff, but if we were to use a plain javascript object and enforcing immutable state change together with forceUpdate() whats the point of Redux? Besides cool timeline dev stuff? What am I missing? :)
Thanks in advance :)

If you truly understood Redux, then I think that’s mission accomplished.
Redux simply adds a simple flow to managing a global JS object - global state. You can surely do it without Redux. After all it’s very small library.
So you’re not missing anything, I don’t think. Redux is just a really useful workflow that you can implement on your own. But given it’s simplicity and excellent architecture, it may be worth going with a proven solution.

React and Redux differences in code that should be used and not used (conceptual)

I'm working with React-Redux and just wanted a bit of clarification as it is a mental blocker for me.
Using the Redux libraries allows us to have a different architecture to manage state - ok.
But using this comes with a variety of helper functions and in the process of looking at online material I have found there are a number of ways of writing your code.
In terms of state management, Facebook's react docs includes stuff like componentWillMount, componentDidMount, getState, etc. Then there's connect(), Redux thunks, etc.
Is it correct that these should still be used when writing Redux-React? Does it defeat the point in Redux? I'm a little confused at where the line is drawn between the two in terms of how to actually write code?
As always, thank you for the advice

Check this official Redux tutorial section: http://redux.js.org/docs/basics/UsageWithReact.html
That will help you to understand how to use them in pair. Even better, check whole tutorial.

Does React.js have a basic Flux implementation?

I am new to React.js and I am enjoying it a lot. I came across the Flux architecture while reading the React.js documentation. I understand that Flux is just a pattern and that there are many Flux implementations out there – including Facebook's own. I also know that React.js can be used without any Flux implementation.
My question is: is it safe to say that React.js has its own (small) Flux implementation embedded within it? In my opinion, I don't see any other way for React.js to achieve its uni-directional data-flow without having its own Flux implementation – which is, of course, replaceable with other Flux implementations.

Flux is pattern for handling application state and React is just view library. You don't have to use Flux with React, but it's preferred way.
Most popular Flux implementation seem to be Redux nowadays.

The picture below is an explanation of what is, and what is not in react:
The green stuff = part of React: a library to render a component tree in a DOM (or somewhere else).
Unidirectional flow means that react is made for/ allows only top-down updates: any component can render/ update/ change itself (through change in state) or its children (through passing props down the tree).
The blue parts are part of the Flux-pattern. React does not have any code/ library components for this.
The elements of flux make the circle complete: they allow react components to trigger actions, which in turn update stores, and can allow for (top) components to re-render based on changes in stores.
There are libraries (e.d. redux, reflux, alt) that implement the various elements of the flux architecture.