Never underestimate the power of teaching. Ian reached out to AJ in regards to previous comments about React on the show and demonstrated that he knows a whole lot more than most of us, so we had him on to talk about his learning journey, the philosophy of react, and top tips for new developers entering the field. Huzzah!

Contact AJ:

Contact Charles:

Contact Steve:

Special Guest: Ian Schwartz.

Sponsored By:

AJ_O'NEAL: Well, hello, hello, beautiful listeners, and welcome back to another exciting episode of JavaScript Jabber. Today we have Ian Schwartz with us as our special guest. Ian, you wanna say hello? 

IAN_SCHWARTZ:Hi, first time, long time coming at you from Watertown, Massachusetts. 

AJ_O'NEAL: Alrighty. 

CHARLES MAX_WOOD: Wow. 

AJ_O'NEAL: We have our normal panelists. Well, actually Chuck hasn't been on in a while, but let's welcome Chuck.

CHARLES MAX_WOOD: Oh, I've been on for a while. 

STEVE_EDWARDS: In the past couple of times, yeah. 

CHARLES MAX_WOOD: Yeah. 

AJ_O'NEAL: It's true, it's true, but we haven't seen you as much as we would have liked to, and we're seeing you more now, and it's excellent. 

CHARLES MAX_WOOD: I blame Carpool. All righty. Yeah, yeah, been doing the Dev Influencer thing. Go check it out, devinfluencers.com. 

AJ_O'NEAL: All right, Steve Edwards. 

STEVE_EDWARDS: How are you doing from Portland? I am the funny guy, not one of the smart guys, but.

CHARLES MAX_WOOD: Yeah, somebody said that on Twitter. I love all the smart people in that one funny guy. 

STEVE_EDWARDS: That one funny guy. So you saw that too? Yeah, that's I sort of adapted I've adapted that from my my tagline now. Thank you Alan for that. I appreciated that. 

CHARLES MAX_WOOD: Yeah, I think we all kind of went is that me? 

STEVE_EDWARDS: No, no, yeah, that was me. 

AJ_O'NEAL: So and I have to let you know the way we do this We rotate through who's the host so I'm not the hostess with the mostest. I'm just the host for today. I yo yo yo coming at you live from sunshine coming at you live from sunshine AJ O'Neill 

CHARLES MAX_WOOD: and treadmills. 

AJ_O'NEAL: Oh, yeah, and I'm walking on the treadmill. If if there's too much noise or anything, let me know. I'm just I'm walking really slow. So there shouldn't be. All right, with all that out of the way, should we should we we just dig in? 

 

I remember working my tail off to become a senior developer. I read every book I could get my hands on. I went to any conference I could and watched the videos about the things that I thought I needed to learn. And eventually I got that senior developer job. And then I realized that the rest of my career looked just like where I was now. I mean, where was the rush I got from learning? What was I supposed to do to keep growing? And then I found it. I got the chance to mentor some developers. I started a podcast and helped many more developers. I did screencasts and helped even more developers became a dev hero. And now I want to help you become one too. And if you're looking forward to something more than doing the same thing at a different job three years from now, then join the Dev Heroes Accelerator. I'll walk you through the process of building and growing a following and finding people that you can uniquely help as you build the next stage of your career. You can learn more at devheroesaccelerator.com.

 

AJ_O'NEAL: So Ian, first of all, I just want you to repeat Ian's an opinionated guy. And I like this. I like opinionated people cause that means we can have a good debate. And maybe, I don't know, just, I assume opinionated people are smarter sometimes cause they're more assertive. 

CHARLES MAX_WOOD: Okay. I want to know. 

IAN_SCHWARTZ:It works that way. 

CHARLES MAX_WOOD: People think that AJ invited Ian. So I want AJ to tell us all the awesome things we need to know about Ian. 

AJ_O'NEAL: I hardly know anything about Ian. I, he, he is a listener. He contacted me to basically say. Hey, shut up. You're wrong. No, he didn't say it like that at all. But, but I, 

CHARLES MAX_WOOD: that's my line. 

AJ_O'NEAL: No, but he said, he said, he corrected me on something or added some additional insight and he sent via email. And then I asked him a question and he responded with something super intelligent that at least made sense to me and sounded smart. And so then I was like, Hey, we need to get you on the show because we don't have enough people talking about react and, and opinions on react and how to build react. Well,

IAN_SCHWARTZ:Yeah. And I think what happened was you were talking about some difficulties. You were having AJ with, with hooks and use effect in react JS. I don't know if you're still having those problems or not. 

AJ_O'NEAL: It wasn't really problems as much as it was magic and I didn't understand where the magic was, but I did dig down and I found the magic and now I understand it, which I can talk about a little later if we want to. 

IAN_SCHWARTZ:Sure. But yeah, I, uh, I've been developing react professionally for the last four years and I'm a senior dev at car gurus. And yeah. The first job I ever had in the industry, they said we want an opinionated JavaScript developer, and I just had made that my career, my career path, apparently. 

STEVE_EDWARDS: So they wanted you to be opinionated instead of your frameworks. 

IAN_SCHWARTZ:I was like, Oh boy, you guys hired the right guy. I got opinions. So, uh, yeah, exactly. Frameworks. Well, yeah. And if you want an unopinionated framework that requires opinions, React is definitely a good one. 

CHARLES MAX_WOOD: Yep. 

AJ_O'NEAL: And what do you mean by that? Unopinionated frameworks that requires opinions. Say that again. I mean, you're.

IAN_SCHWARTZ:Here's the thing about JavaScript, right? Is that in JavaScript, like you can do pretty much anything you want. We all know, you know, you write, AJ, you write a lot of vanilla JavaScript, right? So, you know, a lot of the common gotchas that JavaScript developers are used to. You can extend prototypes of the window and the built in data types. You can do whatever you want in JavaScript and React like really. Gives you, if you use react, I think a certain way, and you really commit to the it's really easy to work with and can be really fast, but you can also completely shoestring yourself and just tie yourself up in knotted spaghetti code way worse than anything you ever would have done. 

AJ_O'NEAL: So is there anything that that is not true of? Cause I feel like it. So for example, I do a lot of programming and go, I have met people who have managed to make go code really nasty, which is, it takes a little bit of determination to do it, but people do it. Like is there anything where people, where there's a framework that is so opinionated that is so strong that almost nobody makes spaghetti out of it?

IAN_SCHWARTZ:Probably you're right, AJ, probably not, but everything, everything gives you different, solves different problems in different ways. And you can write spaghetti code in Rust, but you're not going to write the same kind of spaghetti code you would have written in C, right? And there's problems that you're going to have in C that you're not going to have in Rust and, and I don't know, for me, the main thing that React does is it provides you with this really simple, if you build it the way I build it, which is not the way everybody does, but I think it's pretty close to the way the, you know, the React docs sort of instruct to build it. State comes from up top and it propagates down. And the only way things go back up really is event bubbling. And if you really master that, that model, it's really easy to write code that's refactorable and but you don't have to use that model. And I think for me, my first job in the industry, I was really the only, I wasn't the only person there who knew JavaScript or React, but I was the only person there who actually liked writing JavaScript. And so I was able to take ownership of a vanilla react JS product with with no redux, no crazy libraries and dependencies, hooks weren't even a thing yet. And getting to really nurture that baby, I felt like it gave me an insight that if you dive in to a project that has a lot of dependencies and has state management and has various paradigms of hooks implemented, you may or may not be able to experience that and see where those benefits come in. 

CHARLES MAX_WOOD: I'm going to chime in here real quick because I think I'm going to say this a different way, Ian, and you can correct me if I'm getting this wrong. But essentially what you're saying is, is that there are certain principles that kind of give you a broader happy path. And if as long as you adhere to those in React, then you're fine. But when you deviate from those, then you probably gonna start to have problems. And where my experience, I hear you saying yes. So let me continue on this for a minute because let's compare it to say Angular or Vue. They give you much broader set of the things that they will do for you and do to you. But what they're doing is they're broadening out that happy path, but eventually you're going to get to the edge, right? It's just that reacts since it's simpler. And then you wind up bolting parts of your stack on top of it. React itself gives you a fairly narrow happy path with fairly simple principles to adhere to. Whereas the others solve a lot more problems for you in a lot of different ways. And so here, yeah as long as you do react the way that it's intended, you're going to be fine, but you're going to get to those edges a lot more quickly because react just doesn't do as much for you on its own. And that's why we rely on other things like state libraries and stuff to get the rest of the work done. And they have their own happy paths and give you more, a more broad place to go wander for your code. 

IAN_SCHWARTZ:Yeah, I think that's a fair way of putting it. I mean, trying to say I mean, I have a lot of horrible pics. I'm sorry. The react is so it means so many things to so many different people. And it can just be, some people say it's just the view layer. Some people, you know, every single line of code they write is within, is using React. And some people, you know, I try to write as much of my code outside of React as I can and just have React be responsible for the view layer. But yeah, you're right. I mean, there's from company to company, even the face of what a React app looks like, actually seeing debates online, people argue about books and, and about various state management libraries. It's like you guys don't even know that you're talking about the same thing. I mean, literally your react and my react could be, depending on what we've seen and what we've worked on could be very, very different code bases. Cause it's just so, it could just be the view layer in the MVC pattern or it could be where you put everything. So, you know, one of the things we were talking about kind of before we started was I have never actually written a redux reducer I've worked on. I've never done it. 

CHARLES MAX_WOOD: I think you're a unicorn. 

IAN_SCHWARTZ:I keep looking for a reason, Chuck, but React actually gives you what you need to... Like Redux to me, there are really good... Okay, let me say this a different way. If I was gonna put something into global state in my app, I would have to have a really, really, really good reason. And I just haven't ever written in four years a line of code that needs that kind of granular access to global state that Redux provides, as opposed to just having a context for something that's mostly read-only, like your theming state or things like that. But yeah, so I React for me has enough that I don't have to actually reach out. And even though it's there on projects, I've always felt that code is simplified by, you know, the whole reason we have React is to not use global state everywhere. Right? That's the reason why it exists. And when you start developing React, if you're not using the React compositional model, right, you're still thinking about where do I put this piece of state? How do I, how do I change this piece of state up in the tree? Redux gives you really great ways of doing that, but I don't think that that's not the way that I think about React. 

STEVE_EDWARDS: So real quick, before we get too far, I want to, one of those people that doesn't have a lot of React experience, and for those who might be listening, can you explain real quick what Redux is and what reducers are? You just sort of threw those terms out there, and so. 

IAN_SCHWARTZ:Sure, sure, so. 

STEVE_EDWARDS: For the unknowledgeable, if you could explain. 

CHARLES MAX_WOOD: Yeah, Steve, it's Vuex for React. 

STEVE_EDWARDS: No, yeah, I understand that. Yeah, I understand that. 

CHARLES MAX_WOOD: I know, I'm just giving you credit. 

IAN_SCHWARTZ:Yes, yes. Yeah. So basically Redux is an implementation of the, of the flux state management pattern. And it revolves around having 

AJ_O'NEAL: flux state management pattern. 

IAN_SCHWARTZ:I'm getting there. I'm getting there. I'm getting there. So when react came out, Facebook came out with this idea, they called it flux and it was their state management pattern. And the idea is that you have stores of data in various places around your app. I've never, I'll be honest, I've never really like nerded out on Flux. But what I do know is that Redux uses that same model, but you basically have this one central global data store. Okay. But that data store is actually immutable. You can't, you don't change the data in it. Instead you send messages to it and reducers are functions that accept a message and then in response to that message where there's a limited number of them will give you the updated state back.

STEVE_EDWARDS: It was sort of like actions and views, but it sounds like if I remember correctly. 

IAN_SCHWARTZ:Yeah, for sure. Actually, there's a great JavaScript jabber where Dan Abramoff came on from like four years ago and talked about Redux and kind of his motivations. But React has in it this, this whole top down data passing model where you, you have a piece of state and you pass it down through props to child components. And so people reach for Redux. They reach for there's concept of prop drilling where you're passing down those props through a ton of levels, right? Well, we don't want to do that. So maybe it's better to just have it in some central place. Or how do I get this piece of data to be readable in two different parts of this top-down tree when they don't share a common ancestor until really, really far back? It also has the benefit of being able to time travel debugs if you track those messages. It's a state machine. It's a finite state machine with Redux, you can actually like, at least you could, I don't know if you still can, but you could walk through the messages that had been sent to your Redux store. In my experience, I've seen a lot of, the stuff I've seen Redux used for is usually stuff, but you shouldn't, I don't think you should have the state of whether or not a single button on the page somewhere was clicked in your Redux store. To me, that represents some flaw in the architecture of your app. 

AJ_O'NEAL: But what if it's like light mode versus dark mode? Isn't that something that's going right? or authentication. 

IAN_SCHWARTZ:So yeah, light mode and dark mode are global. And if I was gonna use global state in an app, certainly something like theming is the right way to go, right? Because you're talking about something that's mostly gonna be read everywhere, probably a very limited number of things are gonna be interacting to change that, right? Not every component on your app is gonna be able to change from light mode to dark mode. And so, yeah, I mean, that's perfectly primal use for Redux, but that could also be in a context at the top of your app because it's not going to be changing a lot. You're not going to have to worry about some of the problems. 

AJ_O'NEAL: So what do you mean the context at the top of your app though? 

IAN_SCHWARTZ:So React offers a model called context where you can skip prop drilling by saying you have a context provider high in the tree, and then children below can be registered as context consumers. So maybe you would create a context provider for your theme that stores a piece of state that says whether we're in light mood or dark mode. Right and then any child component that needs to know if it's in light mode or dark mode would be a consumer of that context. And any child would be a consumer of that context. And you have to provide sensible default, or you're supposed to provide sensible defaults that if you don't mount the parent, you know, the provider, it still works, but that's, you know, that's a very fundamental part of React. And it's used all over the place. If you're using popular libraries, like, like Formic, for example, relies heavily on context. 

AJ_O'NEAL: There are downsides. 

IAN_SCHWARTZ:Sorry. What did you say?

AJ_O'NEAL: I was just gonna say, I'm looking at the documentation right now and their primal example is light theme context, light or dark. Okay. 

IAN_SCHWARTZ:The problem with giving too many different components, the ability to change state is that you don't, you then have to start worrying more about where those changes are coming from. And so for me, what I really want in react app is anything that's going to change the state should be at the top of the tree and it should be triggered by. By events bubbling up, which is pretty fundamental part of front end. 

AJ_O'NEAL: So two questions that I have that may tie together. One is, did you believe in React without Redux before hooks? And the second is, do you still use any of the other stuff now that hooks are available? Because I just got introduced to it with hooks and that looks a lot simpler to me and a lot easier to digest mentally as well as to write out in code. 

IAN_SCHWARTZ:Yeah, yeah, I did not use Redux before hooks were available developing React professionally when hooks came out. At the time, React was really pushing this idea of container and component pairs, where you had an outside component that was the container that managed the state. So if you had like, for example, a modal, right? You might have an outer wrapper that manages the state of whether the modal is open, and then that wrapper would return the child modal, which would be a presentational component. And at the time, you couldn't have any state in pure presentational components, you had class components that were stateful and then these simple arrow type components or function components that, that couldn't have any state or side effects. And when hooks came out, it's simpler and it's not simpler. But yeah, I definitely did not use Redux before hooks. 

AJ_O'NEAL: Is it still relevant to talk about the other stuff? Like the old class style, is it still, is it still relevant if I was going to create a new react application? Is there any reason that I would ever reach for that as a tool?

IAN_SCHWARTZ:Yeah. I mean, the React team has said they're not going to be deprecating them any time soon. Obviously I think the thought in the community is that it's coming someday. 

AJ_O'NEAL: But well, being deprecated and being useful are two different things. Is there unique utility is what I'm driving. 

IAN_SCHWARTZ:Yeah. Well, look, every line of code that I write, the whole point is it should be easy to understand and easy to grok, right? And if the easiest way to express the, the thing that you want to do is using life cycle methods in a class based component then look, I mean, it's your code. And at the end of the day, you're the one who's gonna have to maintain it. And if that's, if you're gonna come back to it and it's gonna be more clear to you, then yeah, I would say totally go reach for it. 

AJ_O'NEAL: Okay, let me try again. Do you reach for it? 

IAN_SCHWARTZ:No. 

AJ_O'NEAL: Okay. But that's only because hooks 

IAN_SCHWARTZ:are closer to what the React team had in mind in the first place. And I think they lend themselves really well to it. You know, there were a lot of issues with class-based components that I ran into. And this may have been my inexperience at the time. Hooks came out, I'd been working in React for what? A year, nine months or something when Hooks came out. So it's possible that I was using class components completely wrongly at the time. But for me, it was really easy. They were confusing. I didn't like using this first of all, which sounds stupid, but I just didn't like it. I didn't like having to bind functions before passing them down, which is somewhat solved with error functions, but still. 

AJ_O'NEAL: Well, it was really hacky. 

IAN_SCHWARTZ:It was hacky. We'd end up writing the same code in component did update and component did mount all the time, right? You check it when it mounts and then when it updates. To me, hooks are simpler, but also they provide you with something that I didn't know how to do with class components, which is to separate the logic of the app from what is being rendered, right? There was, to me, there wasn't as easy of a way. If you could express something as a pure function, you could use it all over the place. But how did you take stateful functionality out of a class component and use it everywhere and really isolate it and test it? And it was challenging. The testing paradigm at the time was to use enzyme and shallow mounting seemed to be the most popular things. That's what we used in our app. And I hated enzyme. I didn't like shallow mounting. So- 

AJ_O'NEAL: I don't know what either of those mean. 

IAN_SCHWARTZ:Oh, so shallow mount. I'm just going to keep dropping terms and I'm sorry if this is. 

STEVE_EDWARDS: I'm going to jump in here and have you clarify a few things here in a minute. 

IAN_SCHWARTZ:So sure. So when we were using class based components, at least at the place I was working, we used a testing framework called Enzyme. And Enzyme allowed you to mount the component, but not mount all the things underneath. Right. And so you didn't have to worry about mocking out or providing the data for all the child components to render. You were able to actually mount a component. They called it shallow mounting and then call the instant methods on that class instance methods on that class one at a time and unit test them in the traditional way. There's a great, oh god, I should see if I can find the link and send it to you guys. There was a video by Ken C. Dodds who wrote React testing library where he shows some really great examples of unit tests with enzyme where he then goes and deliberately breaks the component and the tests don't break and then other, then he goes and he changes the component in ways that shouldn't break the tests and it, you know, that don't change the way it renders in the final app and it does. That was how we tested class-based components at the time. And I found it very clued. Just everything about class-based components to me was so cludgy and hard to wield. Functional components give you a really nice way of creating something small and kind of expounding on it. 

STEVE_EDWARDS: Yeah. Okay, so let's jump back a little bit here. Please jump back, jump back, yes. 

IAN_SCHWARTZ:Jump back. 

STEVE_EDWARDS: First of all, for those of you who can't see, Ian is doing a fantastic job of illustrating with his hands all his concepts. Unfortunately, you will not be able to see those because this is an audio only podcast, but I just thought I'd share that with you. So now let's again, I'm coming, you know, from person outside of react. 

CHARLES MAX_WOOD: In his defense, I do that too. 

STEVE_EDWARDS: Oh, yes. Oh, I do it myself too. But I was just I just thought it'd be illustrative purposes, it would enhance the podcast experience if I explained that.

IAN_SCHWARTZ:I assume users will hear the echo location of my voice bouncing off my hand. 

STEVE_EDWARDS: So anyway, so we were talking about hooks and when they came in now, class class based components, I guess was the paradigm prior to the arrival of hooks. Now, usually when I think of hooks and I think, uh, from a software development standpoint, the common understanding of what a hook is is like, okay, here's some program I'm doing something. Okay. Now I'm going to give some other program, whatever a chance to jump in. Cause they want to do something at this point. You know, I came from the Drupal world where you had all kinds of hooks. And if you created a custom module, you and I want people to hook into your process. And so my understanding from things I have heard from people talking interact these is that hooks, that's not really what hooks are. Um, it's sort of a, they sort of co-opted the name hooks and used it for another purpose. So can you explain what hooks are in React and maybe how they're different from what you would normally think is a hook in programming? 

IAN_SCHWARTZ:Sure. Yeah, I mean, they're very different from what you think is a hook, although, well, yeah, let's get to it. So hooks are a way of, okay, so React follows, I would not call it pure functional paradigm, but they're definitely gesturing towards functional programming with a lot of what they've done with React. And so the emphasis in React was always on pure functions on writing as much as possible. But obviously you need a way to make your code be stateful and effectful in any somewhat functional environment. Hooks are, they're just, I heard them described as the missing primitive, right? It's not a pure function. It's, it's, it's, oh, let me explain a little simpler actually by talking about kind of the two most common hooks because I think they sort of answer the question by what they are. The two most commonly used hooks are the useState and the useEffect hook. The useState hook is really simple. It returns a variable that describes your state and another variable that describes the state setter object and allows you at any point in your React app to say, here's a piece of state I'm gonna interact with. Okay, useEffect allows you to limit, in React every time you change anything, the components re-render. And useEffect allows you to limit side effects to when only certain things change. So only make a data request, a fetch request, when specific prop changes as opposed to constantly. But what makes them really powerful is that you can take hooks and turn them in. You can write custom hooks that wrap them. So you can take a piece of functionality that is stateful or effectful and actually put that into a hook of your own, you know, use data request or use, I don't know, whatever they all start with use. So they're extendable ways of encapsulating stateful functionality. And depending on how you write your app, you know, at the top of every component, you might have 30 calls to different hooks, or, you know, you might take those hooks and encapsulate them as, as a custom hook that, you know, kind of works more in the way you're thinking of as a hook, a little thing you can sort of drop into and a piece of functionality that you can call out of, yeah, sorry. I don't know if that answered your question at all.

STEVE_EDWARDS: Yeah, for the sort of yes. Yeah. I hear, I hear people talking about writing custom hooks all the time and that they can reuse in their own applications that. 

IAN_SCHWARTZ:It's sort of like explaining what a custom function is to somebody who's never really written functions, right? If you were coming from like basic background and using go-tos, how would I explain functions to you? You know, they're, it's a little easier once you get your hands dirty with them. 

AJ_O'NEAL: So I want to try to explain, sorry, finish your sentence. 

IAN_SCHWARTZ:Please, please. No, please. I'm, I'm really screwing this one up. So please AJ dive.

AJ_O'NEAL:So I'm going to kind of recap my experience. So when you have a, I don't remember whether it was use effect or use hook. I think it's use hook. It gives you back a getter and a setter. So you state, sorry, you state, you state gives you back a getter and a setter. And so you don't, if you were to console.log these, I think they're functions. I didn't actually do it, but they're not. It looks like it's a value object, but it's not. And you don't assign a value to the thing that when you read the code, let's say it's called shopping cart. You might think shopping cart is maybe an array that has items in it because you define it, you set it as an array, but actually it's a function that's a getter. And then you have another one that's called, say set shopping cart. And when you call set shopping cart, you pass in an array. So every time you call use effect, you get a getter and a setter. And behind the scenes, it's managing a lot of thisness without this. And when you create a custom hook, you're essentially encapsulating one or more sets of use state that you're going to simplify in some way. So maybe you pass in some options and it changes the default value or changes. I don't think you'd really change what it binds to per se, but this is... 

IAN_SCHWARTZ:Let me give it, can I give an example? That might help. 

AJ_O'NEAL: Yeah, go ahead. 

IAN_SCHWARTZ:So you know, really great example would be of a piece of code that any React Dev is going to write a million times is if you have like a modal that you want to have opened or closed, right? Obviously, React, you know, you don't reach out and open the modal, you change the piece of state that says whether the modal was open or closed and that change propagates down and the modal either appears or doesn't appear. Using use state, right, so you would const modal status and then set modal status would be the name of the setter function equals use state, right? And now you have the modal status is your piece of state, the set use status is your function. And every React developer ends up writing a function that looks like toggle modal status where instead of passing down that state setter, maybe they have a function that you just call as a callback that you pass down that knows to toggle it. And you could take that use state call and the function that toggles the state and encapsulate those and then not have to rewrite that piece of functionality all over your app. 

AJ_O'NEAL: And that would be called use toggle state. 

IAN_SCHWARTZ:Use, use modal, use toggle state, use hideable. There's a million. Semantically naming it is the hard part of the job. Or it's the easy part. 

AJ_O'NEAL: Well, it just starts with use. It has to start with use, right? 

IAN_SCHWARTZ:It has to start with use to. 

AJ_O'NEAL: And that's enforced. 

IAN_SCHWARTZ:Yes. Yeah. That's enforced by the transpiler. Beyond being enforced, I think it's a good practice too, because it instantly tells you when you see it, this is not a pure function, this is a hook. And it's important that you know it's a hook, because that means that it has state or it has side effects almost certainly. 

AJ_O'NEAL: So in a way, it almost kind of gives us a manual, dare I say, observable. 

IAN_SCHWARTZ:Sure, yeah, you could say that. 

AJ_O'NEAL: So while we're on this topic, there's something I wanted to talk about was the why use effect was confusing to me and use, use state use effect were confusing to me, which I think might as well go here. So they carry state and they carry thisness, but they don't use this. You never type out this. Right. And if you are a JavaScript developer with some experience, when you look at the code, it should make you scared because there is no indication of where the state is held or how it's checked or validated or there's there's no lexographical indication of where that state is coming from or going. Which is why at first I thought that it must be managed by the transpiler. The transpiler must be rewriting the function and then inserting some sort of state object in a similar way that's been done in some of the test library. But it turns out, rather than calling all of your components or functions, and you're probably familiar, especially if you were familiar with the old way of doing React, with the idea of doing a function.apply or a function.bind. 

IAN_SCHWARTZ:Sure. 

AJ_O'NEAL: What they do is when they call the function, rather than calling the function with function.apply so that the this variable goes into the scope of the function, they maintain a state object that gets pushed and popped. So when they call your component function, they push the state for that function onto the state stack. And when you call use effect or use state, it operates on the current index in the state stack, which if that sounds confusing, it's because it is and it's not a normal way to go about things. It's kind of a hack, but it's a hack that hides thisness from the user so that it looks like magic, but doesn't require a transpiler. 

IAN_SCHWARTZ:Okay. Look, I'll be honest with you. I'm not, I think I told you before I came on, I'm not, you know, you guys often have, you know, library authors and framework authors. I'm a, I'm a dev on the ground using react. Regardless of what may or may not be going on behind the scenes, it's been my experience that use state is usually a pretty easy model for people to use it. Use state in particular, it's a little hard, but it's not harder than using the class space. 

AJ_O'NEAL: Oh, I'm not suggesting that it is. I'm just saying that if you have experience with classes or prototypes in JavaScript or just general state management, when you look at a function inside of another function that you're passing at a closure which is keeping track of state that's specific to the function it was created in without any tie to that function. It just looks weird because it's where did the state go? And I was just for people that are listening, that are coming across this, that are like, what the heck, how is this thing working? I was just trying to give the best explanation I can that the state is there. It is being managed. It isn't magic. Just looks like magic because it's a bean counter in a side channel rather than being something you see lexicographically as you're writing the code. That's fair. That's totally fair. 

CHARLE: Yeah, I have to say though, that I really do like, I've written a couple of React native apps. I haven't done a whole lot with React on the web, but yeah, the use state functionality, I just followed the examples and used it and then figured out later what it was doing. And so initially it looked weird to me and then, but I didn't do my homework either, right? I didn't go and actually figure out how React works. And once I figured it out, once I was like, oh, this is what this is doing and, oh, it does all this stuff automatically for me. And I can make these certain assumptions about how stuff does. That's when it got really powerful. Cause then it's like, Oh, well, I'm going to use this all over here too. Cause it, it's just going to do all the work for me. 

IAN_SCHWARTZ:Yeah. I think that's, that's a really fair point. I mean the react, you know, you state is honestly for me, I think it's been a blessing. I really did not like doing state management in, in life cycle methods. Because it was just, for me, it was just hard to understand where it was going to, where things were going to re-render, when they were going to re-render. It was easy to get into infinite update situations that I've never gotten into since Hooks came out. And you know, the other thing to your point, AJ, is that I think I would argue that the most people who are learning React and who get started with React don't necessarily, a lot of people get started React fairly early on in their JavaScript careers now, which obviously may or may not have been how it was when I started it, but you know, not everybody is in a position to look below the hood. And it's awesome that you are, but I only kind of half understand what you're talking about. 

AJ_O'NEAL: Well, that's, that's okay. What I, so for me, it's important to understand the language itself, right? Typically languages are very, very small and you can, uh, a language typically has somewhere between 20 and 50 keywords in it. And there are only, you know, a dozen or so constructs that you use with these keywords, like for example, a for loop. For is the keyword, for loop is a construct you use out of the keyword. So I do believe that it's important for people to know JavaScript. And I've heard from a lot of React developers that they wish they had learned JavaScript before learning React, because React in essence is a language that is built on top of JavaScript in the same way that TypeScript is. And in fact, you have people that are using both React and TypeScript. So they kind of have two languages that are built on top of JavaScript. And for me, it's important to understand the difference between what am I doing that is JavaScript and what am I doing that is this other language that's being built on top of JavaScript? And so for me, if I look at something and I know that there's not a reasonable way to do this in the language that I'm using, I get scared because if something is just magic, that means that when it goes wrong or when it behaves on it, well, one, I don't know how to expect it to behave because magic, if you watch Harry Potter, magic doesn't have a system where it's like, oh, I use so much Polyjuice potion, therefore it'll only work for so many hours. It's just, you throw a bunch of stuff in the pot, poof, you take a drop, you take a vial, it doesn't matter, it's gonna work, and you don't know how. There's no science to it. It's magic. And so I don't want things to be magic. I want them to be science so that I know that I can predict and expect, and that when I write code, my code will operate according to my expectations and predictions. And if I can't draw a connection between what's presented and how it will work, I need to know that when I hit the gas pedal, it's putting in more gas and that's causing the car to go faster or it's giving less resistance and that's causing the electric motor to turn faster. I need a model of operation or knowing that when you're an electric car and you hit the brake, there's no brake line. It's electronic. Something goes wrong with the computer, the brakes don't engage. That's important to know if you're driving a car, for example. I don't know if those are good examples or bad examples, but. 

IAN_SCHWARTZ:That said, I don't know that I could tell you how the brakes work in my car. I know that you press the pedal and the car slows down. I assume you can break that somehow. 

AJ_O'NEAL: Hopefully. Well, it depends. 

STEVE_EDWARDS: It's this concept called friction. 

AJ_O'NEAL: But it depends on whether they're electronic brakes or whether they're cable brakes. If they're cable or hydraulic, then you know that when you press the button, the brakes will engage. This is guaranteed. If you're in an emergency situation, the brakes will work unless the wires cut. If it's electronic, it responds to the amount of pressure you give it. It makes a lot of guesses. It can take longer for the brakes to engage. If you switch from a gas vehicle to an electric vehicle, you'll notice the brakes don't engage the same way. They take a lot longer. You have to apply more force. You have to be more calculated. And when you hit the brakes, I total tangent, 

IAN_SCHWARTZ:totally fair, totally fair. I think, I think for me, the thing that I focus on when I'm learning something new and the thing that has helped me with react and with learning hooks in general is there's kind of two ways to learn react, right? You can try to learn the API surface and understand what everything does. But the truth is that for most of the hooks that react provides, you could probably write most apps with just use state and a few use effects calls when you really needed them. Most of the other ones and including use effect, you know, once you need them, there's nothing else that will work for them, but that doesn't necessarily mean that they can't be used for other things. So one thing, a pattern I saw a lot, for example, was people at a job I had was rather than passing changes up as event bubbling, what people would do is they would use use effect to call a state setter that had been provided by a React use state hook, which to me is like blasphemy because once you start passing down raw state setters and then letting use effect hooks change them willy nilly, you stop knowing where state changes come from. And that's exactly what happened. There was a point where I would literally type something in the URL bar, like a search query params and they would just get overwritten every time. And I went on like a two week thing going through this code base, looking for all the different use effect calls that overwrite the URL search query params. It was exhausting.

AJ_O'NEAL: That's what I'm talking about. Like you don't want it to be magic. You want it to be predictable, 

IAN_SCHWARTZ:but the magic's okay. If you're using it because you know that that's because there's no, you need your car to slow down when you hit the brakes. Right. And so use effect comes in. If you try to do a side effect in your react app without a use effect call, right. It's going to happen on every rerender, which in some react apps is a lot of rerenders. 

AJ_O'NEAL: Yeah. I'm 100% on board with you. I'm not saying that it is. I'm not, I'm not having any argument against use effect or use state. They are the right thing to use. I'm just saying like just what you presented. 

IAN_SCHWARTZ:Yeah. 

AJ_O'NEAL: Doing things in that pattern where it became unpredictable to determine why the URL was changing is that is something that I would consider to be magic. It's something that someone intended this to happen. They intended it to happen without the user having to have the burden of understanding it, but then when the burden hits of needing to understand it, it hits hard. 

IAN_SCHWARTZ:Yeah, I could see that. There was a great, I think I sent you guys in the pre-show thing, there's a great article I just read called Use Encapsulation, which I loved. I forget who the author was. I can look it up again. 

CHARLES MAX_WOOD: Kyle Schevlin. 

IAN_SCHWARTZ:Yeah, the idea to me that every time you call a use effect, it should be in a custom hook to literally just. I mean, that alone, that rule would just make it so that people stop using it all over their apps. If you know, you had to justify its use every time. And that's kind of what I meant at the beginning, that React will let you do whatever you want. You need to have a little discipline with React and you need to, we don't need to, but you know, it helps, in my opinion, to spend a little time really understanding the mental model that React encourages. 

 

Are you ready for core web vitals? Fortunately, Raygun can help. These modern performance metrics play an important role in determining the health of your website which is why Raygun has baked them directly into their real user monitoring tools. Now you can see your core web vital scores are trending across your entire website in real time and drill into individual pages to focus your efforts on the biggest performance gains. Unlike traditional tools, Raygun surfaces real user data, not synthetic, giving you greater insights and control. Filter your score by time frame, browser, device, geolocation, whatever matters to you most. And what makes Raygun truly unique is the level of detail they provide so you can take quickly identify and resolve front-end performance issues with full waterfall breakdowns, user session data, instance-level diagnostics of every page request, and a whole lot more. Visit raygun.com today and take control of your core web vitals. Plans start from as little as $8 per month. That's raygun.com for your free 14-day trial. 

 

CHARLES MAX_WOOD: Well, and to that point, I mean, going back to whether it's useState or useEffect or something else, if you're learning React and you're kind of getting your hands around it, you've got two examples of hooks that just do this particular thing, right? And then as you get deeper in, then it's okay. Now that I understand the fundamentals of how these work and I understand how some of this stuff goes together, now I can create my own hooks, right? And so now you can level up and kind of wave away some of the magic that makes AJ uncomfortable. I remember just going back a little bit, going back a lot a bit when I was learning Ruby on Rails, right, I just did everything the Rails way. I didn't know how it all worked. I didn't even know that I was supposed to care how it all worked. And then I started learning Ruby, right? And I started learning the underlying stuff there with Ruby. And as I picked up Ruby, I realized that Rails was taking advantage of a lot of the things that Ruby gives you. Right. And it's the same way here where you start using use state and you start using a use effect, and then maybe you write your own hook and you start saying, okay, now that I understand how this works and I understand how these pieces fit together, I can now make better calls as far as what I care about and how that works. And then I get like use, I don't know, use some other, use logo, I guess, right? And so under certain circumstances, the logo updates, right? Or use, like use hidden, I think is one example you were doing, right? Where, okay, now I only care about this one thing and I want it to do this one specific thing and I don't have this massive use effect that I'm working off of. It just does the right thing based on maybe some other use state or something like that. But I can make it all come together and make it work the way that I want. And I can now create these places where it's really easy to figure out this, this concern is encapsulated in this book and this other concern is encapsulated in this other hook. And I kind of see what Kyle's saying in this article, because I was like, yeah, that makes a lot of sense.

IAN_SCHWARTZ:The goal to me with Hooks, the thing that like before Hooks came about, right? I always used to say that my goal when writing a component was to be able to let the other people on my team just drop that component in without them having to understand how it works. And Hooks allow you to extend that same thing to not just the visual parts of your app, but the actual functionality, right? The truth is that every dev on your team shouldn't have to know what the pattern is for updating the title or making a network call. And okay, so one of the things that really helped me early on in my career as a React developer, as JavaScript developers, I love learning other languages. I consider myself a JavaScript developer. I don't write JavaScript outside of work. Everything that I write outside of work is in another language or framework with the intention of bringing the more concepts back. Okay. And so one of the first languages I learned that wasn't JavaScript was Forth. And Forth really encourages you to build up. Lispers say the same thing, a vocabulary of higher level, a high level vocabulary to describe the low level things you want to do so you don't have to think about them. And writing forth without actually factoring your code and you should be able to call a fourth word and not have to know what was in that fourth word. And to me React, look, Lispers will hate if I say this, but it is kind of a Lisp and it is like it does give you the ability to create this high level way of making the low level things that we need to build a web app, which is HTML.

CHARLES MAX_WOOD: And, uh, right. And then going back to your ideas around kind of a high level react, right? Where you pass state down and you bubble behavior and state back up. Then all of a sudden, yeah, if I need something to change in a downstream component, then I just changed the state that it depends on, right? And then it essentially does what it's supposed to do out of its hooks. And yeah, it can be completely opaque. I mean, you can go look at the code, right? But for me, it can be completely opaque and I don't have to care about what that component does, I can just use it. And as long as I'm making the correct assumptions about how it goes, this opens up a bunch of possibilities. And then if I do need to customize something against it, then I have that option, I can go dive into the code that makes it up. But in the meantime, it's, hey, this reliably does the job that I need this part of the page to do, given certain state and then reacts to things inside of it given certain behaviors or certain actions. 

IAN_SCHWARTZ:That's right. And you know, the truth is that it doesn't have to be, you know, when you start writing code, you don't have to say, oh, I'm going to write this custom hook that's going to do this thing. A lot of times as you're building a component, if you see 10 or 12 calls to hooks on top of the page in a component, likely that is, it's probably not one thing that it's doing. It's probably doing three or four different individual pieces of functionality on a page. Nobody can keep all that in their heads. And so- 

AJ_O'NEAL: I know one man. I'm not going to disclose his identity, but I do know a guy who can keep when he starts a project he sits down for two weeks about two weeks is what I've observed on him on a couple of different projects Plays with a Rubik's Cube looking at the screen and after that two weeks. He knows the code base and he can operate in it holding it what appears to be entirely in his head 

IAN_SCHWARTZ:I'm not even talking about knowing the code base though AJ. I'm talking about I'll see a PR that has a 500 line and you just, you can't, you can't know what you're looking at. 

AJ_O'NEAL: I know. I was just, I was just being facetious, but also serious. I do know one person who can hold it all in his head, but it's a superpower. 

IAN_SCHWARTZ:Yeah. Well, we'd all be so lucky. 

CHARLES MAX_WOOD: Yeah. But this, this is the idea behind react at the same time. You know, what you're talking about is that you've got this reusable set of things. Right? So if I'm putting a car engine together, I know I have eight pistons on eight chambers that innate fuel injectors and Okay. You know, older cars, I get, I get it. Okay. But you're right, but you get the idea, right. And it's the same kind of thing. And so they can all be in different states, but at the same time, they all work as one whole to get the job done. And yeah, you may see it calling, yeah, a whole bunch of callbacks, but what it's doing on, on the flip side is that a, a lot of times those are broken up so that. Uh, I can't hold it all in my head. Right. And so I'm going to look at it and yeah, it's doing 12 callbacks or 12 12 hooks, it's calling 12 hooks to do three jobs. But if I have to go change it, I can figure out where I need to change it, right? And the overhead on that isn't so much that, for the machine, that it's not worth doing it that way. And so then I can make it, continue to make it more reliable and then stamp out all the places that it needs to be on the page. And so- 

IAN_SCHWARTZ:That's right, it also gives you a smaller surface for testing as well, which I'm big on testing. Yeah. And if you see 10 or 12 component hooks calls on top of the page, I would assume that you don't have great tests covering that component because yeah, that would be hard to write. 

CHARLES MAX_WOOD: It's interesting to see how different people approach it though, because there are exceptions to every rule. But yeah, I mean, I think the most that I've seen is like three or four hooks that I've had to write against a component and I'm not efficient. Oh yeah. Yeah, I'm sure. But that's what I have. Yeah. Yeah.

IAN_SCHWARTZ:And, and react, you know, they teach it in boot camps. So people learn it when they've only been doing JavaScript for a few months. Now there's, there's plenty of the blind leading the blind going on the react community, which isn't a dig against anybody, you know, I think no code that you're good. And, and, uh, but I've seen patterns in docs for popular that pattern. I was talking about, about use effect for calling, for changing the state center that was provided by react. I've seen that in docs for popular libraries, plenty and without maybe names, so, you know, the idea that, you know, when I talk and I want to emphasize that when I talk, if I say the words right or wrong or, or, you know, have any value judgments about people's code, we've all written plenty of code that somebody could point to and say, you know, that's questionable or that's not questionable. To me, that's the other benefit of hooks is that it lets you kind of isolate those, those, those instances, you know, the more encapsulated your code is, the less you have to worry about that sort of thing. But it's challenging. And, you know, truthfully, we as JavaScript developers, we're not used to thinking with you know, you can do a lot too with what kind of state you're passing down. When people talk about prop drilling and you know, one of the pain points in React is I'm passing down too many props. Every component has all these props. Maybe those props can be represented by, you know, a data type or some algorithmic using some actual programming and not just, you know, passing down. I think Dan said in one of the, one of the podcasts recently, the JavaScript developers only use arrays for everything. And you don't have to. You can pass down, like when I write React components, I really like the things I pass down to be sort of knowledgeable models. Cause I came, I started with Rails as well, like you Chuck, and you know, Rails is very MVC. And if you were writing all of your Rails code in your view component, then people would tell you, you know, there's skinny view fat model, skinny controller fat model, and fat controller skinny model. There's no fat view version of Rails. Nobody's advocating for fat views. And you know, you can skinny up your react code the same way, which is sort of my personal. 

CHARLES MAX_WOOD: Yeah. Well, I'm going to throw, I'm going to throw you for a loop then if you haven't done rails in a while, but, uh, no, the there's a, there's a developer at GitHub that created a view components library for rails. And so now you can actually go in and instead of using partials, which is what we did before, you can use view components and they have a lot of this behavioral stuff that we're talking about built into that. And then if you want to get real fancy, you can drop a react component or a stimulus or something else on top of that. And now you've got the best of both worlds in a lot of ways, or the worst of both worlds if you if you're doing it wrong, 

AJ_O'NEAL: but so when you said view in that context, did you mean VUE or VIW? 

IAN_SCHWARTZ:Or it's a lot. 

CHARLES MAX_WOOD: It's a rails view. It's the HTML template for the page. 

AJ_O'NEAL: Okay, because when you said GitHub created or someone, you said someone created view components for Rails and I was like, which, which type. 

CHARLES MAX_WOOD: Yeah. It's just a component that goes into the Rails views, just like your components go into your React apps. 

IAN_SCHWARTZ:But, you know, I would say really, yeah, the React model is more important than the API and if you can really learn the model and grow out the model, you know, Swift UI is basically React for iPhone development is my understanding. You know, other things, I mean, there's a lot that's been borrowed from, it's not React for me, I mean, there's a lot that's been borrowed from React. When we talk about framework fatigue, I don't think that there's been anything that's really, you know, there's sort of these three models of the Angular model, the Vue model and the React model, and they're all different ways of thinking, but there's been nothing for me that's come along that's really presented a newer way of thinking. And I think it's a very powerful one. 

CHARLES MAX_WOOD: So. Well, and to a certain extent, they've all borrowed that reactive model. It's just It's just the implementation and the different things that they care about that changed the flavor of it some and make it a better fit for some apps or some developers than others. But yeah, there's a lot to be said for React. We were kind of getting toward the end of our time and I, I'm enjoying this conversation. I want to cut it off, but I guess the question that I have is we typically don't dive into the frameworks like this. I mean, we even have a React podcast where people go listen, but if there's a takeaway for people that have either been doing React for a while that you think they ought to go and really understand deeply. And then I also want to take away for people who are just getting into programming or just getting into React, what's kind of the one thing that they need to go into and say, okay, if I get this, everything else will kind of fall into place. 

IAN_SCHWARTZ:Okay, those are two different questions. Hold on, let me address the first one. They are. So if you've been doing React for a while, you know, you may, first of all, the people listening to this podcast are may or may not be agreeing with me because, you know, as React developers, we all have opinions. Um, I think the best thing anybody can do if they're struggling with React. If you have the time and the ability is to challenge yourself to build either build and maintain an app or as much of a part of your app as you can without relying on external dependencies, we don't, we don't need to use libraries for most things. When I heard on the podcast, AJ, that you were learning React, my first thought was that you would do well with it, because the truth is that most of the time, the question of how do I do this, if you already know how to build web apps without React, you can probably figure it out using the small API that React actually has. So that would be my main thing is just, you know, as much as possible, try to write vanilla React components, and honestly, try not to use hooks. If you can avoid using, you know, I see calls to use memo and use callback that don't need to be done. Dan Abramoff, somebody put it in the chat here, the overreacted article before you memo, you know, the truth is that you, you almost never, you'll know if you need those because your app is going slow, but you don't know. 

AJ_O'NEAL: But to clarify, you're saying don't use hook libraries, not don't use react hooks. 

IAN_SCHWARTZ:No, no, I would say as much as possible, try to write code. Like you're going to need to use them. Right. But a lot of times, you know, it's easy to overcomplicate things when you want, when you, when you think you're using fancy features of the framework in the library. One of my, one of the things I'm always putting in code review feedback, right, is that these two, you have two pieces of state where one will do, you have a use effect where none is needed, right? You have a call, a use callback on something that probably isn't expensive enough to warrant it. You don't, you do need hooks, but it's nice trying not to use them, trying to think of ways to express the logic of your code where you don't have to write call after call to, to react hooks, to react, build and hooks. 

AJ_O'NEAL: So still using components in the style of react hooks, but not using as much of the use state and use effect. 

IAN_SCHWARTZ:No, no, if you need a hook, you'll use it. 

AJ_O'NEAL: Look, I mean, I'm trying, I'm trying to distill cause my understanding is the opposite of hooks is classes and the mounting stuff. No, I think you're saying a different language. 

IAN_SCHWARTZ:Yeah. Minimize. I guess. You know, in any functional language or functional framework, right? The, the side effects of the state are always kind of, if you learn LM or hassle or any other functional thing, your side effects in your state kind of live at the edges of your program. And they're not done all over the place. It's not that you shouldn't use them in the app. You should, you need them in the app, but you should try to use them with a light hand. They are the amount of state that you think you need and the amount of side effects that you think you need, maybe less than you think you need. If that makes any sense. So before I, before I reach for state on something, I always think, is this something that I can derive as a state that can be derived from, you know, state that already exists, right? Do I need to put a hook in here where I can just put a ternary statement? Right. And a lot of times hooks can be replaced by ternary statements or. 

AJ_O'NEAL: Can you give me an example of that? Cause I'm not, are we saying inside of the JSX, the HTML part? No, just in your react. 

IAN_SCHWARTZ:Okay. So like there'll be a prop of, okay. So let's, let's stick to our modal example, right? Maybe you're, you have.

AJ_O'NEAL: No, I mean, you're going to have state, right? 

IAN; But I just try to minimize the surface of the state I have, minimize the places where it's being called. So you may already have a P, uh, you're going to use a react to hold that state. But are you going to, if a prop is being passed down, is that okay. I've seen components where they'll say like, you're going to have a use state that says it's a Boolean, right? So you const foo use foo equals use state. Okay. And the argument of use state takes a default prop and maybe they'll use it, you'll have a string that's being passed down. And if the string is foo, then foo is true, right? And you'll see developers put in a piece of state with state setters that, you know, toggle that, but really you just had to look at what the string, is the string an empty string or is the, oh, that's a terrible example. 

AJ_O'NEAL: I feel like maybe...It's okay to fumble it a little bit. I, we just, it's totally cool. I think that the people that are listening will, will catch the idea. 

IAN_SCHWARTZ:Yeah. You know, in general, the props that you have, like my first thing when I'm designing a component or the behavior and the thing, right, is you have props that are coming into a component. You have JSX that's being returned. Ideally everything that's happening in between should be like we used to write pure functional components all the time, because we didn't have hooks. And you would have to interpret from the props that were being passing down, is this a thing or is it not a thing? And while that's still, that's done by most React developers, it's very easy to accidentally realize, oh, I already not realize I have a piece of state that's already covering this, or this is something. You're in your light mode or dark mode theme, right? And you have a presentational component. This is a really extreme example. You have like a button, right? And you could write a use state at the top that also stores the state of is this in light mode or dark mode? And i've seen you know, i've seen code and i've written code myself many times where i've accidentally not realized that that piece of state was already covered somewhere and was being passed down through props and could just be derived from the the situation. It's something that's easier to spot in code review than it is to spot on a podcast. Now the question for new developers, I think is a little simpler in that honestly, the best thing I think you could do as a new dev is to practice writing code without React, teach it to new devs early on. It is absolutely the right thing to learn from a career development standpoint. There are a lot of great jobs in React and they pay very well, which is a really great reason to learn it. But you know, most of what you need to know exists in the browser already the more you get used to writing web apps that don't have React in them before you start writing it, the more plain the use case of React and the benefits of it will seem, if that makes sense. And the less you'll need libraries, the less you'll need external tooling. 

AJ_O'NEAL: So I think we kind of covered this, but I'd like to explicitly go over, you're an opinionated person. You've mentioned a lot of things that you feel strongly about. Do you have something you could distill that are say your top five tips or your top five gotchas that you see in code reviews or something like that? 

IAN_SCHWARTZ:Sure. Tip number one. Okay. So everybody knows, everybody who programs knows the concept of like high level programming languages and low level programming languages. And for front end developers, we don't write assembly code, right? Our low level is basically HTML and CSS. And React is not that. If you're writing long components that call a lot of, you know, you see div all over the place and span all over the place in long chunks of JSX, you're probably missing an opportunity to break things up and encapsulate them more. So that's number one. Number two, I would say, is to leverage the language and learn as much of it as possible. React allows you to create components and hooks where the API is easy to understand, right? That's the real benefit is that. These things are easy to consume. And the more of a vocabulary you have for expressing, expressing within the language what you want to do, the easier that becomes to do, the easier it becomes to encapsulate. Number three. I guess for number three, I would say, write. Honestly, play, don't use dependencies if you can avoid them. I think that they complicate a lot. And you can interact with cookies without finding the dependency to let you interact with cookies, right? You can interact with you can make fetch calls without without using a dependency for that. And you may find use cases where you need those things and you can always bring them in. But it's always useful to try and do it yourself first if you can. 

AJ_O'NEAL: How many so three fetch I'm on board with you with because that one already is an abstraction over the old a XHR cookies. Is there a new API for dealing with cookies? Because the old one was you have to read the spec and split and join and do a lot of testing regulation. 

IAN_SCHWARTZ:The thing is that for me, the best API is the one. I like writing APIs for myself to use. For me, it takes as much, what you're describing is right, but it takes as much effort to write those functions as it does to learn a library that uses those, that provides the distractions over those. 

AJ_O'NEAL: I agree with that to a large extent. 

IAN_SCHWARTZ:And if you've ever, dependencies are needed, but I would rather, I don't know, I'd rather not use code that I'm going to have to update. You know, you read dependencies update, they change, especially in JavaScript, things change fast. The less I can have to mess with my code later on, the better. So I don't know, I'd rather fix a bug in my handling of cookies than have to worry about there's security update that, you know, major, major breaking change with the library I'm using. And I'm using it all over the app. So 

AJ_O'NEAL: got it.

IAN_SCHWARTZ:And on that note too, I guess number four, I would say I'm a really big fan of encapsulating dependencies. If I have to use a date handler library, like moment JS, for example, I would really try to have a single module that I call those functions in as many places possible, as many places possible. So I don't have to, you know, when, when moment updates go back and has breaking changes, go back and do it in 10,000 different places, it should really be in one section of the code base. And then for number five, I would just say just write. I think learning other programming languages, when you get to a point at JavaScript where you're comfortable with it, every time I learn another or play with another language, I always bring something back to JavaScript that makes me stronger in it. And either increases my ability to use the language or my understanding of it, or even my understanding of just a really great example is if you play around with Lua and there's no classes in Lua and then all of a sudden you're like, well, I want to use a class, you build a class in Lua and then you need build classes. And or at least when you come back to JavaScript, you understand what they were there for and what benefits they gave you. 

AJ_O'NEAL: I feel like I'm channeling Amy and Amy is saying, I agree with you, some relevant experience that I had learning something else, but the words aren't coming through that clearly. 

IAN_SCHWARTZ:Yeah.

AJ_O'NEAL: No, yeah. 

IAN_SCHWARTZ:I mean, look, we're all, every program, like you said, every programming language, hamstrings are in different ways and gives you different tools to use knowing what tool to reach for and when to use them definitely is the mark of a good craftsman. And you can't get that unless you get your hands dirty doing a lot of things. So there's a meme going around now, you know, this whole idea of like, should programmers write, have side projects or not? And the truth is, you know, my only instinct, I have two kids, right, my only concern is, am I getting paid well for my job? And the stronger you are, the better you will be. That's why we're all here at the end of the day, unfortunately. So, uh, as much as I would rather we could just program for fun. So yeah, you know, 

AJ_O'NEAL: I'm not, I'm not familiar with this meme. So I feel like on Reddit, 

IAN_SCHWARTZ:I see people, oh, you know, they always ask me in interviews, you have side projects, you know, you don't have to have side projects, but it's, it's, I think we're paid to be learners and the more you're learning, the more you're, you're bringing back to your potential as an earner, which is for me is 

AJ_O'NEAL: well, I think that goes in with the principle of sharp and saw, you need to take time work on your ability to work. So sometimes the correct solution to a problem is to stop and then take a really tiny piece of the problem and write some test code or some experiential code around it so that you understand only that piece of the problem. And that's code that you put in a blog and then throw away. And then you go back to your problem. It's like, okay, now I understood what the problem was. Now I can solve it in the context of the application. I'm getting paid to build.

IAN_SCHWARTZ:Right. And then you put it in a hook and nobody ever has to write it again. 

AJ_O'NEAL: So wait, use hooks. Don't use hooks. Hooks are hooks. Components are Oh,

IAN_SCHWARTZ:look, I mean, sledgehammers are tools that you need to. But when you're doing a construction project, you want to use a sledgehammer at the time when you need one and not whenever you feel like it would be fun to use a sledgehammer. So 

AJ_O'NEAL: wrong. Always use the sledgehammer nail sledgehammer screw sledgehammer glass pane.

STEVE_EDWARDS: When I was doing construction, I always used to sledge hammer when I was putting together the walls because you could do it only one shot. You didn't need so many hits. 

CHARLES MAX_WOOD: So are we just chit chatting? Are we done or? 

IAN_SCHWARTZ:Yeah. Chit chatting. 

CHARLES MAX_WOOD: You didn't do picks or did I miss picks? 

AJ_O'NEAL: No, we haven't done picks yet. We were just kind of wrapped up with the top five tips and we can, we can move into tips or picks, I think. 

 

So, Hey folks, if you love this podcast and would like to support the show, or if you wish you could listen without the sponsorship messages, then you're in luck. We're setting up new premium podcast feeds where you can get all of the episodes released after Christmas 2020 without the ads. Signing up will help us pay for editing and production. And you can go sign up at devchat.tv slash premium. 

 

AJ_O'NEAL: I will actually go first this today. So I'm going to put in a whole block of React material that is stuff that has either been mentioned while we were talking right now or in the email exchange between Ian and I or I think those are the two sources that they're coming from. So just a bunch of stuff. It's like five different links. So check out the show notes for that if you want it. I'm also going to plug the hashtag RIIR, which is a new security hashtag that I absolutely love, which basically says, C is insecure, the whole world is broken because of C, rewrite it in Rust. That's what RIIR. And there's a lot of initiatives going on right now to rewrite things in Rust so that they are guaranteed to be secure and stable and work and not get viruses or have DDoS, well, not DDoS attacks, that's not really the thing, but things like heartbleed and whatnot. So I'm gonna pick that hashtag. And then other than that, just want to remind everybody, if you've got programming questions that you would like me to go through in one of my live streams or have a little mini course on, you can tweet me at underscore beyond code. And in the show notes, I've got links to the live streams as they go up on Facebook, YouTube, and that Twitter handle. And I am still gonna plug the Vim Essentials for those of you that would like to have Vim working nicely as an IDE without having to learn all the configuration details, just kind of get some basic stuff that's just opinionated enough to get you working, but not so opinionated that you're gonna hate something, Vim Essentials is a good place to go, webinstall.dev slash vim hyphen essentials. And then after that, should we go ahead and pick, how about Steve? Cutting edge, Jim? How about Steve? 

STEVE_EDWARDS: Oh, oh, well I'll go with my dad jokes of the week. Ian, I'm not sure if you're up on my ragingly popular new feature that I've added to the podcast. So I've had a few in the past where I've talked about my job history, you know, like the time when I got hired for my first job at the bank, because an old lady came in and asked for her balance and I pushed her over. But anyway, I actually quit another job to start a cloning business and that's because I loved being my own boss. And then, so the other day I was walking past a farm and a sign said duck eggs. And I thought, man, that's an unnecessary comment. The tenant hit me.

IAN_SCHWARTZ:I might steal that one from a bad joke repertoire. 

STEVE_EDWARDS: And then one last question, you know, for thought. If a cow doesn't produce milk, is it a milk dud or an utter failure? That's my question for the day. 

AJ_O'NEAL: Awesome. But that we'll move on over to Chuck. 

CHARLES MAX_WOOD: Yeah, I'll throw some picks in. So, uh, the first pick actually had it looked up and then I moved away from it. But, uh, I've got a couple of picks. The first one is a blog post by Jason Freed and I really dig it mostly because it's, it's just changes at base camp. So base camp used to be 37 signals. They're best known for building like productivity and collaboration software. David Heinemeyer Hansen is one of the partners. He's the guy that created Ruby on rails, but just a few things here that he threw out there was that, uh, he looked at just where things were going and, and basically he and David decided they needed to make some changes. Uh, the first one was, and this was one that I really loved because I think he, he put it so well, and it was just that they're going to have no more societal or political discussions on their company base camp account and just explains, Hey, look, you know, they're people that, you know, they just get really, really sensitive about all kinds of different things. And so they're gonna, they're basically enabling people to come work for base camp and then. If you want to go and be involved in societal or political stuff on your own, then that's certainly fine, right? But the, you know, they're just going to get down to the business of doing what they do, which is building Basecamp and building Hey.com. And I thought that was really interesting. Just along those same lines. Uh, the other one that was, uh, he said no more paternalistic benefits, but essentially they had like a fitness benefit, wellness allowance, a farmer's market share. They had a couple of other things. And instead of giving their employees those benefits that they may or may not be using, right? Like paying for their gym membership, they are just giving them the cash value, those benefits and then not telling them what they ought to be doing with their life. And so anyway, it was just some of this stuff was just really interesting. There are like six or seven things. I know that some people aren't going to like the take that he has on this. But for me, it really just kind of underscored and I think a lot more companies would benefit from this kind of thing where they sit down and they look at it and they go, okay, you know, what is helping us? What is hurting us? What is helping or hurting our relationships with our employees? What is wasting time? There's some of that in here, right? We're 360 reviews. They got rid of those cause it was a waste of time. And then just focusing on the stuff that matters for the business. And so that's putting together the management software and email software. So anyway, really, really liked that. 

AJ_O'NEAL: That's radical. I mean, two, that's...I love it. It's so non radical that it's radical. 

CHARLES MAX_WOOD: Well basically it was, hey, look, we're just gonna, we're gonna be who we are and we're gonna have people work here to be who they are. And it didn't say that they weren't gonna have, I think they actually called out that they do have diversity, equity and inclusion stuff going on in their company, but that's their people ops person's job. And so they'll do that, but they're not going to make the political or other stuff part of their culture, right? Their culture is we're gonna make great stuff. So. 

AJ_O'NEAL: Awesome. 

CHARLES MAX_WOOD: Right? So anyway, so that was one pick that I really, really, really enjoyed. And I've just, anyway, that just kind of hit me yesterday when that showed up. So I'm loving that. And then the other pick I have, and I think I might've picked this last week, but I just, I'm just getting more awesome out of it. So I'm gonna pick it again is monday.com. And monday.com is basically project management software. So it's competitor to Basecamp, go figure. But, and I think they're based in Israel, I think is what Dan said last week. But anyway, what's interesting about their stuff is just all the automation. And I've got a guy that's actually working on automating a lot of the processes around the podcast production, all the way from the guest schedules the episode. A lot of this is automated through Zapier right now, but the guest and then it just automatically sends out an email to them and says, Hey, can you put some, you know, some material in for us to prep on? And then it'll email the host and say, Hey, the, the guest has had a couple of days to put prep information in, you know, go put your questions in and then it'll just remind us, you know, a few days or a week before, right? But then it goes through the whole process. Okay. Now it's recorded. So the recording link goes in, then it notifies the editor and notifies the person writing the the show notes and then once those are done, then it notifies the person who can publish it to publish it. And once it's ready to be published, it gets put in and then once it's scheduled, then it's like, okay, well, you need to schedule the social media and you need to schedule this and you need to schedule that. And so the whole thing just gets cascaded and automated all the way through using their stuff. There are a few gaps that I've had to work around in it, but they're not major gaps. They are workable. The only other thing that I've run into that was weird about monday.com is that they have a JSON API and they expect you to put JSON into your fields in Zapier. So it doesn't have the integration, for example, with schedule once. And so if somebody schedules a meeting and schedule once, like one of these episodes, then Zapier still has to connect it to Monday. And so I've got to pull the data out of the schedule once appointment. And then I've got to turn around and put it into JSON so I can stick it into monday.com on Zapier. But that's not, it's still not terribly hard. It's just, yeah. It's just a little bit clunky compared to some of the other ones where you just, okay, pull the name of the guest out here and stick it in here. So anyway, but I'm really, I'm really loving it. I've also been doing kind of the CRM thing and enjoying that. So yeah, those are, those are pretty much my picks. 

AJ_O'NEAL: All right. And with that, we'll head on to the best of the bunch Ian. 

IAN_SCHWARTZ:Yeah. So, I guess I'll do two. My first pick will be a tech one, which is Preact CLI. I did use React. I was doing an app, a React-based app at home, which is a rare thing for me. And I tried Preact and the Preact CLI, and I say I really liked it. It's much lighter weight than React. The docs are as good or better than the official React docs. And just the defaults that they chose in setting up the CLI were very sensible for me. It was really easy for me to get get going very fast. So if you're thinking about starting up a React project, if you want to use React, certainly not using a Facebook product is not a bad thing either. So my other pick is not technical, which is, so I in January was diagnosed with obstructive sleep apnea. And I gotta say since learning about the condition and treating it and looking around at the people around me, it turns out there's a lot of people. Like something like one in five people have undiagnosed sleep apnea. It's not just for fat people, it's not just for old people, although I am creeping towards being both a little closer every day. 

AJ_O'NEAL: You don't look a day over 17, Ian. 

IAN_SCHWARTZ:But honestly, you know, I just, to everybody in the world out there, if you ever wake up and you're foggy in the morning, or you wake up not feeling well rested, even though you're getting a good night's sleep on the regular, you know, and if you have insurance and you can get a sleep study done, it's worth it because you might be suffocating in your sleep, you know 20, 30, 100 times an hour. So, which turns out you need oxygen to function and go about your day and be a good parent and all that other stuff. So that is my second pick is sleep apnea. If you are tired, please get checked out. 

CHARLES MAX_WOOD: Yeah, I was gonna say, so you wear a mask when you sleep, but that- 

IAN_SCHWARTZ:I just started in January. It has been an adjustment period for me. But I was not, yeah, I was waking up. I was actually waking up from it, which most people don't do. So for me, there has been no alternative but getting used to it. Because again, it turns out little kids with no sleep is not a really pleasant life experience. So yeah, I have been wearing it to sleep. And you know, truthfully, the side effects of not treating it, it's a fatal disease eventually. And looking around, I just see everybody I see who tells me that they have brain fog and they're tired. I'm like, go, go get checked out you know, they strap a thing to your chest and another thing in your nose and they'll tell you and you can see on the graph, some people 20, literally there's people out there a hundred times an hour. They stopped breathing in their sleep. So I'm very outspoken about it now. 

CHARLES MAX_WOOD: So my wife, my wife was diagnosed and she started sleeping with the thing on her face and it makes a little bit of noise, but I can sleep through anything. So that wasn't an issue, but she felt a ton better, ton better.

IAN_SCHWARTZ:And for most, for most spouses, the, the most sleep apnea people, not everybody, but most people snore pretty loud. So generally people say that the noise of the machine is less than the noise of the, uh, the log sawing. 

CHARLES MAX_WOOD: So I won't say that publicly. 

IAN_SCHWARTZ:Anyway, that's my second pick. So let's, uh, Thanks guys. 

AJ_O'NEAL: Well, I'll look into that a little bit because I've wondered sometimes I have bad snoring habits sometimes. But I've also found, I'm going to reference this since we're talking about it. There's a Jim quick video. I've mentioned on the show before 10 morning habits, and I'm putting a link to that because just changing some of my habits has been giving me much better sleep while establishing habits, establishing an actual routine and including just a few minutes, not 15, not 20, not half an hour. We're talking two to four minutes of exercise in the morning. As I feel like that's one of the biggest things in drinking more water that if 

IAN_SCHWARTZ:you know AJ I can tell you as somebody who as somebody who used to joke that I would get out of breath if I ran a bath but then has since trained myself up to half marathon distance four times like once you get in the habit of exercise it gets easier and it gets more fun so even that four minutes I would challenge yourself to make a little longer if you can because once you get to the point where you can do half an hour without like dying it becomes a lot more fun too. 

AJ_O'NEAL: I have a hard time believing that but I will see if I can get my two and a half minute run to to three minutes. 

IAN_SCHWARTZ:Check out Couch to 5K if you haven't. 

AJ_O'NEAL: What is it? 

IAN_SCHWARTZ:Couch to 5K? Couch to 5K, that's what I use. It starts you out the first day you run 90 seconds and walk 60 seconds off and on for like 15 minutes or something like that. But yeah, I ran three half marathons, four half marathons with my daughter in a stroller for the entire training process. So running, pick number three, recommend. 

AJ_O'NEAL: All right, cool. Oh man. I will check this out because I I hate running. I do it almost every morning or some other form of exercise that is less obnoxious to me. But I only do it for a few minutes and it's just to start my day and I definitely feel the benefit. But I have a hard time believing that I could ever enjoy running. 

CHARLES MAX_WOOD: You're not running enough then. So I have to chime in. If you if you really get serious about running. I've been using a system called Training Peaks and then I just bought a training program on there to get the coaching because I couldn't afford a coach every month. And I'm using it to train. I'm going to be running Utah Valley marathon in a couple of weeks. So that works too. But yeah, start small, do catch the 5k. And then kind of when you've worked up to that, then look at what's next. Cause initially I didn't really like running. And then once I was out running three, four, five, six miles, then it was like, wow, this feels really good. 

IAN_SCHWARTZ:The runway from no running to three miles is really, really big. The runway from three miles to, you know, 15 miles is much smaller.

CHARLES MAX_WOOD: Yep. 

AJ_O'NEAL: Oh, y'all making my head spin. I'm not going to even think about that. I'm just going to think about, could I get to three minutes from two and a half? 

IAN_SCHWARTZ:That's exactly what you have to do. And, you know, but use it, use a program because, you know, you're probably capable of more than you realize to when I did couch to five K I went through the first week of it in like three days because it was a little too, too gentle. 

CHARLES MAX_WOOD: Yep. 

AJ_O'NEAL: I can't imagine anything being too gentle for me. But with that, shall we wrap up the show? 

CHARLES MAX_WOOD: Yeah. 

AJ_O'NEAL: All right. Thanks everybody for listening in. You know, what would be really great is if you would hit us up on Twitter with your questions about stuff that you want to learn, and also feedback for us on things that we've done well and haven't done well. We really haven't been asking for that, and that's to our detriment, and we'd really like to invite you to reach out. We are at JSJabber, is that right? Did I get that right? Okay, I got it right, good. I didn't even know. But yeah, we're at JSJabber on Twitter. So please hit us up. What are the things you wanna learn about? What are who are some experts you'd like to have us have on the show? And what have been the shows that have been most impactful for you in your career? Thanks a lot and we will catch you next time. Adios. 

CHARLES MAX_WOOD: Alright. Yes. Thanks out everybody. Bandwidth for this segment is provided by Cashfly the world's fastest CDN. Deliver your content fast with Cashfly visit c a c h e f l y.com to learn more.