Taste of Russia — Capstone React/Redux Project for Flatiron
Tags: Final Project, Redux Thunk, Flatiron School, React, Redux

After brainstorming and coming up with a few ideas what I’d like my application to be, I eventually stopped my decision on Russian recipe app, that will showcase my Russian heritage and hopefully spark some interest about Russian traditional dishes and will also help me show my technical skills with React and Redux in particular. I called it “Taste of Russia”. For planning the features of my application I found it very helpful to think about the User stories, which is a powerful tool for describing a set of functionality in terms of what it allows the user to do. Therefore, my user should be able to browse the existing recipes, create their own (and save them into the database), delete or search for recipes. Creating the User stories for your application is particularly helpful, because later they will be transformed into technical requirements necessary for turning those stories into working features.

After creating my User stories and Domain modeling I started creating my backend API with Ruby on Rails, where all my data would live. I created all the necessary models, migrations, controllers and routes and finally seeded the database with first recipes. The strong temptation is to build all the features together on the backend and then move to the frontend, but essentially it’s not very practical. One of the best advices I can give is to try to build out the functionality feature by feature, not model by model or layer by layer.

Once basic functionality on the back-end side was finished I started working on creating a front end (client side) of the application with the help of React. React is great, because it allows you to create small reusable components, each of which essentially are responsible for one thing (single responsibility principle). This way some of your components will be purely presentational (functional components), responsible for how things look, and others will be container components (class components), responsible for logic and data fetching. One of the super helpful articles that I can recommend that explains the difference between presentational and container components is by Dan Abramov (the creator of React) =>

To quickly recap if you don’t feel like reading that whole article, Dan says that it’s easier to understand as well as reuse your components if you divide them into two categories: Presentational and Container components. Presentational (stateless, functional components) are like templates, that are concerned only with presentation. Those components receive props as arguments, and never make use of state or any lifecycle methods (they’re simply not available outside a class-based component that extends React.Component). They are usually as simple as possible and receive data and callbacks from props only (provided by parent component). An example of such component would be a RecipeShow Card that I used in my application as a template to show ingredients, instructions and an image for all my recipes.

RecipeShow.js

Container Components on the other hand tend to be more complex, since they’re responsible for more logic like data fetching, sending props to their children, making use of state and other lifecycle methods that come with extending the React.Component class. An example of Container Component in my application would be RecipeContainer Component, that is responsible for data fetching, mapping over that data and creating a React component to represent the data. This example will be a bit more complicated, since this component is already hooked up to the Redux store(state management library), it also makes use of BrowserRouter (declarative routing for React), as well as makes use of Redux Thunk. Redux Thunk middleware allows you to write action creators that return a function instead of an action. The thunk can be used to delay the dispatch of an action, or to dispatch only if a certain condition is met. The inner function receives the store methods dispatch and getState as parameters. More info here =>

Basically, without Thunk we wouldn’t be able to make asynchronous requests.

RecipeContainer.js

One of the challenges I encountered was figuring out the correct data flow, and after implementing Redux figuring out which components should be connected to the store and which ones should receive the data as props. Making sure I use the right syntax and avoid silly typos was also important, because you can spend hours fixing some bug that’s actually a simple typo somewhere in your code.