Navigating Stateful and Stateless Components in my Final React Project

For my final react project I built an app that lets the user search for a specific dog breed and renders a page that displays different information and pictures about that specific breed of dog. The data displayed from the app was persisted from an external API. Utilizing react and redux for this project was definitely a learning curve considering there are noticeable architectural and contextual differences between React and Javascript. I’ll dive deeper into some of those differences below. 

Components 

One of the key differences between vanilla JavaScript and React is components. Whereas in vanilla JavaScript views would’ve been used to represent different pages, react uses components to both encompass logic such as fetching data and display HTML on the User Interface through render methods. That means components can handle primarily frontend actions and some (would have been backend) actions in a vanilla JavaScript application. In my application, I found the best and most straightforward way to structure it was by separating the folders based on concerns. The stateful components were saved in a folder named “home” and the stateless components were saved in the folder named “layout”. Both of these folders were nested in the “components” folder. In addition to the structure of what would be the rendered application, I chose to also separate the fetch components and reducer components into separate folders.

Stateless Functional Components vs Stateful Class Components

Stateless functional components refer to components that don’t have a lifecycle. This means that hooks and methods such as setState and componentDidMount will typically not work for this kind of component. Since this component is stateless the state cannot be rendered. This is useful when it comes to debugging and testing because there is no need to console.log the state. In addition to that, to render props in a stateless component, the following syntax must be written like so ex: {props.name} For my app the parts of it that I knew were going to be static were written as stateless components such as my view pages and presentational components like dogCard. Stateless components also don't contain a render method. 

Stateful class components differ from stateless components for the most obvious reason. They can render a state and this is useful when writing functions where the outcome of the state after running a certain method might change. Some other differences are that stateful components can hold functional components and do need a render method and when rendering a prop must be written through this syntax ex {this.props.name}. The DogContainer component as well as my fetch actions components were written as stateful components due to the fact that I knew their output would be constantly changing. 

Container Components & Presentational Components

As mentioned earlier, container components and presentational components were included in the app for the main reason of separating by concerns. The purpose of my DogContainer was to destructor the dogsbreeds array fetched through the searchActions component and then map through the array to create new dogBreed objects which would then be rendered in the DogBreedCard component. So the container component's purpose are to handle the logic and state. Then the DogBreedCard component can display the information as a stateless component and it’s more concise and structurally safer due to separation of concerns. This separation of concerns would help in the long run if I ever wanted to change the DogBreedCard component I would only need to update that component and would be able to reuse it in different containers. 

Learning about the different types of components in React was definitely a learning curve but it helped to view components as another useful way to organize the app based on that certain component’s “job”. Eventually, as my app started to come together it clicked and started to make sense that it’s easier for myself and other developers to read my code when things are separated based on concern. With information that is dynamically changing such as from a fetch call to an API it makes sense to store it in a parent component that will handle the data and logic, which then gets passed down to its stateless children components.