React and Redux : Connect Redux to the Messages App - Presentational Question

In this lesson we are introduced to the term Presentational. It says that:

This term generally refers to React components that are not directly connected to Redux

I was kind of confused by what we meant by “not being directly” connected to Redux. In the lesson prior, we said we “connected” our React component to Redux. I figure our component is either connected to Redux or it’s not, so I’m not sure what “directly connected” refers to. The following line says:

They are simply responsible for the presentation of UI and do this as a function of the props they receive

I had a look around online and came across what seemed to be a design pattern involving “Presentational” and “Container” components. My understanding is that container components actually interact with the store (by dispatching actions to it), while presentational components do not interact with the store by way of dispatching actions to it. They - the presentational components - simply display data passed down to them as props from their parent container component.

I wanted to post this topic to get verification that my understanding of what the lesson is pointing out about Presentational components is correct. I had a peek at the lesson that follows:

and it looks like we end up dispatching actions from the Presentational component, which - based off my understanding - kind of goes against the design pattern the lesson is trying to illustrate.

Please let me know if there is anything I am misunderstanding. Thanks in advance!

Yes. Thats a correct understanding.

The distinction isn’t particularly useful. Generally, outside of simple examples (or via forcing this structure in regardless of whether it’s sane or not), it doesn’t work universally. This was understood pretty quickly by the author of Redux, but by that point the idea had traction and here we are. He wrote a long-ass blog post touching on this & Redux in about 2019-ish (?). It’s kinda useful, and the pattern has many applications, but it shouldn’t be taken as any kind of black-and-white set of rules.

YMMV, but I would be very careful re. this part of the curriculum. It uses a lot of stuff that isn’t considered good practice any more. React used to have a major issue with state management, and it was often paired with Redux by default. That stopped being the case about 6-7 years ago (ish, maybe longer?).

e.g. I was rewriting an app in 2019 that used Redux in the way the curriculum describes. Code was very dated at that point and used a set of (formerly popular) supporting libraries that were essentially dead.

  • React itself had the Context API revamped, which probably removed 90% of the use-cases for Redux.
  • Redux itself was revamped - still works the same way, but it’s very rare to write code in the way described in the curriculum.
  • There are other state management solutions which work differently to Redux, and are equally (or more) popular.
  • GraphQL got fashionable, as did HTTP query libraries for React, which removed another big % of the Redux use-cases.
  • React went in very heavy on a function-based API, rather than using classes, which removed the distinction between “smart” class-based stateful components and “dumb” function components (all components are functions, all can have state).

Edit: here is the blog post from 2015 that introduced the idea and the reason you’re looking at these ideas ATM:

It was updated in 2019, see the introduction:

Update from 2019: I wrote this article a long time ago and my views have since evolved. In particular, I don’t suggest splitting your components like this anymore. If you find it natural in your codebase, this pattern can be handy. But I’ve seen it enforced without any necessity and with almost dogmatic fervor far too many times. The main reason I found it useful was because it let me separate complex stateful logic from other aspects of the component. Hooks let me do the same thing without an arbitrary division. This text is left intact for historical reasons but don’t take it too seriously

So you’re looking at a pattern adopted 10 years ago, that the author (and IME most developers) realised wasn’t terribly useful in many cases at least 5 years ago.

Note that, because of the way rendering works in React, it can be extremely useful if you have a component that makes an async call of some kind, then you have a subcomponent that renders something depending on response. Your “container” doesn’t need to have any rendering logic, that’s in those “presentational” component/s, the subcomponents. Hooks can do this fine, but it’s sometimes easier to have that parent/child component structure.

1 Like

@DanCouper Thanks so much for all of that! You mentioned some of the material in this course might be a bit dated, what would you say is some of the more common ways of managing state for React applications these days that I might want to have a look at?

  • Focus on local state as much as possible, most often relying on:
  • Hooks. This + functions is how React is normally written now (Vs using classes & class mathods). You can extract logic into them, reuse them. Most libraries provide their own hooks you can use to interact with the libraries.
  • Context API; this is built into React. It’s always been there (react redux has always used it). But was only really for internal use up until about 5 years ago, when they cleaned it up for the function/hooks API. It’s a dependency injection API.
  • Redux Toolkit, if you want to look at where Redux went. The current maintainer has done a lot of work to make it more useful and ergonomic, so I would have a look at the website. The curriculum get is useful in that the way Redux works under the hood is the same, but the way you use it is a bit easier.
  • Zustand is popular. Jotai and Valtio are other ones by the same author. All three are good & take slightly different approaches. Recoil is Facebook’s own library.
  • Then you have React Query, or whatever the newest hotness is, which provides hooks for making async queries. This by itself can sometimes negate the need for a state management lib.
1 Like

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.