Connect API vs Hooks

[00:00:00]
>> Welcome back, everyone so, [COUGH] In the previous section, I mean, so far we've mastered Redux, we're done, we know everything there is to know about Redux. We hooked it up to a react application, a very simple react application using the hooks API, and now we are going to look at how to use Connect.

[00:00:22]
Connect definitely predates hooks and so far that hooks have not always been around in react so they couldn't have always been around in react Redux by just that logic. There are trade offs between the two, hooks are definitely a very simple API that's very easy to use. As you can see, it didn't take a lot of particularly new knowledge to hook up a Redux store to our react application.

[00:00:53]
There are some drawbacks to hooks as well though, which is You know, I think one of the concerns and some of the criticism of hooks sometimes is like a separation of concerns, right, like that component is hooking into a Redux store. So like if you wanted to unit test it or drop it into storybook, a little bit difficult without bringing all of your Redux store along with it, right?

[00:01:16]
If it had any other side effects or use effect, they're going to fire no matter what, with the Connect API, it's just a different set of trade offs. And I would also posit that you don't have to exclusively use one or the other, you can kind of make the decision and trade off but there's not necessarily a right or wrong answer.

[00:01:35]
Connect API wraps, regular presentational components presentational components are basically react components with no sense of state management whatsoever. They take props, they do things right, they're effectively in a lot of ways, they can be class based or functional, but they're effectively not dissimilar from pure functions. They don't do anything and don't have any side effects on their own, the Connect API lets you take presentational components, wrap it in a high order component that passes in whatever state and whatever actions action creators or that the component needs into the component, which means you can kind of separate the two very easily.

[00:02:11]
You want to drop the presentational component into storybook and just pass in some mock data and some mock actions. Very easy to do, you want to pull it up in your test suite and unit test it super easy as well. Some of the drawbacks are, the act of wrapping components into a hierarchy component will add extra noise to your dev tools because there'll be these kind of invisible components, wrapping each and every one of these static typing hierarchic components can is not impossible.

[00:02:39]
But it can be a little bit trickier versus a hook, which takes an argument and returns an argument much easier to static type. So really what it comes down to is one, how old is your code base, because you might have a whole bunch of Connect API components in there as well.

[00:02:56]
Do you know if you're working very closely with a design team that needs a bunch of storybook or something along those lines or your unit testing everything maybe having a higher order components is more important for you. But if about ease of development and like what is the kind of like Less least amount of code you can possibly write well hooks are beneficial static typing is easier with hooks, so on and so forth.

[00:03:17]
We use both at various points and it is kind of on a case by case trade off, so we're going to look at both and then you can feel informed to kind of use use whichever one fits the problem you're trying to solve at that given moment. So, if we look on my screen right now, I've got the beginnings of a, just a quick little app that takes a bunch of menu items subtotals and figures out what the tip is, so on and so forth.

[00:03:47]
Right now, it doesn't do much we are going to get it wired up using the connect API, and there's a bunch of moving pieces here because there's different ways that you can use it. And so we've got a chance to kind of kick the tires on all the different ways to use the connect API.

[00:04:01]
So it's less about, I copied code from one part of the code base tweak some things and it works to actually like, just like we did with redox, I understand how this works. And now I can see what is going on cuz there's different syntaxes, and stuff along those lines.

[00:04:15]
This is our application, we can flip over to the code, I've got a store in here, and we've got to reduce it but right now it doesn't really do much of anything. And some actions which is just an empty file, we've also got a series of components all of them don't have any real estate management to them whatsoever.

[00:04:38]
Right now there are some hard coded items that will remove momentarily but the rest of them just take props and they render some no JSX right. Which will eventually get rendered as they shim out, what we're gonna do is take the different pieces that have some state management requirements, and we're gonna wrap them in these higher order components that will either pass in state from our Redux store, or pass in functions are going to dispatch actions to update the Redux store.

[00:05:04]
And we'll just kind of wrap the existing components and sometimes swap them out. There's a lot of ways to name the different components you can see sometimes you might make the wrapped component called menu item, container connected menu item. So on and so forth, it's really just matters about consistency In a larger application, how you lay it out might change as well.

[00:05:26]
A lot of times what we'll do is for every component will have a folder, and in that folder we'll have the presentational component, as well as the container component. This application isn't necessarily big enough that will just add more confusion than anything else, but how you choose to lay it out, it's kind of up to you and there's a lot of thoughts on this.

[00:05:46]
It's just say that there's no one right answer probably isn't isn't true, but there's no like hard and fast rule for how you have to lay out a component.