Interviewer: Did you read my email yesterday that was a bit longer than I meant to? laughs
Joe: Yeah, yeah, yeah. It was super helpful.
Interviewer: Does that make sense about the custom hooks versus NPM publishing stuff?
Joe: Yeah. I wrote down some thoughts addressing some of the things you said. The reason that I gave it that title and thinking of going in that direction was because I thought from a marketing perspective, target React developers who have a ton of experience in React, and want to share but don't have a ton of experience altering NPM packages.
That was my original intention, but I see what you are saying.
Interviewer: I think that we could do both. What we've been doing lately with some of the courses that we've been planning is they've been ending with a deployment step. Think about when a Gatsby site gets built you would deploy it to Netlify, or GitHub pages, or whatever.
Also, if you build a Create React App you can still deploy it in a similar way. If somebody wants to jump in at that point, they would have to go through everything. If your course started with, "You've already written these custom hooks." It like, "Wait, I didn't do that yet."
Interviewer: That's the angle we were thinking when we looked at it. We wanted to stand alone from the other couple, the courses that I linked that are similar but different. We want more than one person to teach the same thing.
The example that I like to use is I had to replace all the stuff inside my toilet tank, the floater and all the other stuff. I watched three or four YouTube videos before I even tried it.
Interviewer: It's the equivalent of that, where it's like, "OK, how do I really do this? This guy does it this way, this person does it that way." If it works for you, I'll share my screen real fast and we can start working through this a bit.
Like I wrote in the email, we're going to work through these. They'll take a little bit, but it goes by pretty fast, because we have fun while we'll do it.
Interviewer: What would you say is the one sentence topic of the course?
Joe: The one sentence topic is writing custom Hooks in React.
Zach: Would you add shareable or reusable?
Joe: Yeah, writing custom shareable, reusable, probably shareable.
Interviewer: Before we get going, some of this might feel a bit redundant. We're looking at it from different angles, and then it's easier than like, "Oh, I forgot I should've said this one thing earlier." It minimizes with that thing.
Even though we've already read your notes and stuff, we pretend that we didn't, if that makes sense?
Interviewer: Cool. Why is it important to learn how to write custom Hooks and share them?
Joe: I guess to the first one, "Why is important to write custom Hooks?" Essentially you have these basic Hooks that are provided out of the box in React. The important part of being able to write custom Hooks is because you can build on top of what you're given by React.
It's like writing a function. Maybe you build something on top of Lodash. You're gathering something that might be reusable, packaging it up into this custom Hook. When someone goes to use your custom Hook, all of that logic is abstracted away. You have to call this custom Hook to implement that feature.
It's a long-winded answer but hopefully.
Interviewer: No, it's great. That's perfect. This is what we're going for so far.
Interviewer: What's most exciting about custom Hooks and sharing them? What do you find most exciting?
Joe: The most exciting part is, I don't want to say feeling like a React developer, but feeling like a React core developer. These people, I don't know, their minds, and it's like I look up to Danny Vermont, for example.
I look at that team, and I'm like, "OK, they built these useState hook or they built these useEffect hook. Now, I'm taking this pattern that they've presented me with. Then I'm leveraging it to write my own hook and so it feels like I'm really writing code. I'm like standing on their shoulders to write code that feels like code they wrote kind of."
It feels very empowering to you as a developer because again you're leveraging the React ecosystem, the patterns that they are advocating for and then being able to package that up into a custom hook.
What you can do then is subtract it from your project, create a package and share it with the open source community. If you're interested in getting involved and you have a lot of experience with React, you can take that experience and use it to give back to the community, the open source community.
Interviewer: That's all awesome. laughs So good. How did you first get interested in custom hooks?
Joe: At my previous job, we do this thing called OKRs. I don't know if you guys are familiar?
Joe: There's this book that I think someone who worked at Google wrote called objective...It stands for objectives key results or something. You got your main level objectives so like your goals and then you break that down into key results that will just come in if you hit that objective or not.
One of mine at my last job was, "Hey want to get into open source and understand how to release something to the open source community?" For an app we were working on, I wrote a custom hook called use-click-away. It was for like we had...when you click on your icon and a drop down pops up and then you want to click off to close it?
Joe: I wrote a custom hook to do that. When I was talking to my coworker, he was like, "Dude, you should just extract that and make that an NPM package." Him and I made this package called react-use-click-away.
Then when I was trying to figure out how to do that, I'm googling "React," it was either, "React custom hook" like "NPM package." I tried to get pretty specific and I couldn't find any blog post on it or anything in that.
I tweeted about it and a few other people were like, "Hey, let me know what you find." I found stuff that was like, "Hey, here's an NPM package." I watched some of those videos from Ken, but I didn't understand how to create the package and not bundle React as a dependency.
When I first did it, I was bundling React because I didn't know what I was doing. Now when I tried to input the package it was like, "Hey your two inaudible is a React". That's the whole reason that this all started.
Interviewer: You wrote a use-click-away?
Joe: Yeah. I put it in the Zim chat.
Joe: ripple. If you google it too, "React-use-click-away," you should find it.
Interviewer: You know what you might be able to do, you might be able to teach how you did this.
Joe: That can work too.
Zach: It's concise enough too.
Interviewer: It's MIT anyway so you'll be allowed to teach it laughs no matter what.
Joe: That's funny.
Interviewer: Since you are the one that created it, that might something to think about because then we don't only get to tell the story of how you did it, but you're actually like, "Literally they can do it too."
Interviewer: Keep that in the back of your mind because that might be even easier because you've literally already done the work. Cool. How would you respond if a developer asked you why they should learn custom hooks and how to deploy it? We've sort of touched on this a little bit, but the what's-in-it-for-me factor?
Joe: Again, going back to this idea of leveraging this pattern that's presented to us from the React ecosystem, we can take that, built upon that, one that's going to make you a better developer because it's you going to have to better understand how Hooks work and how to make sure that you're not breaking any rules and following the correct patterns and procedures. You're going to become a better React developer.
The second thing that it's going to help you with is being able to put that on your resume. "Hey, I wrote a custom Hook, then I deployed it, or authored it into a NPM package. I've contributed to open source."
It's going to look good for you, your company. It's going to make you feel confident as a developer. Maybe your package will solve a problem for someone else.
Interviewer: That's perfect.
Joe: I feel like I'm being interviewed here.
Interviewer: That's all right.
Zach: Well, you're nailing it.
Interviewer: It's good practice. This is exactly the stuff that we'll be using this to promote it. I will go through and come up with ideas. Then you can promote your own course. This helps you build yourself up that much more.
I've seen you around. You're not low tier. You're not a nobody. This helps for more than just the course creation. This is all the stuff around it, too.
What happens if a developer doesn't learn about writing custom Hooks and deploying them?
Joe: On the short term if you don't understand custom Hooks, I don't want to say you're going to fall behind because that may be dramatic. If you don't learn how to do this, then you're probably not going to fully understand the potential for Hooks and everything that it introduces.
Again, at the end of the day, it's just a function you're building on top of a function. You're going to be less efficient. You're not going to save as much time. Your code won't be as [inaudible 1
Zach: 18] .
That would be the short term. Long term, again, this could be a very simple introduction to open source for you. By not taking advantage of that, it might take you that much longer to learn how you can contribute to open source.
It's scary. You see Kent C. Dodds writing entire tests in library suite. I'm like, "That's where I'd love to be one day maybe. What are the baby steps to get there?" Again, by not doing this, you're not going to be able to take those baby steps. You're never going to fill that gap.
Zach: Would you say it's fair, or would you say it's fair to say -- that was a bad sentence -- at best your wasting your time rolling your own code or functions where they might be a solution and, at worst, you could become outdated?
Joe: Yeah, totally. You could totally become outdated. Some people still haven't even tried Hooks. There's the first step of trying Hooks.
Then the second step is writing custom Hooks. Again, if we have this scale of the potential, the amount of efficiency that you can have as a developer, using class components, using Hooks, and then using custom Hooks, you're not going to be the manager of that whole scale. You're going to be stuck in the middle.
Interviewer: I pictured that meme with the brain or whatever.
Interviewer: I don't know if that has a name, but you knew which one I meant. Cool. This one should be pretty easy because what are the real world contexts in which students could apply custom Hooks in their deployment? It's almost in the sentence itself, right? laughs
Joe: Yeah, using your custom Hooks, you're going to use them in the applications that you're writing for work or for fun. Then, again, the next step is deploying that, sharing it with the open source community.
Once you do that, the possibilities are endless for how people are going to use it. You really can't anticipate the number of ways that people are going to use your packages.
Again, you might write it and nobody uses it. That's OK. You're still going to have that real world context of taking something, extracting it from your own application, honing it in its own context, packaging it up, deploying it, sharing with the open source community. That in itself is almost like shipping a product.
In this case, it's just code. They can see more as a developer. Again, there's so many people that that's all they do. They only work on open source.
Interviewer: This is all great stuff. As I pause and type, sorry.
Joe: You're fine.
Interviewer: What would be the end result goal? Similar to what our one sentence version of the topic, what's the one sentence version of the goal for a student after they've taken the course?
Joe: The one sentence goal would be, "As a student, I understand how to write custom Hooks in React and publish them as NPM packages for the open source community."
Zach: What's interesting is this next step is very similar to what you were talking with the OKR, I think you said. We have that course goal. Now, a step under that is these course outcomes where we're going down into a little more objective steps to take.
Interviewer: Exactly, what's the first milestone outcome on the road to writing and deploying custom Hooks?
Joe: If we're assuming that this is a beginner, probably understanding, "What is a Hook? What isn't a Hook?" or "What is and isn't?" Again, we need to lay the foundation for the student and figure out, "OK, what is a Hook? We need to be on the same page because what you think is Hook, I might not think is Hook, even though there is a standard Hook."
Interviewer: That's great. What's the next one after that?
Joe: After we know what a Hook is, then probably understanding what a custom Hook looks like. That might be a good example to looking at one that you sent me to go use at inaudible .
Interviewer: We need to know what a Hook is. That would be like, can we say, is built-in the right phrase, standard maybe?
Joe: Yeah, where you can get...
Interviewer: One that you don't write yourself, I guess.
Zach: Yeah, what would that...? Man, I feel like there's a right word for this.
Interviewer: What do they say on their websites?
Joe: What does the React doc say?
Interviewer: Hooks are functions that let you hook into React state and lifecycle features, which is a really long way of saying built-in, I guess.
Joe: First Class?
Interviewer: First class, all right.
Joe: I don't know what that is.
Interviewer: Anyways, I know...
Interviewer: We'll know what this means. When we work on this together, we'll know what we mean by first class.
Interviewer: After they understand what a custom hook is, what's the what's the next milestone?
Joe: I'm going to ask a question first. Do you think that it's better to write a custom hook within the context of an application like a create React app, and then extract it, or do you think it's better to start with a boilerplate for writing a custom hook?
Interviewer: What would be more real world?
Zach: What did you do to make the click away hook?
Joe: I wrote it in the current application we're working on, and then I pulled it out.
Zach: That would make sense to me. I don't see anyone ever developing hooks like, "All right, I'm just going to use it over here," like in it's isolated. It's pretty much are you unit-testing just the hook or are you actually having it in an application with dealing with state and all of that.
Interviewer: Let me move the Zoom stuff around. If we used use clickaway, we're going to try it in this demo...
Joe: I can't see. I just see...There we go.
Interviewer: Cool. My Internet's been super weird today. Menu, and then clicking out here closes it, right?
Interviewer: Even if we started with just this, and I want to close it, but I can't...
Joe: I see. Without the hook.
Interviewer: We all know what menus are. It's not hard for us to be like, "Oh, yeah, click outside of it," but it doesn't work. Not only do we need to implement that, but then it becomes a hook and then it becomes extracted into its own thing. Then at the end, you bring in the one that you wrote the custom one, something like that.
Zach: Using that example, you can get on the same basis on what a regular hook is. Maybe that hook is already written and you're just going through what it actually is.
Zach: If you had the setState of menu open, setState menu closed...
Joe: For that hook, you have to use another hook, a setState hook.
Zach: That works well.
Interviewer: More brainstorm-type stuff. The next milestone is understand what a custom hook is. Could be something like write a custom hook.
Joe: Write a custom hook in an application. Pre-existing or existing application?
Interviewer: Existing. There we go. All right. Then probably extract the hook into...?
Interviewer: Do you deploy it, or is there something between extraction and deployment?
Joe: Testing locally.
Interviewer: Then deploy?
Joe: Then deploy. I'm going to pull something up real quick to share.
Joe: While I was waiting for this, I wrote a blog posts on how to do it on the previous topic. Maybe I can share that if that's helpful.
Interviewer: Dropping it in the Zoom chat?
Joe: Yeah. Pulling it up right now. The other thing, too, is I don't know if this fits as a milestone, or this might just be part of the extraction process, but there is a library called react-modern-library-boilerplate. It's a CLI tool for putting together a boilerplate for publishing a react module.
Interviewer: That sounds like it will fit in the next section of stuff. As we move through the funnel, we're going to get more and more granular into each of these now. Then the next step after, we break these six up into pieces is the actual list of lessons.
This stuff becomes almost a checklist of cross-referencing as we come up with each lesson to make sure that everything's in order. As compared to the old school course proposal process was like, "Here's my list of lessons." The goal here is to make the highest quality content possible that takes the cognitive burden down a bit.
I'm going to open that blog post in a tab. This very last part of this first section is prerequisite knowledge, obviously React. How much, some familiarity of hooks, casual familiarity?
Zach: Know what they are, maybe?
Joe: Yeah. There's that blog post in Zoom
Interviewer: Got it. You'll teach the NPM publishing part. I'm going to write a publish/deploy. Is it publishing or deploy? I guess it's publishing more.
Joe: It's probably publishing, yeah.
Interviewer: I'm so used to saying deploy is the last step.
Interviewer: Have an NPM account, I guess.
Interviewer: Any other prerequisites jumping out? That's the only ones I can think of, at least. Cool. That is the end of worksheet one. What's your email address?
Joe: J-J-P-R-E-V-I-T-E @Gmail.com.
Interviewer: I remember it from yesterday now. As soon as I asked, I was like, "I think this is it."
Interviewer: Cool. This is workshop one or worksheet one, although workshops is something else that we'll talk about too in just a little bit.
Zach: Nice to cover it.
Interviewer: Meaning fundamentals and skills. This says topic, which is funny. I'll just write that for now. That'll be good enough. We'll know what that means.
What this section is, is this breaks up the outcomes that we already talked about, so these six things. This breaks those into meaning, which are things rules of thumb stuff that's like...Think about don't nest four loops would be a rule of thumb that you don't necessarily teach why not to because it's something that you eventually learn, if that makes sense.
Are there any rules of thumbs? Rules of thumb, not...Singular thumb, I guess.
Interviewer: What rules are there about making hooks, like creating them? Best practice-type stuff?
Joe: There is, I think, an ES link plugin. There's a React hook schools that I would lean off of.
Interviewer: Cool. That sounds it will be very helpful for this.
Joe: It's called Rules of Hooks.
Interviewer: Rules of hooks.
Zach: If it's ES inaudible , it sounds a good lesson. laughs
Joe: Yeah, NPM install eslint-plugin-react-hooks.
Interviewer: I'll just make this a link for now for the sake of not rewriting them all in this doc. These are the types of things that you can say during the lesson, that you're not necessarily going to have an entire lesson on only call hooks from React functions, but it's something that you'll explain out loud as you do the code, right?
Interviewer: Cool. Besides that, ESLint can be helpful, or ESLint has a rule you can use or something?
Joe: It's a plugin called eslint-plugin-react-hooks. It enforces those two rules from rules of hooks.
Interviewer: Enforces. I can type sometimes. Awesome. Any other rule of thumb stuff besides those two who literally have rule in that in their titles? Those two are pretty good.
Zach: My thought goes to peer functions and side effects. It seems if you have a ton of side effects, your custom React hook app would be bad. I don't know if there's a specific wording you have there, rule or...
Joe: That's probably something I should talk about or cover. There's useState hook, and then there's the useEffect hook. useEffects usually has side effects versus useState.
Interviewer: How about when to use useState and when to use useEffect?
Joe: Yeah, like when to write a useState custom hook and when to write a useEffect custom hook.
Zach: Do you ever mix the two?
Joe: Yeah. That's a good question. The useClickAway, I had originally called it useClickAwayEffect, because it's using useEffect to add an event listener to the document. There's the side effects there.
Interviewer: That would probably be the lesson to bring up that very thing.
Basic concepts. These are, what we would have the anatomy of a hook, or something like, "A hook as this, this this," kind of stuff? What do you think?
Zach: I'm going to start it, "A hook always returns an array with two elements. A two-element array."
Interviewer: Is that true even with the ClickAway?
Joe: No, because it's an effect. It doesn't return anything.
Interviewer: so it's not always, it's not all hooks.
Zach: Would it be a state hook? laughs
Joe: That's right.
Zach: Was it not specific enough?
Interviewer: Partial credit.
Joe: That's probably...OK, state hook, like Zach said.
Zach: I should probably use "always" less as a word because of this programming.
Interviewer: Go with like "often," or, "can."
Interviewer: What happens when you use useEffect? What gets returned?
Joe: I don't think anything. Right, Zach? I don't think anything returns. When you useEffect, nothing returns, something happens, so a side effect.
Interviewer: I'm behind on my...When you were talking earlier about, "I'm still writing class components over here."
Interviewer: You're getting me, man.
Joe: inaudible 3
Zach: 53] .
Interviewer: Exactly. I haven't been writing as much code lately. What I need to do is jump into my own side-project again.
Anyways, what other types of the concepts do people need to know? More of a practical, "These are kind of like theory, and these are more like practice."
Joe: Don't bundle React with your package.
Interviewer: That's a great one. Let's look back over here. I'll pull these up side-by-side. What other types of...and now I've got to move all the Zoom crap around. We have, "Writing a custom hook." When you write other custom hooks, do you usually do it in place before you extract it?
Joe: That's what I usually do, because then I can test it right there.
Interviewer: Custom hooks should be written in place so they can be tested before extraction"?
Zach: Is there any rules or -- that's probably the wrong word to use -- best practices around the options that you pass in? I see in your useClickAway, you pass in the state getter of useState, and then whatever React App ID and clickable is. Is there any best practice you're leaning on, or is that up to you, as a developer?
Joe: That is a good question that I don't know the answer to.
Interviewer: There's a bit of opinion in there, where, if you picture this course as cementing your place as the subject matter expert for someone who wants to write custom hooks, I think that whatever you think would be the best practice, becomes the best practice, until somebody can learn everything that you teach in the course.
You know that point where, you learn a lot about something, and then you've learned enough to start questioning what you've learned, once you get to that next stairstep up? I think about...like watching Ken and Dan argue on Twitter kind of stuff, where you have two different people that everybody knows are the guys, but then they all argue about stuff.
Interviewer: Then the same with coworkers and stuff, too. Whatever you think people need..."I do it this way, so you should do it this way," I think is...
Joe: The reason -- in useClickAway -- that we used an object was, because then we could destructure it and the order didn't matter. When you call a function and the function signature is three arguments or parameters, and then people mix them up. That was something that I learned from someone else and why I implemented it that way.
Zach: That seems like a great concept to get around. That's one of those frustrating things that you'd keep running into if you implement it the wrong way.
Interviewer: That's awesome. Because then when you talk about this, using an object, you can mention, like connects the fact of, when you call useState, it returns the array destructuring that he has to do.
Joe: Exactly. That would be a good one to...I don't know if it'd be under C1. A state hook returns a two-item array, and the first item is always a piece of state.
Joe: The second is the function that modifies, or the state updater inaudible .
Interviewer: This is a great...Say this when you teach it.
Interviewer: What about concepts of publishing? We have, "Don't bundle React," but what other types of mechanical processes, as they say in the UK...and Canada, too. What kind of processes...? I'm not in Canada...
Interviewer: around deployment, or -- I said deployment again -- publishing would there be?
Joe: Semantic versioning, semver.
Interviewer: That's a vocabulary, or it's ver...Argh! What is going on?
Joe: Yeah, I didn't...semver. Peer dependencies is another vocabulary term.
Zach: A little hint to, "Don't bundle React with your publish."
Interviewer: Obviously, hooks, semver, peer dependencies. I'm going to write useState, useEffect. Any other weird ones we can think about? Semver, for sure. There will be people who haven't had to version like that.
Joe: What Zach said, maybe a fundamental is the -- I don't know if that's a concept -- but, "Don't bundle React." You got it? OK.
Interviewer: Yeah, we got that one.
Joe: There's CommonJS...
Interviewer: Like the module exporting stuff?
Joe: Yeah, all that kind of stuff.
Zach: Would that be a tool, maybe?
Interviewer: It's more of a syntax than a tool, because then you use inaudible . Is syntax the right for CommonJS? It's a pattern?
Joe: I don't know.
Interviewer: It's not like you're installing...Are you going to use react-modern-library-boilerplate?
Joe: I was thinking about it, because it makes it very easy.
Interviewer: This is the tools section? Obviously, we're going to use NPM.
Joe: Rollup. react-modern-library-boilerplate uses Rollup.
Zach: No Webpack! Yay!
Joe: I know, right?
Interviewer: I'll still add Rollup because we...
Zach: I missed what you said, sorry.
Zach: I said, "No Webpack! Yay!"
Joe: I don't know if this is a fundamental, but knowing what type of bundle...That's what I was trying to get at, the CommonJS, versus there's an EJS file, versus the...
Interviewer: I couldn't hear you, Zach. Sorry. EJS...?
Zach: Am I...? OK.
Joe: Bundle outputs, maybe?
Zach: That's a good way to phrase that. I'm going to look at it on Package.
Interviewer: EJS? I don't think I've heard EJS.
Joe: The file is .ejs.
Joe: This is something I'll have to learn more, but there's the modules like import/export, like you were saying, and there's the CommonJS. Then there's the UMD, Universal Module something.
Zach: Definition, maybe?
Interviewer: I've inaudible this in the...
Joe: That stuff is still confusing to me. That's why it's nice using something like that boilerplate.
Zach: That's what the boilerplate solves?
Interviewer: Yeah. When you run the build command, it will output an EJS file and everything else.
Zach: Is it a CJS?
Joe: Is it CJS, is that it?
Zach: React has a CJS bundle output and a UMD bundle output."
Joe: Yeah, you're right.
Zach: This is a bundle.
Interviewer: I'll add an ETC after this.
Zach: Click around the file system on a package."
Interviewer: CJS and UMD, there we go.
Joe: There it is, yeah.
Interviewer: A bundler, bundling, or just bundle. I added a note for you to write a blog post about why you like using this. We don't have to worry about that right now. That's not your homework, that's something that you can...That will help promote after...
Joe: Another question I thought of, this library, there's a few minor tweaks that I would love to make to the library. The question is, do I use it, and then in the video say, "Hey, we're deleting this file," or, "We're updating this thing," or do I fork it and then tell them use the forked one with my updates already in it?
Interviewer: I don't know. We'd have to feel it out. How long would it take to modify...What's the scope of the tweaks?
Joe: You have to update some of the dependencies. It was using React 16.4, but hooks on 16.8. A little thing like that.
Interviewer: Maybe aim them at your fork. Explain what the library is and then say, "I've made a fork of this." What if you forked it and then published it as "-hooks" or something?
Zach: One thing that's interesting is, you could use yarn workspaces to use your own version of the package, this is what specifically that use case is. Yarn will download the package in your workspace instead of going up to NPM to install it.
That way, when you publish the changes on the real package, you strip the local package, and it'll go up to NPM. It's some sort of package resolution. I could get you more info on it.
Interviewer: The only thing with using a yarn workspace in the course, though, is if it adds more cognitive load. If they're already learning custom hooks for the first time, then...
Zach: I was saying that as more of a behind-the-scenes thing. If you're intending to update them, the time frame would be off for updating your package. This is an immediate fix. Get the local package where you need it and do your...but yeah. Adding it...
Interviewer: I thought that, for someone following at home, that they would want to use the fork. laughs Use the fork. I'm confused, Joe.
Interviewer: Let's pull this up.
Joe: There it is. Hasn't been updated since 2018.
Zach: This is what hasn't been updated!
Interviewer: Someone else's...
Zach: I thought you're talking about the custom hook module.
Zach: Never mind, scrap all that. It could be an option if you think you could get those pull requests merged. It's a nice way to skip the waiting-on-someone-else-to-merge-your-stuff step.
Interviewer: Network. I can never remember what I'm clicking when I want to look at the graph. It's Network. laughs
Joe: What does the Network do?
Interviewer: Theoretically, it will show all of the forks and who's ahead of master. It's like, this guy is ahead of master, so maybe his fork already has hook support. Even this is eight months ago.
Interviewer: 16.4.1. I would fork it yourself and aim them at your fork.
Zach: That sounds good.
Interviewer: At least then you'll know it's there, for sure, too. Then you don't have to teach them how to modify it, and you can be like, "We're going to use my fork of other dudes' work."
Zach: That's a nice next-step for a student, like, "Hey, if you're frustrated 'cause you don't understand why we're using my custom thing, go merge a PR."
Interviewer: That too.
Zach: Because there are those people that are like, "Well, this works because you have your custom thing, but it could work for everything."
Interviewer: This next section, these are the more discreet skills. This is not quite a lesson list, but this is a little bit closer to what lessons are. We're going to have, for example, use the setState hook, use the useEffect hook. laughs
What other types of things are the skills that you're going to teach them during the course? What are the types of small steps that would lead you to understand what a custom hook is?
Joe: You're just writing a function, that maybe inside of that function is using the useState or useEffect hook.
Interviewer: Those would encompassed in there?
Joe: I think so.
Interviewer: How about refactoring a hook to a separate file?
Joe: Extracting, yeah. Refactoring.
Interviewer: What other types of, more nitty-gritty...?
Joe: If you're writing the hook to...I don't know what.
Interviewer: I'll move.
Joe: We could even write a custom hook, like a state hook, and then effect hook.
Zach: Get the full spectrum.
Interviewer: Write a custom useEffect hook." "Extract a hook to a separate file," what other types of...? You had mentioned testing earlier.
Joe: Testing your hook locally. The whole testing part, there could be a mini-course on that, because there's testing locally with yarn link, there's testing locally with yalc, testing locally with Verdaccio.
Interviewer: Yelk? What was the...Y-E-L-K?
Interviewer: I haven't seen that.
Joe: I could do three lessons on how to test it locally.
Joe: If you want.
Zach: That's more than just testing the function. That's testing it as a package?
Zach: Like testing the function, testing it as a package. Maybe there's another revel.
Joe: Sorry. It's not writing tests for hook. It's literally tests. That could be one. I don't...
Interviewer: I'm so used to the Kent C. Dowds version of testing. laughs How would you reword not [inaudible 5
Zach: 26] make sure a hook works?
Joe: Yeah, exactly. That is what you are doing. You have it in a separate file. You've extracted it, and what react modeling migrate bullet plate does is it installs a create react dev folder, and then you use yarn link, and then you can import this local dependency and test it as a package.
Interviewer: Make sure hook works as a local dependency?
Interviewer: OK, cool. I'm just so used to literally tests and not just test it out. Cool. What other types of lessons do you think you would teach, like immediate skill lessons? Let's look at some of our other goals. We have extracting. I think we have actually covered all of these.
Joe: Besides publishing, yeah.
Interviewer: Besides publishing yeah. Prepare and then I really want a keyboard shortcut for that and then actually publish.
Joe: Same thing with publishing. I could show on MPM's registry or GitHub's package registry, but the GitHub package registry is still in beta.
Interviewer: Yeah. You know that the day you record that lesson, they're going to change it all.
Joe: I know.
Zach: That'd be so cool the show, not that we want to teach for a cool factor.
Interviewer: I guess on NPM doesn't really need parentheses. I guess it wouldn't even need on NPM right there anyways.
Interviewer: Go ahead, sorry.
Joe: This course is for custom React hooks. I just remember when I wrote the blog post, I included custom components. Do you think that that should be included here as well or no?
Interviewer: You could probably give them a component to start. I would assume that anybody who's learning how to write a hook can already write a component.
Joe: Right, but then the same way that you would publish a custom hook is how you would publish a custom component. Maybe it's a room to tie it in there.
Interviewer: Maybe so. You mean, if you're your demo...? I lost it. Wait. There it is behind all of the Zoom windows that are that are blocking everything. You could deploy a menu component that uses your custom hook.
Zach: The one we've been working with the whole time, so it wouldn't be...
Zach: That makes sense.
Joe: Yeah, more like, "Hey, I wrote this really cool modal component and I want to share it with people." Like, "Oh, it's the same way that I would publish a custom hook," reinforcing that idea.
Interviewer: Yeah. We would have prepare a custom component that uses the custom hook for publishing?
Joe: Yeah, that could...Yeah.
Interviewer: Then publish the component to MPM. This would be publish the hook, publish the component. Does that sound right?
Interviewer: Cool. Long term things that people will be able to transfer is create their own custom hook, publish their custom hook. Your topic lends itself really well to this because it's really easy to apply. There are a lot of things where it's like, "Well, now what?" laughs
I made a to-do list, but I can't make that jump from, all I did was create all the crud operations. People are like, "I hate learning the to-do lists." I was like, "But literally everything uses those operations."
Interviewer: When that light bulb moment or the brain with the lasers or whatever...
Interviewer: Create their own custom Hook. Publish their own custom Hook. What other long-term stuff? I guess, once it's on MPM, it's there. Use the Hook, or extract custom Hooks from existing applications to be external packages?
Zach: Would contribute to open source? The publishing your own custom Hook is contributing but, like you said, just doing this is a great stepping stone to eventually setting your sights on a bigger project or either if it's something you want to create or something that's already out there.
Interviewer: Yeah, how about I add for existing applications? It'd be work, side projects to process.
Zach: There you go.
Interviewer: You could do this for anything open source and not just your stuff. Any other long-term skills?
Joe: I don't know, being a better React developer, but that's implied.
Interviewer: This is the end of Worksheet 2. What we'll do now is we'll look over Workshop...I keep saying workshop. Let's talk about workshops for a second because I keep saying it.
Interviewer: One of the things that we've been starting to experiment with is doing paid, ticketed workshop events where we would have an instructor like yourself basically charge admission to do a remote workshop where it's the material from the course.
One of us would be in as a TA, if you want a TA around. How would you feel about getting paid money laughs to do this live, I guess?
Joe: Let's do it.
Interviewer: It's not my best pitch ever, but you know where I'm coming from.
Interviewer: Go ahead.
Zach: We also have a practice live stream that would be leading up towards it. That would be along the similar lines of the workshop, but more of a show your coworker type scenario where the workshop might have more exercises and stuff like that.
Interviewer: Now that we've cut to the end, we'll rewind a bit again. laughs Workshop 3, this one's your homework, where earlier when we were doing the numbers for stuff, this is what the lesson order would be.
Then the idea here is that...It'll be easier if I pull this back and forth. I want the second one, not the first. Oh, jeez. Let's try it like this. Too many tabs. The screen is too large. Wow, and then the zoom stuff keeps getting in my way. I keep moving it, and then it gets in my way in a different spot.
As you go through the lesson outline, the idea here is that this would be like before. This is title of the lesson. This is the description. That would end up on the web page for the lesson. Then the outcome supported is from Worksheet 1. We're looking for...
Come on now. "Did we cover all the bases? Does this lesson help you understand what a Hook is and isn't?" Yes, so that would be Outcome 1. When we get to the testing one, this is Outcome 5 and the fundamentals here.
Basically, it's like a checklist of making sure that we've covered all the bases that we've outlined. If we talked about all of this and then you come up with lessons, you don't want to get to the end of recording and be like, "I really need a different Lesson 3, and I'm already..."
You don't have to scrap everything to go back. There's also places where we could actually do this together. Where did you get stuck? I know that when you first were pitching the course, you talked about getting stuck learning how to do this. Where do you anticipate a student would get stuck trying to learn it?
Joe: Probably wrapping their head around the bundle outputs. That's definitely one. Related to that is making sure that you're not bundling React, and then knowing why you shouldn't bundle react. What are true dependencies, that kind of thing?
Interviewer: Why you shouldn't bundle React and how to make sure you don't?
Interviewer: I'll say it why/how. Then you have the blog post stuff and "Rules of Hooks" was a link. These are places where we can send people to get more help. Next steps would be, "Write your own custom Hook."
Joe: I get stuck on that, too. It's like, "OK, I know how to write a custom Hook, but what should I write down in code?" There, we might point them to, "Here's a list of awesome Hooks that the communities created." There's like...
Interviewer: That's perfect because we're not afraid to send people away if it's going to help them. A lot of people would be like, "Don't send people to other...Don't send them to Wes Bos." It's not like Coke or Pepsi. Developers, we learn from everywhere. As I whap my microphone out of the way, laughs we don't learn from just one place.
Then the other thing here that's new is we're working on adding a little bit of quizzing to the end of courses. What it is it's really like a glorified flashcard in a way where it's not literally them typing in the answer and us going and using machine learning to check the Levenshtein difference between their answer and our answer.
For every lesson, we want to try to get one flashcard of a big takeaway. If it's a code example, like this is an example I wrote from one of Ken's courses, "How would you update this input tag to call a function this.update every time a key is pressed?" You're given this and then it's like, "Ad an onChange with this.update."
Then after they see the question it's, "I didn't get it, I kind of got" or "I knew it." Then it's a self-check in that way. That's just something that we're trying to do. If you feel like doing this as you go, like what the one big take away is from each lesson, that's the goal of that. laughs
This is your homework now is to come up with...The main thing we need is the list of lessons, the lesson outline. Then after that will be the demo code which since you've already written the library, the demo I don't think would be too difficult.
Joe: What's the demo? What is that?
Interviewer: The code that you'll be writing over the course of the presentation or over the course of the course. Before you record, if you have all the code written and you know that it works, then we'll do the live community event where you walk through the course material before you record it as a practice.
Interviewer: It's really to give you an opportunity to practice the material to not waste time recording stuff that ended up being broken or didn't work or something like that, if that make sense.
Joe: I think so.
Interviewer: You think so? laughs What questions do you have?
Joe: I'm just thinking in my head the process. We are going to end this call, I'm going to do the homework, I'm going to give it back to you. You going to say, "OK, great. Let's change this." Then we go back and forth, we iterate, it's done. Then you're like, "OK, we are going to do the community demo thing."
Then, that's where I would probably fork that, let's see a lot of school updated, have that ready and then come to the event and walk it through as if I'm doing the thing from scratch.
Interviewer: Except it's not fully from scratch because you've written the code already and...
Joe: When you say, "Written the code," what are you referring to? Which code? What code?
Interviewer: Let's see like...
Zach: It would be the actual course example that would be built out throughout the course. You have like in the past instructors have done branches per lesson. We like to encourages folders per lesson in the master branch but that's an invitation.
Interviewer: I chose Sandbox of course instead of going with GitHub.
Zach: Lesson one, you can open if you're a majority.
Interviewer: I'm going to go to projects.
Zach: If you start, your first one is this is a React application with no custom hooks but it's using useState and useEffect. That's a lesson one beginning state. Then you have a lesson two beginning state which is you extracted it or whatever the step is.
Say the next one is you extracted it and then the next one is now you move into a different folder so you have your checklist or checkpoints in the code that would correlate to the actual lessons of you doing it.
Joe: If I were to do it where lesson one is a folder, is the code in the finishing or the starting state?
Interviewer: Yes. laughs
Interviewer: Whatever would be easier for you to present it. If you want to do a cooking show where it's like, "Here's how I made the stuffing," and then you bend down. The turkey is baked. You don't have to live code completely from scratch during the presentation.
Other instructors do quite a bit of copying and pasting. We did a live stream with Swyx, with Shawn. He was writing his own readouts with Hooks, or something like that. The live coding didn't work out super great. We did lots of jumping over to the answer sheet.
Really, the goal of the first live stream, the reason why we do it after you've come up with a demo, before you've recorded, is because then we can ask actual people watching, "Does this make sense?" versus you recording everything, getting to the very end, and then people are like, "Uh, which one is useEffect?" or something like that.
I realize that it probably sounds a little overwhelming and a lot of stuff. It's not as bad as it sounds. Mark Barton did Vue and Socket.io for Real-Time. What he did is he built a few different demos, and then this is broken up.
With Socket.io, you have the server side and the client side that you have to do. He would jump back and forth. As we moved through the lessons in the live stream, we'd pause after each one, "Hey, are you guys getting this?"
The demo was already done. We only had to alter one or two things from the live stream. That ended up working out better in the course.
There was an example where he was sending messages from the URL bar, using query parameters to send, "Hello World," messages. It's like, "Why don't you just make that a form so it's more clear?" Have the form add the URL params. Nobody would ever type a chat message from a location bar.
Interviewer: He's like, "Oh, yeah." 20 minutes of extra work to add the form that does it. Again, once we've had feedback from actual people, that's when the paid workshop version would come in, and then a little exercise. The material is 90 percent the same.
Joe: Got you. Wait, can you answer that question now? Is the lesson in the done state?
Interviewer: I don't know. You could have Lesson 1 start, Lesson 1 end.
Zach: Typically, what has been done is you have a start state for the whole course. We have not touched anything. Every lesson is the end state. At the end of the course, you get the final course example, and then you get the final state of each lesson where the previous lesson is the starting point of the next lesson.
Does that make sense?
Joe: Is there an example?
Interviewer: We have "Write text using the React 360 Text component." This is everything, the package JSON, everything.
Joe: By the end of the lesson, right?
Interviewer: We'll look at the commit here. Lesson 3, we'll look in the commit here.
Zach: Hopefully, that's the right one.
Interviewer: Hopefully, that'll move. I'm going to move all the zoom stuff over again. Let's see, getting more tests, client.js.
Zach: It's not going to show a true diff because there are new files for each one. If we line them up, you might be able to see the diff between the two. In each lesson, there's 5 lines of code that get changed maybe, 5 to 10, something like that.
Interviewer: We've got to have a better example.
Zach: That's the diff between each end to lesson state.
Interviewer: This one would be good. "ES2019 in Practice" which comes out pretty soon, this is a straight up refactoring course.
Zach: Hit the 12 commits.
Interviewer: That's the one.
Zach: That shows it really well.
Interviewer: That's what I was looking for.
Zach: Yeah, here we go.
Interviewer: Optional catch binding commit. In this lesson, with ES2019, you don't have to pass an error param to the catch. In this lesson, literally, you erase the E.
Joe: Doing it like commits?
Interviewer: Yeah, commit the way that you normally would write code. Don't do initial commit and write the entire thing. Do same commits because then later the before and after. Here's a refactor from for each to a flat map.
Zach: We call it a semantic git where each commit actually has meaning instead of fix. No, this fixes it. No.
Joe: Try again.
Zach: We all defaulted to that.
Joe: We would attach that repo. Is that inaudible the extra thing?
Zach: Ideally you could have this, one of those commits stacked nicely like that. Ideally, each of those commits would be in...You'd have a folder, essentially, of each individual change.
Interviewer: We did that after. We made the change after this. We found that it's worked better. That's what I'm looking for the 12 commits. It'd be like lesson one, stable sort, lesson two, optional catch binding.
Joe: I know this might be getting into nitty gritty details, but with this example, we have an existing React application with no hooks. We add hooks, and then we switch gears and we use the COI to create a new folder. I guess I just have a parent folder that has all of those?
Zach: Yeah. In the lesson that creates the new folder, that diff is just going to be that new folder now. If you change stuff in the folder, that's totally fine. You don't have to get that fine. You can if you want. That lessons, diff would be all of that new stuff that gets generated.
Joe: That makes sense.
Zach: If you wanted to, you could lesson start, and then generated code, and then lesson end, whatever you change to the generated code if you had to make some modifications. You can get fine-grained like that, but the end state of the lesson is the important point to the hit.
Interviewer: Also, when you're presenting it for people, then you have something that you can put on a separate display or something and have your answer written already.
Interviewer: How does the process feel as a whole so far, the worksheet stuff and talking it out like this?
Joe: Really helpful. Super. Just going through that whole worksheet, I was like, "Where...?" I don't know. Who came up with that worksheet because it's awesome? From an educator standpoint it's like, "Wow." There's so much thought that I haven't been putting into my previous courses or lessons.
Zach: Funny you say that. laughs
Interviewer: We've been working with learning designers like masters of education design.
Interviewer: We've been working on this for a while. That That is awesome that you are, that's what you're getting out of it...
Joe: Yeah, totally.
Interviewer: and that you can recognize that. We feel vindicated.
Joe: You can totally tell. I'm like, "Oh, man." There's so many more levels I need to climb as an instructor so that I can do this whole process for everything I teach.
Interviewer: It's just you mentioned at the beginning, the best time to start climbing the hill, it's easy to look at the people that are up there already. This type of process is a major leg up in it's not just some YouTube...
Don't get me wrong. I still watch code videos on YouTube also. You can tell when it's just somebody's messing around versus, "Oh." laughs There are a lot of things happening here.
Joe: Yeah. The workshop stuff is super interesting.
Interviewer: Yeah. We're still working on the details of that. By the time you get to the point where you'll be ready for it, we will know more about how it works anyways. The paid workshop stuff is really cool to get a different type of income from the course.
Joe: Yeah, totally.
Zach: If you enjoyed it and made enough money that's satisfying to you, you can keep doing those too, which is the cool thing.
Joe: Keep doing some workshop or...?
Zach: Yeah, why not?
Interviewer: If people buy tickets...
Zach: If there's a market, people are signing up, yeah.
Joe: The only point of feedback I have is the timing was hard. Not hard. I just got a new job and it's remote and it's flexible. You guys are probably working the 9:00 to 5:00 window depending on where you are. That would be my only concern is doing this same process moving forward.
I'm in Arizona, and I'm doing it from 3:30 to 5:00 so inaudible worked earlier. The same thing with the workshops. I don't know if that would be...
Zach: We can definitely work with you on schedule, like what would work best for you.
Interviewer: We don't have to shut everything off at 5:00 PM. I'm Mountain Time too in Idaho.
Zach: I'm 8:00 PM Eastern Time right now.
Interviewer: He's on the east coast.
Zach: It's all good. We try and optimize best for you.
Interviewer: That's what the calendar is for. As long as we know things ahead of time...It's no different than, in that regard, going to a meetup after work or something that.
Joe: That's true.
Interviewer: When you when you know that you're going to do it, it's just how it is.
Zach: Live streams are fun too.
Interviewer: Yeah, they are.
Joe: No. Yeah, it sounds like fun.
Interviewer: Yeah, the livestreams for the community, we schedule them for an hour-and-a-half. We usually are about an hour long with slush time just in case. We've done up to two hours a few times and people start dropping off a bit. It's hard to pay attention for two hours.
We also have a lot of fun. It really doesn't feel much different than what we've just been doing, except for it's your screen instead of mine laughs is basically the difference. We're there to MC and moderate. You don't have to watch the chat, because we'll be like, "Oh, hey. So-and-so asks..." whatever.
Are you going to go to React Reality?
Joe: When it is it? I don't...
Interviewer: August, something.
Zach: you at the JSConf?
Joe: I don't know. I don't have any plans right now. I know my new work will pay for me to go. I'm planning to go to All Things Open.
Interviewer: I've heard that one's really fun.
Joe: Yeah, so I'm going to that in October. Do you know JC Hyatt?
Interviewer: I haven't met him yet.
Zach: I met him at Magnolia.
Joe: He's going to be there for inaudible , the company that we work for. I'd love to go. I don't know, we'll see. I'm still getting things sorted out with the new job, but hopefully some soon.
Interviewer: Yeah. Congrats, by the way. New jobs are cool.
Zach: Yeah, awesome.
Interviewer: I'll be at both React Rally and JSConf. Are you going to Jess JSConf, Zach?
Zach: Yeah, mm-hmm. Ian will be at both React Rally and JSConf. I think Joe has met both of us.
Joe: Yeah, at Magnolia.
Interviewer: Yeah, Joe. It was good meeting you. As always, feel free to hit us up on Slack or the email thread if questions arise. I'll make sure that you're shared on all of these docs. This has been really fun. I think this course will do really well, especially as a workshop. There's tickets to sell, for sure.
Joe: No, I think when you mentioned custom hooks I immediately went to egghead. I was like, "Isn't there already a course on this?" laughs
Joe: Elijah did his course on hooks. There was only like one lesson at the very end on custom.
Interviewer: Yeah, and especially for yours to go the full zero to NPM install my custom hook, good stuff.
Joe: Yeah, it's potential.
Interviewer: All right, man. I am going to hit stop on this now. We'll send you a link to the recording when it's ready too, so you can review and everything. I appreciate you taking time and definitely excited about this.
Joe: Yeah. Thanks, guys. I appreciate your time. I think this process has been super helpful.
Interviewer: Good to hear. We'll talk to you soon.
Joe: OK, see you.
Zach: Have a good night.