In this tutorial, you will learn all about the container pattern. The container pattern should make your problem solving easier as it will allow you to separate your components in smaller ones.
What is the Container Pattern?
The aim of applying the container pattern is to make components simpler. Simple components are desirable for several reasons. Keeping components simple basically means the application will be easier to maintain. First, designing a component to do one thing well, will increase the chances that it can be reused somewhere else in your application. The more re-use you can get from a component the less code you will need to write. Second, simple components are usually easier to test.
The container pattern promises to simplify your application through 'separation of concern'. MVC is another well-known pattern for separating concerns. All the logic required to render a page is done within the controller. The model is used as a contract between the contract and the view. The view is the presentational component aimed at rendering HTML to a user.
The contain pattern is similar to MVC. Within the container pattern, instead of having a one giant god component that does everything, you split it. Within the container pattern, you would create two components. One components concern is to manage how the component will work. The other components concern is how the component will look like.
Let's explain with a crude scenario. A common requirement in a project is to get some data from an API and display it. One approach would be to create a single component that contained all the code to query the API as well as all the code to render the HTML. If this component was compared to the MVC we would say that the controller and the view code has been intermingled which would be classed as a design smell.
Following the container pattern, we would create two components. The container would contain all the API calling logic. The resulting component hierarchy would look like this:
Within the container pattern, the component that manages state is called 'the container'. This is where the name 'container pattern' comes from. The presentation component is called 'the component'.
In this example, the 'Title' component is the presentation component. All 'Title' does is render some HTML based on some received props being passed in. The 'TitleContainer' is the component that does the work. it gets the data from the API, filters it, etc.. You may think that following the pattern seems like a lot of work for little benefit. The separation will add simplicity to your application. Following the pattern usually means a little high development cost up-front, however, it usually saves a lot of time when you write your tests. It will also prevent you from having to write very similar components to render out similar HTML with different data sources.
If you use Redux you will bump into the container pattern frequently. A very crude example of how Redux uses the container pattern with the 'Title' component would be:
The object being returned by the connect method is the container. The connected object hides the logic for the component to interact with the Redux store. The container pattern is simply a way of writing your code so the presentation code and the logic are in different components. That's all there is to understanding the container pattern, enjoy!