When you've implemented the dish detail component in the first assignment, you might have noticed that the dish detail component operates purely on the props that are passed to it from the menu component in the form of the selected dish details. So, the dish detail component itself has no local state, and is purely dependent on rendering its view based on the props that is passed on it. So, it is acting as a pure presentational component as we might classify our components. Similarly, a container component may simply store the state information and pass the state information to its children. Let's look at some details next. Some people have informally classified the various kinds of components that we use when we implement our React application into different cuts. So, for example, we can talk about presentational components that are purely responsible for rendering the view based on the props that they are passed in, and then you could have container components that simply make use of presentational components and pass props to them and they are responsible for storing the state (the container components). Similarly, we can talk about these as skinny and sat components. Skinny components mean purely responsible for rendering the view and fat components having a lot more information being tracked there in the form of state. Similarly, we can even label them as dumb and smart components, stateless and stateful components. No matter how you classify them, you begin to see that they can view components as of two kinds. Again, these are informal ways of classifying the components. There is no formal description of these kinds of components in React itself, but this helps us to structure our application when we view the components of different kinds as delineated here. Let's look at specifically representational and the container components in a little more detail. Taking a broad view of presentational components, we can consider presentational components to a mainly concerned with rendering the view, that is how things look. So, they are mostly interested in the markup and style, so they become the repository for the markup and styles for rendering the view to the screen. So, they render the view based upon the data that is passed on to them through props. So, we have already seen how we pass that selected dish details through props to the dish detail components. So that being one example of a presentational component. Furthermore, presentational components do not maintain there own local state. So, they won't maintain the state of the application in any way. They may maintain some basic state with respect to only the UI state. So for example, if you have a dialog box popped up or a model popped up on the screen, that state of the dialog box of the model, may be reflected in the local state, but beyond that, the presentational components do not worry about the application state itself and they simply depend upon their opinion to passing the application state that is necessary for rendering the view. So, this gives you a rough idea of how we view a presentational component. On the other hand, we can view a container component as being responsible for tracking the state or at least a part of the state of our application. So, they are responsible for making things work. So, they are more worried about fetching the data, say for example, from a server and then using the data within the application or to set up the state or maybe taking care of updating the state in response to any user interactions on the screen or updating the states based upon the data sent back from the server. So, all these would be responsibilities of container component. So, again this is just a broad way of specifying what a container component may be used for, and they make use of presentational components for actually rendering the view. So, they could wrap the information sent in by the presentational components in their own wrapping divs within the container component in order to position the views that are rendered by the presentational component on the screen, but beyond that they will not be responsible for actually constructing the views. They delegate that responsibility to the presentational component, and also they are responsible for providing the data to the presentational component in the form of props that can be passed in to the child component there. So, they maintain the state and they take care of any state updates and then they will take care of communicating with the server in order to maintain the state or reflecting the state update and so on. So that becomes the responsibility of a container component. So, you can clearly see the separation of concerns between representational component and a container component. So, if you view your React application as consisting of these two kinds, then implementing your application or at least thinking of how you implement your application becomes more easier. So, you could only think about presentational components that are purely responsible for the views, and then you could think about container components that make use of the presentational components in order to construct the overall view of your application. Again, this is just an informal way of looking at how you can organize your React application itself into a hierarchy of components. So, with this view, let's go and work on our React application and then reconstruct it to use a presentational component say for example, we can redesign our menu component to be a pure presentational component, and we can redesign another component on top of it as a parent, which will be responsible for the state. We have already lifted the state into app.js in the previous exercise of the last module.
