Starting on React
So now that we've gotten the basic APIs required for Recipe, its time to show the goods and shake it with what your mama gave you. Firstly, let's have a holistic view of our folder structure:
├── __test__ Mocha & chai tests
| └── actions
| └── reducers
├── .vscode Settings & snippets for this project (for VS Code)
├── messages locale messages
├── src Main container for the application
| └── actions Handles communication of external calls & modification of data
| └── types Dispatch types
| └── app Application core structure and theming components
| └── components Cross-project reusable components (dumb components)
| └── containers Components that handles business logic & redux connect (smart components)
| └── layouts Page layouts
| └── lib Cross-project reusable helper libraries
| └── reducers Handles modification to store
| └── routes Url path manipulation & authentication
| └── types flow types
We Breath Redux
The folder structure is mainly due to the contribution of the Redux structure. Although there are many great alternatives for React state management, Redux has been tried against the test of time and still remained the most accepted and popular framework of them all. To understand this further, one must first understand redux
Circle of Life
An important thing to remember about react is that things always goes around in a circle. The purpose of this is to separate the concern between each pieces of this flow. When trying to understand each piece, focus on its downstream and upstream (what comes in and what goes out).
Separation of Concern
The components only care about the props coming in, and the actions it can call. It has no clue nor does it care about what the action does with the given information. The action is only responsible for communicating with external APIs and data manipulation based on the parameters passed in, and it'll dispatch (broadcast) its different states of its actions (ie. fetch request, fetch complete, fetch fail). It does not care who receives these dispatches or what they do with it. Lastly, reducers listens on any dispatches that are emitted from actions, captures the one it wants base on the dispatch's type, and modifies the store data base on the dispatch's payload (data that goes along with the dispatch).
Why separate us?
This has two main advantages: simultaneous development and adaptation. To elaborate, on a particular feature, instead of one developer working on it, we can now have three developers simultaneously, each in their own domain: Views (components), Actions and Reducers. As for the second point, adaptation, it is always beneficial to cut a framework's responsibilities into layers. Why? Not every piece of the flow may be best suited for each project. There will come a time when we feel swapping a layer will provide even higher efficiency due to either the nature of the project or the composition of the team. A good example would be a fairly popular trend recently of using React for its views, and Angular for its state management. There is never an absolute path, so always be prepared for adapting.