If you listen to the last episode of the show, you know that we changed things up a little bit. We talked about, well, I talked about my experience, my personal experience, learning react over the past couple of years. The show was still flavored mostly like the Developer Teaepisodes that you're used to. We talked about learning and we didn't get into too many specifics about react. And today's episode is going to be fairly similar. We're going to talk a little bit more specifically about lessons that I've learned. In fact, I have three specific lessons that I'm going to share with you. And these are not going to be groundbreaking. Unfortunately, I don't have clickbait titles for this particular episode because these are things that really, you didn't need react to teach you in the first place. And these lessons, these are things that you can carry with you regardless of what tooling you decide to use because as we discussed in the previous episode, you're learning an ideology, you're learning kind of principles, patterns, ways of thinking, and then using a tool to accentuate those learnings. Sometimes some tools are going to help you learn a particular concept better than other tools. This is why we have differences in one of the reasons we have differences in tooling. Of course, tools are also made for different jobs, but we're not going to dive too deep into that in today's episode. My name is Jonathan Cutrell, and you're listening to Developer Tea. My goal on the show is to help driven developers connect to their career purpose and do better work so they can have a positive influence on the people around them. And in today's episode, I'm sharing three specific lessons with you that I've had in my past couple of years of learning, specifically with relation to React. Now, if you're not familiar with React, encourage you to go and Google, React.js. React is always growing, it's always changing, and there's a vibrant, very large community. It's really responsible, arguably, responsible for a lot of the kind of renewed excitement and development around JavaScript, it certainly is not solely responsible for that. And it has benefited from that effort, but I try not to make broad generalize statements on the show, so I say this tentatively, and with some reservation, it's not really an understatement to say that React has significantly changed web development, and perhaps even native application development on both Android and iOS, and even on native desktop OSes. So it's a powerful thing, and despite how you feel about React, that's not really the discussion that we're having on this episode. Instead, I want to share some of the lessons that I've learned along the way. So let's start with the first lesson, and this is, again, I just want to overstress this, you don't have to learn React to be able to use these lessons. These are kind of universal lessons, and I hesitate to even talk about React, but it gives us a good kind of common ground to discuss these lessons with. Build the thing you need today, that's lesson number one. Build the thing you need today. There are a lot of ways of phrasing this. You've probably heard something like future features, right? And future features or fortune telling code, fortune telling design. These are things that you try to build before you really have an expressed need for those things. Of course, I don't want to go overboard and say, you know, never try to build anything with any foresight at all, but perhaps your foresight is much more extended than you think it is. So I want to be clear, there are multiple types of fortune telling design, fortune telling code. One of the types that doesn't feel like you're trying to build out into the future is abstraction. The other type that does obviously feel like you're building into the future is feature development, right? If you try to build in a bunch of other features or maybe you are adapting certain data types or you're trying to build a lot of flexibility into a component or you're using, you add methods that you're not necessarily even using yet. These are always that you may be trying to predict what your code will need in the future. But the one that we mentioned first, abstraction, this is something that we think is responsible design. And this is a difficult thing to get passed because a lot of the refactors that we do in the future, they rely on some kind of abstraction. And so much of the work that we do, in fact, is just taking a concept and abstracting it. And here's the reality. This is very easy to do, especially in a tool like React. In fact, you'll see a lot of people that recommend making a lot of classes. And I'm recommending that too. How can you simultaneously recommend making a lot of classes and also not abstracting too early? One of the ways that I've learned to do this is to rely on local components. Now, what does this mean? It means that when you normally would be abstracting out into a file and creating a component that might be used by multiple other components. Instead, I want you to create in the same file that you're in, whatever your current component file is at the top of that, after all of your in-ports, create a private component. This is a component that doesn't get exported. It's one that no other components are using is just for your local scope. Now you can export the component that is kind of the primary component in that file, but don't export that private component. This is a lesson that I've learned. Even more recently, these private components, very often, they solve a whole host of problems, but very often, they don't grow into an abstraction. When they do, they're very easy to adapt. Let me say that again. Very often, these local components don't grow into a reusable abstraction. Technically, we are abstracting an idea out from a render method, for example, into its own component, but that component is, for all intents and purposes, virtually similar to a variable. Maybe it's virtually similar to a light class or even a module or a display component. There's a lot of names that you can use for this. Unfortunately, we don't have the semantic differences in the language itself. The component is kind of a component. You do have things like presentational components or pure components. We don't want to get into the nuanced differences here. What we're talking about doing is instead of trying to, and let's zoom out of this react context that we're talking about, instead of trying to create a reusable polymorphic thing, this thing that can service in multiple areas into the future, there's where a fortune-telling coding comes from, instead, let's make this thing available to us now, and make it available to us only in this context. This is much less code, and it's easily adaptable. This is really the key factor here. When you have the same local component and you find yourself copying and pasting that local component over and over and over, especially if that local component has some behavior that you end up copying and pasting over and over, some methods inside of it, some kind of state that it holds or something that it does consistently with props or whatever it is that you continuously are copying that same local component into multiple other components, then you may have a reason to abstract that component, to bring it out of that local scope and to put it into its own exported, you know, official component file, whatever it is that you want to call that, so that now it's all contained in one place. Very often what ends up happening is that in order to, and this is kind of the beauty of using local components, in order to go through that process of abstracting that out, most of what you're going to do is transforming that local component definition into an import. Most of the time when you actually use that component in your render method, right, when you're actually using it, when you're actually doing the, you know, the JS tag for that component, that's going to stay the same because you're importing essentially the same thing that you had defined locally. Now what you'll find is that you might have differences between your implementations and Mrs. Where you have to do a little bit of extra work. This is one of the benefits of a local component. You can have a local component that is named one thing in one file with a slightly different behavior, slightly different default style, for example. And then you can have another local component named the same exact thing that behaves differently. And this may feel initially like kind of an anti pattern. And in some ways, that's a good argument. It's a good argument for abstracting. If you have, you know, semantically similar code in two files, then perhaps those things should become one thing. But in my personal experience, and of course, I can't speak for everyone's experience, but in my personal experience, I haven't found a time where those locally defined components cause me enough struggle because of those semantics. Okay, so that's lesson number one. We're going to take a quick sponsor break and come back with the other two lessons. Today's episode I'm very excited to announce that today's episode is sponsored by Manifold. Manifold allows you to connect to more services and all new discovery experience and a refresh dashboard and integrations. These all make Manifold the easiest way to build cloud native applications. What does Manifold do? Well, it brings you the developer closer to the tools that you use. Manifold also allows you to find new tools that maybe you don't realize even exist yet. You can organize all of your services into projects. And if you have custom services that you want to use through Manifold, you can bring those too. You can create a custom configuration and then you can create teams and invite collaborators to those projects. And once you do all that, you connect those integrations. Manifold is going to give you as a developer to listen or $10 to go towards services that you want to use on Manifold. To get that $10, head over to Manifold.co. That's Manifold.co slash devt. Manifold.co slash devt.a. Thanks so much to Manifold for sponsoring today's episode of Developer Tea. Manifold.co slash devt. Okay, so let's get on to these other two lessons that I've learned in the past couple of years as I've been picking up this new skill learning react and understanding some of the ways that react is intended to be used and ways that people are finding that it can be used. And all of these psychological principles that we talk about on the show that comes into play as you negotiate with new tooling. Your tools are not obvious all the time. So it's very important to realize that your interaction with that tool is going to be different from everyone else's. So that's why I want to share these lessons with you because not everybody's going to have the same experiences and that's okay. Alright, so the second lesson. Small has never looked better. You've heard it on the show before and I can't stress it enough. Small things are easier to build. Not only are small things easier to build, they're easier to maintain. And that includes when you compose small things. When you have small components, I'm talking less than 20 lines sometimes. Sometimes the components are less than five lines. That sounds crazy doesn't it? But those components become the most straightforward, easiest to maintain pieces of code in your code base. The whole concept of having components is to compose them. A component on its own is usually not very valuable, but when you can compose one component with another, it becomes much more valuable. The interchange between those components, whether they are siblings or totally unrelated to each other or if they're ancestors, if they are in some tree together, these components being composed together, this can be extremely powerful and all kinds of combinations can exist. Those are incredibly powerful as well. So don't confuse small with abstracted by the way. I've had files where I have five or six private components defined inside of that file that compose very well together. So it's not about having small files per say. Small files become easy to read and I would still shoot for a relatively small file size. Let's say for example, a hundred lines or less is probably a good heuristic to use, but it doesn't necessarily mean that every single component that you create has to be broken out into another file. So small doesn't mean abstract. Okay, let's move on to the third and final lesson for today's episode. Everyone else is making things up. The react developers have not been doing this for very long. It's impossible because react has only been around for a short period of time. And so no matter who you encounter, who's using react, they haven't been doing it for very long. And therefore we're all still learning. And this is true of older tech as well. There's not a point in the future where we're all going to circle around react and say we've arrived. Everyone is making things up. And in this process, you will have a lot of bad ideas. You're going to do something poorly with react. You're going to make a bad decision about naming a component or even about the entire design of a component or a list of components or an entire application. And others are going to do the same. Entire open source projects may fall apart and you may even abandon react or whatever other tool at some point in the future altogether. This is not outside of the realm of possibility and it's very important that we remember this. We remember to stay open to the fact that we're all learning constantly. That we're not going to have the perfect answer and we're going to learn new better ways of doing things. Even when we think that we have the best design patterns nailed down, there's something new around the corner. The truth is your heroes, the people who are writing react that you look up to and any other hero that you have, even outside of programming, there's something that they do in a very weird way. There's probably something that you do better than them. There's probably something that you know about more than them that you would never expect. I don't say this to artificially inflate your ego or to try to make you feel better, but instead I say it because the reality of our situation is that bravery is in short supply. We have a fear when we learn something new that we're going to screw something up. We have a fear when we're the new developer on a team or when we're approaching something that we don't understand. Something in our heads tells us that anybody else who has worked with this is significantly smarter than me. Our brains can trick us into thinking that even asking questions or questioning the way something is done that that's going to bring on ridicule. The unfortunate truth is that sometimes our brains are right. Sometimes it does bring on ridicule, but it's all that more important that we continue to support each other as we learn new things, as we try new things, as we stumble through finding the best way to wrangle computers together. And not only computers, but as we stumble through building businesses together, understanding each other's emotions and psychology, trying to work better together as humans. These are things that we're all beginners at. Once we've learned just enough, there's still going to be more to learn, and things are always changing. So I encourage you to change your perspective a little bit on what it means to grow as a developer. You're not growing from small to big, you're not climbing a ladder. The senior developers who believe that they've gotten to the top of that ladder very often find themselves staring at a new ladder, or perhaps on a lower rung, that ladder itself growing above them. We like to think that there is some destination that we're all heading to. And it's easy to believe that a lot of the people that we look up to, they've arrived at that destination. But the truth is very different. The journey is so cool. There is no specific destination in mind, and we're going to continue on that journey for our entire careers. Thank you so much for listening to today's episode of Developer Tea. I encourage you to always be learning. This is one of the best ways to remind yourself that you are on that perpetual journey as a developer and as a human. I think we get into manifold for sponsoring today's episode. You can get your services kind of orchestrated together in a much more sane way. And you can find new services that you didn't even know exist. Go and check it out. NFold.co slash devt, you're going to get $10 worth of credit to go towards any service. Thank you again to manifold. Thanks so much for listening. If you enjoyed today's episode, I encourage you to do two things. First, subscribe and whatever podcasting app you're currently listening to this episode in. This is the best way to make sure you don't miss out on future episodes just like this one. The second thing is leave a review in iTunes. I know you've heard this on pretty much every podcast that you've ever listened to. And you've probably heard it on this podcast multiple times. But the truth is, reviews are kind of the lifeblood of a podcast. They help other developers like you find the show. And the more people who listen to this, the more value we can get out of it. The more people that can talk about these discussions that we have about treating each other better and being on a perpetual learning journey. The more people who can have those discussions, the more likely we are to grow together. So one of the best ways to help more people have those discussions is to take a moment and leave a review on iTunes. Thank you so much for listening to today's episode. And until next time, enjoy your tea.