Recognizing Patterns in React-Redux
For the last phase of my software engineering course, we were introduced to ReactJs. Things like scaffolding for my Rails API and the very helpful create-react-app command made the beginning of this project feel like a breeze! But once I got into creating my project I realized how unsure of myself I felt. Should state directly reflect the tables and columns of my database? Which state should be kept local versus being kept in the Redux store? I had so many questions about the organization of my project in relation to what I wanted to happen. I also thought that maybe I should start by building an application without Redux and then incorporate it later, but I was afraid I would only confuse myself more. I realized that I needed to start small, start with one fetch and just slapping that data on the page. Taking things one step at a time helped me see the pattern I needed to use to make my app work. Now i think that understanding the patterns of React and Redux can be the biggest part of the battle.
It’s important to note that these patterns are not necessary for React or Redux to function. React uses JSX separated into components, which when compiled form your complete application, and every separate component can contain whatever you deem necessary. You can incorporate local state and pass it down from parent to child and so on, or use the Redux store state in any file within your app, but this is a little too wild for me. I like to be able to recognize which of my files are used for completing particular tasks, in large part because that makes debugging and changing my app a lot more streamlined. If any file can do anything, it could be difficult to track the culprit down, especially because the error may present in a different file. For instance, when I had a bad fetch request to fix, the error showed up in the file that was trying to load that resource, but couldn’t locate it because it hadn’t actually been created! But because I knew which file was loading, I knew which fetch request to fix and I knew all of my fetch requests were stored as action creators in my actions file. Ease of tracking down and fixing my problem saved me time and sanity.
I organized my files by presentational and container components. Container components are meant to interact with the Redux store, call Redux Thunk fetch requests, and contain the most logic, whereas presentational components are used to simply organize the presentation of those containers’ contents. I also stored all of my fetch requests for Redux Thunk inside an actions folder, so they were all neatly organized in one central location. So I kept my logic-containing files inside a “containers” folder, my presentational components inside a “components” folder, and my action functions inside an “actions” folder.
For Redux it is also essential to have an area for reducers. With Redux, an action is initiated, which contains a type property. The type is passed to the reducer and it looks through all the cases available to match to the type you sent it. When the type matches the case, it will update the state in the manner you have coded it to. If no case matches the type then the default of “return state” would be initiated. You usually want to store all reducers inside a “root reducer” so that you can be sure you’re using the right reducer when sending an action type. Multiple reducers could lead to issues and ultimately end up returning your un-updated state even if the action matches in a different reducer.
So you see, before you give up entirely, take time to look into the patterns of React and Redux. You may find a different pattern than the one I used that you prefer, I might change the pattern I like next week, but the important thing for me is just to feel like I have a structure to follow. I like knowing where to step next, whereas a lot of coding at first feels like walking blindfolded. React and Redux are helpful libraries that allow for dynamic, complex applications with less hassle than vanilla JavaScript. Enjoy!
