Learning React - Part 2 (Three lessons from the perpetual path)
The. If you listen to the last episode of the show, you know that we change things up a little bit. We talked about. Well, I talked about my experience my personal experience learning react to the past couple of years. This show was still flavored mostly like the developer t episodes 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 gonna talk a little bit more specifically about lessons that I've learned in fact, I have three specific lessons, they're mature with you, and these are not going to be groundbreaking. Unfortunately, I don't have click bait titles for this particular episode because these are things that really me didn't need react to teach you in the first place, but these lessons these 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 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 into a one of the reasons we have differences in tooling. Of course, tools are also made for different jobs, but we're not gonna dive too deep into that into days episode. My name is Jonathan trailing. You're listening to developer. Not my goal on the show is driven developers connect to their career purpose and do better work. So they can have a positive influence on the people around them and into days 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. If you're not familiar with reacts encourage you to go and Google react j s 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 Java. Gripped. It certainly is not solely responsible for that. And it has benefited from that that effort, but China didn't to make broad generalized 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 I o s and even on native desktop. Oh S's. So it's a powerful thing. And despite you know, how you feel about react, you know. That's not really the discussion that we're having on this episode instead wanna share some of the lessons that I've learned along the way. So let's start with the first lesson. This is again just wanna over stress. 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. Avoid 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 in a never try to build anything with any four site 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 obstruction. 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 know, you're using you add methods that you're not necessarily even using get. These are always that you may be trying to predict what your code will need in the future. But the one that we mentioned I abstraction this is something that we think is responsible design, and this is a difficult thing to get past. Because a lot of the reflectors 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 obstructing it. And here's the reality. This is very easy to do especially in a two-leg react. In fact, you'll see a lot of people that recommend making a lot of classes, and I'm recommending that to how can you simultaneously recommend making a lot of classes and also not obstructing too early. One of the ways that I've learned to do this is to rely on local components. And 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 wants you to create in the same file the area in whatever your current component file is at the top of that after all of your info, it's create a private component. This is a component. That doesn't get exported. It's one that. No other component. Are using his just for your local your local scope right 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 and win. They do. They're very easy to doubt. Let me say that again, very often these local components don't grow into a kind of a reusable abstraction, right? Technically, we are kind of abstracting an idea out from, you know, render Beth for example into its own component. But that component is for all intents and purposes kinda. Of virtually similar to a variable. Right. Maybe it's virtually similar to a light class or even a module or a display component. There's a lot of names the news for this. And unfortunately, we don't have this semantic differences in the language itself. A component is kind of a component. You do have things like presentational components or pure components. We don't want to get into the nuance differences here. But what we're talking about doing is instead of trying to enlist 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 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 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 that same low 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 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 Jess tag for that component. That's gonna 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 Implementation's 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 and one file with a slightly different behavior slightly different default style, for example. And then you can have another local component name the same exact thing that behaves differently. Now, 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 a semantically similar code into files, and 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 caused me enough struggle because of those semantics. Okay. So that's lesson. Number one. We're gonna take a quick sponsor raking come back with the other two lessons. Today's episode of very excited to nounce. Today's episode is sponsored by manifold manifold allows you to connect to more services and all new discovery experience and refresh dashboard and integrations these all make manifold the easiest way to build cloud native applications a what does manifold do. Well, it brings you the developer closer to the tools that you use manful 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 to 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 can next those integrations manifold is going to give you as a developer t listener ten dollars to go towards services that you want to use on manifold to get that ten dollars head over to manifold duck. Oh, that's manifold dot CO slash devotee. Manful dot co slash DAV. T A. Thanks so much to manifold for sponsoring today's episode of developer t manifield dot co sized T. Okay. So let's get onto 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 reacts is intended to be used in 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 calls are not obvious all the time. So it's very important to realize that in your interaction with that tools going to be different from everyone else's. So that's why I wanna share these lessons with you. Because not everybody's going to have the same experiences. And that's okay. All right. 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 it easier to maintain. And that includes when you compose small things when you have small components, I'm talking less than twenty line. 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. Ace 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 their 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 obstructed, by the way, I've had files where I have five or six private components defined inside of that file that composed very well together. Right. So it's not about having, you know, small files per se, small files become easy to read, and I would still shoot for a relatively small file size. Let's say. For example, one hundred mines or less is probably a good here. Stick to us. 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 onto the third and final lesson. For today's episode. Everyone else is making things up the reactive. Ella pers- have not been doing this for very long. It's impossible because reactors 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 implant 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 in. We're going to learn new better ways of doing things. Even when we think that we have the, you know, 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 here that you have even outside of programming there 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 you know, 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 and 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 were all beginners at once we've learned just enough. There's still going to be more to learn and things are always changing. So encourage you to change your perspective little bit on what it means to grow as developer. You're not growing from small to big you're not climbing ladder. The senior developers who believed 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 cyclical there is no specific destination in mind, and we're gonna continue on that journey for entire careers. They can so much for listening to today's episode of developer t 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 developer and as human thank you again to 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, they didn't even know exist. Go and check it out manifold dot co slash devotee. You're gonna get ten dollars worth of credit to go towards any service thinking into manifold thinks mature listening. If you enjoyed today's episode I encourage you to do two things first subscribing, whatever podcasting apps. 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 ITN's. I know you've heard this on pretty much every pie Cassie ever listen to and you've probably heard it on this podcast multiple times. But the truth is reviews are kind of the lifeblood of a pie cast. They help other developers. Like, you find the show in the more people who listen to this the more value. We can get out of it. The more people that can talk about these 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 this discussions is take a moment and leave a review on tunes. Thank you so much listening to today's episode and until next time enjoy your team.