Composables vs Utilities vs Logic

[00:00:02]
>> Speaker 1: How do you know you want to use a composable versus a util method?
>> Ben Hong: I love it. You read my mind. Let's move on to this. Composable versus Utilities. So that's exactly it. So, I think most people, they see this and they're like, cool, I'm just going to cram everything in Composables because it's kind of easy.

[00:00:25]
It works. I mean, let's be honest, it does work. Nothing wrong with that. However, in the discussion of in case, for those who are newer to the industry, what's actually really common in a lot of enterprise code bases too is this either utils. Wait, whoops, wrong folder. There's usually some sort of utils folder or utilities.

[00:00:45]
And so when differentiating between the two, I would say the key thing here is that Composables is, if you think about it, composables is a term originated from the fact that it's the View Composition API, meaning that it's using VUE things. And so oftentimes this means it's regarding some sort of stateful ui, whether it's using reactive data with like refs reactives or lifecycle methods.

[00:01:08]
On the other hand, utilities are really like when you think of lodash, when you think of Moment js. These are things that have like generic purpose and really in some ways are kind of more that pure function mentality. They're there for one specific thing, whether it's like two, uppercase, whatever, you choose your pick.

[00:01:24]
Those are usually what I consider more of the utilities is that they really have nothing to do with view. And so in this regard, you might say, well, Forma's task status label doesn't technically have any view things on it. But what we could say with confidence, though, is that this particular bit of like, let's call it a search algorithm is specific to tasks, right?

[00:01:49]
And so, unless we could prove that like, this particular status label is going to be genericized maybe to a bunch of other status labels. Again, let's just assume for now that this particular logic is only associated with tasks. So one could then make the case that it really probably does belong more so in the composables.

[00:02:08]
And I'll give you a hint. Part of the reason I say this too is that we mentioned that status is a string here. But one of the things that's like a hint to what's coming is that status is not necessarily just a plain value. So we'll talk more about that later.

[00:02:22]
This has to do with composable Design here, we can see here in this regard, we have a task list that's being dropped down. There's a lot of filtering happening. So now there's even the question of business logic, right? Because Composables doesn't necessarily equate to business logic, nor does it necessarily equate to utilities.

[00:02:42]
And so, David gave a great talk yesterday and was talking about this. And I do think when you're thinking about these three kind of categories, what a lot of times people do, especially with Composables, is they kind of stuff everything together because it feels like the easiest thing to do, right?

[00:02:57]
But the problem is you end up with this kind of tight coupling when it comes to testing. Because imagine if you want to test your business logic, but it's tied to the fact that you have to navigate to a page and then click a button and then do things that doesn't really make sense.

[00:03:09]
Your business logic really should have nothing to do with what's on the webpage, right? There should be multiple ways to execute payment functions, authentication, whatever unique value proposition your business offers. That to me is what David mentioned is sort of like your pure functions. You should be able to test those in a vacuum and they should work every time, regardless of what the UI is, right?

[00:03:29]
Utilities. I would say that what separates logic from utilities is that utilities aren't related to your business like core business, right? You could replace them with kind of any generic thing, but like logic, because that's what some people do. They do have a separate folder for logic, and then that is their pure functions that resolve, basically targeted to their business stuff.

[00:03:47]
One of the struggles with testing is that you try to test everything, but as we know as software developers, sometimes you just don't have the resources to do so. You might only, and especially if your tests take a really long time, you want to test your core functionality.

[00:04:00]
Separating out your business logic into like a specific. Essentially a specific folder makes it easy to go, you know what? We're going to trust that the utilities are working and the composables are fine. But we must test the business logic every time. Because my mentor would say there are only two tests any company ever needs.

[00:04:17]
Can the user log in and can they pay us? Everything else is optional, right? And so it's a bit tongue in cheek, but at the end of the day, we are building things that provide value to users and we want to make sure there's a business model behind that.

[00:04:30]
And so that's kind of like the way I would see the Three paradigms and again, adapt it to whatever you and the team see fit. Whatever works best for your mental model. But again, your utilities really do tend to be those third party libraries, your lodash, your. They just very clearly scream like I do one thing, I do it really well.

[00:04:48]
And I'm going to sit here in utilities and then I get brought into composables where then I start affecting state changes. Maybe I'm modifying xyz. That's kind of like the high level of how I like to think of these three things. But yeah, does anyone else have like.

[00:05:03]
We got a question.
>> Speaker 3: So your task list composable screams business logic to me because it had nothing view specific. Do composables give you access to props and other things by default if they're used in a component or?
>> Ben Hong: Nope. That's the funny thing.
>> Speaker 3: It is a composable then because it just sounds like it's a function you're passing around.

[00:05:22]
>> Ben Hong: Yeah, it does. The reason why this ends up becoming a composable, at least filter task specifically is because again, this kind of like a forecasting into the future, what we're going to find is that this task list parameter you're passing in is not actually always going to be a plain value.

[00:05:41]
Like this is what the assumption is right now. But you actually cannot assume that and I'll explain why in a little bit. So what you might do, for example, is you might abstract the rest of this filter like this stuff into a generic like logic function. But then this I would still make the case that filter task itself needs to be a composable because it's going to end up dealing with reactive state one way or the other.

[00:06:06]
But this is what's interesting about that three paradigm bit is that these internal bits to our point of search term, this search term filter, which to correlate for what people are thinking of is here it correlates to Did I stop the server? I think I did. No, I didn't.

[00:06:25]
I know what I did. Okay, What I did was remember filter tasks at one point had access to all the tasks. I added a parameter that we would have to pass it in and I did not update the filter task this to take it in. So, this needs to be passed the TaskStore tasks.

[00:06:51]
Now there you go. This search functionality, like view, as you can see here, coming up with these two instances, honestly, I would make the case again, we won't do this fully because we want to cover other things. But this particular snippet is so generic. So this might actually be an example of.

[00:07:09]
In this particular case, I would say probably just a utility function for like filter matching or whatnot. And so it's things like that where you just slowly start to just keep breaking it and chunking it as it makes sense. And then to your point of, like, actually, all of this stuff can most likely be genericized too, because what this stuff is doing, again, for those who want to dive deep later, is this combining the.

[00:07:34]
Basically the selections here. Yes. This one doesn't have that many. This one doesn't have that many. All status. Wait, I have this view on it. Yeah. So I can say completed. So it's basically combining all the different areas. Yep. And then. Yeah, so again, as we can imagine, that can probably also be then genericized as well.

[00:08:02]
So, we talked a lot about the different, a lot of the techniques we talked about earlier regarding generic components that provide. You probably would want like a base search filter, honestly, text that just takes it in, spits it out, returns back stuff, and then it just doesn't matter.

[00:08:15]
It doesn't care what the type is. In our particular case, it's very specific to returning tasks right now. But you can obviously genericize it to other things too. Got a question.
>> Speaker 4: I see people doing useTask and useTask$. Does it make more sense to do that than only one composable?

[00:08:34]
>> Ben Hong: UseTask versus useTask$? Are you referring to the fact that it's named Usetask or. That's what I would need clarification on. Because this is where naming's tricky too. People. I do know people who just use the plural all the time. I think it really boils down to what your team prefers.

[00:08:58]
Obviously it does not ultimately impact the code you write at the end of the day. So just I would say pick a convention and then choose it. The follow up was plural for everything related to a list and singular for one task. And they do both. Okay. So, there are, I think the most convention you'll see is they'll pluralize it when it's a list.

[00:09:21]
But I think I showed it. Yeah. Here I'm a big fan of because that one off. Off by one letter is the thing I found at least when I'm typing. So task list is just a little bit more explicit. And that's really what arrays are ultimately. They're a list of things.

[00:09:33]
So I personally prefer. Well, particularly with my parameters. I'm not sure I would, I guess, to be fair, I'm not sure I would call this usetasklist, because that's not necessarily accurate to what you're doing either. So if I'm being really verbose, I might just call it Use Task feature.

[00:09:50]
That's really what it's associated with. It really had nothing to do with whether or not it's plural or singular. It's just that this is the tasks feature that we're basically working on. But, you know, developers don't like to type, so we like to shorten everything. So I get it either way.

[00:10:07]
You know, I say choose whatever you prefer, it should not do you much harm.