Gain insights into modern Redux usage with Redux Toolkit and React-Redux hooks. Delve into updated patterns and practices through comprehensive tutorials. Explore and apply contemporary Redux concepts.

Hi, I'm Mark Erikson, also known as @acemarke, and I'm a Redux maintainer

I wrote this course in 2017. Many of the concepts are still relevant, but Redux usage has changed significantly. We now teach Redux Toolkit as the standard approach for writing Redux logic, and React-Redux hooks as the default for components.

I'd recommend reading through the Redux core docs tutorials, which have been rewritten to explain the "modern Redux" patterns we teach today:

https://redux.js.org/tutorials/index

I've made this course free if you'd still like to go through it.

Robin Wieruch

Mark helps people learn Redux almost every day.  I guess he has seen all the challenging questions about it by now. So if you are learning Redux, I highly recommend to go with his course, because it comes with all his gathered experiences about the topic

Author of "The Road to Learn React"

Dave Ceddia

Practical Redux is the missing manual for how to use Redux in real-world apps, full of practical ideas on project structure, handling complex data, and best practices. I highly recommended it for anyone using Redux in a real app.

Author of "Learn Pure React"

Gosha Arinich

Mark is _the_ guy when it comes to explaining Redux. The course builds upon (& goes above and beyond) his awesome series of posts on Practical Redux. It’s full of actionable advice that applies to a range of apps… there were a couple of things I myself learned from it, and I’m no stranger to Redux. Definitely a must!

Author of "The Missing Forms Handbook of React"

Practical Redux

There's been lots of discussion over what constitutes a good folder structure for a Redux application.  The typical approaches generally fall into two categories: "file-type-first" (folders like `/reducers`, `/components`, etc), and "feature-first", also sometimes referred to as "pods", "domain-based", or "feature folders" (folders that each have all the file types for a given feature).

The original Redux examples use a "file-type-first" approach, but a lot of the recent articles and discussion have shown some convergence on the "feature-first" approach.  There's tradeoffs either way - "file-type-first" makes it really easy to do something like pulling together all the reducers, but the code for a given feature can be scattered around, and vice versa for "feature-first".

My own current approach is mostly a "feature-first"-style approach.  It's got some similarities to the approach described by Max Stoiber in his article [How to Scale React Applications](https://www.smashingmagazine.com/2016/09/how-to-scale-react-applications/).  The main differences are:

- I prefer to give my files full unique names, rather than having files named "actions.js" and "reducer.js" in every folder.  This is mostly for ease of finding files and reading file names in editor tabs.  I also would rather give component files unique names, rather than naming them `SomeComponent/index.js`.  
- I've experimented with using `index.js` files to re-export functions and components upwards as a sort of "public API" for nested folders.  I'm not entirely sold on this idea, as I'll explain in a minute.  
- I put these folders grouped under a folder named `features`, rather than `containers`
- I personally use a mixture of thunks and sagas for my side effects.  I use thunks for simple async and complex synchronous work, and sagas for more complex async or decoupled logic.
- I also prefer to use "absolute imports", such as `from "features/someFeature/SomeComponent"`, rather than multi-level relative imports.
- I do have a `common` folder at the top level of the source, next to `features`.  This is where I put truly generic reusable components, utility functions, and other logic that may get reused in multiple places throughout the application.

I'm not going to say that I'm 100% happy with my current approach.  In particular, having a path like `"features/featureA/FeatureAList/FeatureAList.jsx` gets kinda silly and repetitive.  On the other hand, it's _very_ clear exactly where that file is coming from.

I mentioned I'm not convinced on using `index.js` files to re-export "public APIs" for a folder.  It can simplify import paths a bit, but may also mean that more files might get affected and rebuilt by a development server like Webpack due to the additional dependency entanglements.  At one point it seemed like that the time needed to hot-reload changes in my app had gone up considerably, and I'm not sure how much was due to just having more code, and how much is due to a more entangled dependency tree causing more files to be affected.  The proliferation of `index.js` files and re-exports can also be annoying.  

I would say using `index.js` files is most useful if you have a parent component and several child components as separate files in the same folder, and you really only want to have the parent component get imported by other parts of the app.  In that case, it does shorten the import path by just a bit, and also keeps the rest of the app kind of ignorant as to whether it's a single component file by itself or some kind of "compound component" that's actually several files in a folder together.

I'll freely admit that I'm still trying to figure things out myself.  There's been quite a few good articles written about project structures, which I have collected in the [Project Structure](https://github.com/markerikson/react-redux-links/blob/master/project-structure.md) section of my [React/Redux links list](https://github.com/markerikson/react-redux-links).  I'd generally suggest using a "feature folder" approach, but Redux itself won't care at all.  The important thing is that you, and anyone else working on your project, should be able to understand where the code for a given capability actually lives, and find that structure to be maintainable.

So, with those caveats, we're at a point where we should start extracting files to a more maintainable structure, but there's a couple tweaks we have to make first.

Introduction

Project Planning and Setup

UI Layout and Project Structure

Using Redux-ORM

Loading and Displaying Data

Connected Lists, Forms, and Performance

Form Change Handling, Data Editing, and Feature Reducers

Form Draft Data Management

Managing Modals and Context Menus

Wrapping Up

Thoughts on Folder Structure