When to Refactor

[00:00:00]
>> So another question that comes up a lot when it comes to production-grade apps, because we're talking about enterprise scale here is when it's best to actually refactor your apps. And so this is sort of like the cliche statement that's made a lot in programming, which is that premature optimization is the root of all evil, or at least most of it, when it comes to programming.

[00:00:22]
And the same can actually be applied when it comes to refactoring components. And so the principle I wanna introduce here is to follow what I like to call data driven refactoring. A lot of times, as developers, when we start building something, it's easy to try to think immediately of how it can apply everywhere and all of the various use cases it can apply to.

[00:00:43]
But most of the time, what I found it is more effective is to go ahead and start by building the component as you would normally and just build out the feature, make it very specific, right? So in the instance of our to-do list item that we talked about earlier, to do this item, just build it.

[00:00:59]
Don't sit there and think like, well, it's kind of a list item, which kind of could be used in shopping cart and kinda could be used on the dashboard. This is I think where we get stuck a lot. And so instead, these are some signs we can use to kind of indicate when we need refactoring, right, once we build the specific instances, right?

[00:01:16]
And the first one is that when your components are hard to understand. And so what does that mean exactly? For those who have working on really big apps, most of us have that experience where you get that ticket and someone's like, well, this component needs fixing. And everyone's just like, give that to Dana.

[00:01:34]
Dana knows what she's doing with that. And so in that scenario, this component has become so complex and only one person understands it, that at that point, no one wants to touch it. And then most people probably have experienced that level of complexity in the component. And so one of the reasons that components are supposed to be helpful is because anyone can get in there and help enhance it.

[00:01:56]
But when it becomes so difficult that people can't even get in there or don't want to basically work with it, this is probably one of the biggest signs that we need to take the time to refactor it. So that Dana isn't the only one who understands how that component works.

[00:02:10]
And so we can have better shared knowledge on those sort of things. The other thing is that when you're getting the sense that a component really should have its own state. So this is an example of this might be when you're working on a component, and you find that you're just configuring a lot of things really specifically for this one section of HTML.

[00:02:30]
And that you're just finding that it's kind of odd that the parent's controlling it. And so once you start to get the sense that a component should encapsulate its own state, this is another example of data driven refactoring. Because at this point, again, you've seen that, you have the evidence to show that the code would support having its own file and being on its own.

[00:02:48]
And so the third point, it's similar to the first one, where if you have a hard time figuring out what exactly that component is responsible for, then absolutely, it's time to break it apart. Because one of the things that also makes single file components really great in view is the idea that when you delete something, you know exactly what's getting impacted.

[00:03:06]
But if you have a component that's so complicated that you can't safely refactor or delete code, this is time that we're spending into. Because we wanna make it easy for people to not only debug and refactor, but even enhance it with new things going forward. And so what are some other ways of finding these new reusable components?

[00:03:25]
The most obvious one is when you're using a v-for loop with any sort of HTML that's starting to get pretty complicated. So if you're just looping through an LI that has just some text in it, certainly there would be overkill to a refactor to its own component. On the other hand, if you have a v-for loop where the LI contains a lot of different markup and not only that the markup has different state that changes or has different things that reacts to different data points, then this is absolutely a great time to just abstract that out into its own component.

[00:03:57]
And so large components is another one too. If your components are 100s and even 1,000s of line long, probably something should be refactored at that point and reconsidered, and so whether it's similar visual designs as well. So if you're lucky enough to have designers who are providing a design system up front, these are great ways to maybe abstract out certain base layer components that have certain styles that are very consistent over time, right?

[00:04:23]
So a base button is the most traditional example of this. So that the styles are consistent, and then people can extend it from there. Otherwise, we talked about some of these other ones. But generally speaking, if they're repeating, if there are multiple mixed responsibilities, and if anything starts to get so complex that no one understands what's happening, that is the time to invest in refactoring.

[00:04:47]
So we have a question regarding whether or not, so I recommend using the container presentation model, where you have sort of what they call dumb components versus components that are stateful. And so in general, we'll get over into that a little bit in routing. But as a whole, the key thing when it comes to determining the architecture of your components, I think, really boils down to that data driven, just call that architecture.

[00:05:12]
Because what I've seen is when people try to follow too close to the presentational versus stateful components, oftentimes they find themselves sort of wound in. They end up getting stuff tied up in a knot regarding, but kinda this, and so using data driven refactoring, I say, in general, if you know instantly, for example, you're building a page layout.

[00:05:32]
And let's say your designer has provided you a three column layout, or a two-third, one-third, those are things that I would say instantly, yeah, so I'll cover this a little bit in routing, but you can create a layout. Basically, I would recommend creating a layout folder where those components are specifically for layouts.

[00:05:47]
And so those are instant wins. You don't even have to think about it. But otherwise, when it comes to presentational layers, I would say let your app dictate that rather than trying to predict what will happen in the future. That's the easiest way to, so know that the presentation model is there for you.

[00:06:04]
But as a whole, I would say just focus on building things and it'll become obvious over time.