Write a Higher Order Component from Scratch
Learn the proper patterns for writing a higher order component from scratch.
[00:00] A higher order component typically always has the same structure. It takes in a base component and it returns a component, in this case, it's a functional stateless component. Then it renders out the base component and it spreads the props in.
[00:28] Now, if we create another user and we pass our first user to our higher order component, it's not going to modify it in any way, but we will have a valid React component. I just have to add the name. You see, the prop signatures identical to user, and it renders exactly the same.
[01:04] Now if we want our higher order component to actually do something, typically you add a configuration step. Here we'll take in some props we'd like to override and then we can spread those onto the component as well. Now, we have to use our configuration phase and pass in any prop that we'd like to override.
[01:32] Now the name will always be Bob, regardless of what I change the name in the JSX. You could save the configuration portion of the higher order component call into a variable. We can call this one Always Bob, sometimes that's nice for readability. Then we can name our higher order component properly, as well.
[02:07] Another reason you might want to create a higher order component is to tap into a lifecycle hook. In this case, I need to use a class component and we have to do the same thing where we return the base component and spread the props in. Perhaps we want to create a component that never updates.
[02:29] We could tap into the shouldComponentUpdate() method, and we can return false. We don't need a configuration step for this phase. We can call this Never Render. Now, User 2 will never render. We also don't need this portion of the functional stateless component, and we also need to change this to this.props because we're using a class component.
[03:09] Now, if Steve were bound to some data and it changed the update would not be reflected.
Austin you nailed it, this was my point. There's actually a lot of benefits from higher order components, but it's not being explained. That's where some type of small intro to these videos would not only be extremely beneficial but in some cases crucial to understand the material. I understand that egghead tries this 'bite size' approach of training which is fine, it's great for breaking up the material but that's not a replacement method of teaching if you don't have some context with a beginning, middle and end.
I think the remaining lessons in the course help answer your question through various examples. I'm optimistic that by the end of the course you'll have a clear understanding of why you might use HOCs. This particular lesson was added to the beginning to demystifying what HOCs do "under the hood". I could move it later in the course after learners have gotten some initial exposure to some several real world examples.
Alright Tim, I trust you and I will give it a go! A short introduction is always useful in any case, for my taste. But opinions opinions.
Thanks for the quick reply :thumbsup:
It's good feedback. Thank you.
Instead of neverRender you mean neverUpdate, right?
Cool... just a bit dry 😬
which videos on egghead r are prerequisites? thx
why do you write BaseComponents in curly brackets without parentheses?
const neverRender = {BaseComponent} => class extends Component { shouldComponentUpdate() { return false; } render() { return <BaseComponent {...this.props} />; } };
...
const User2 = neverRender(User)
Why should I be writing 'high order components'? I do not understand what they do for me, it seems like a lot of abstraction with no clear benefit.