Wrapping Up

[00:00:00]
>> Thanks everyone for hanging out today, I know it's been a long day but hopefully, you found this useful. As far as next steps go, there's a whole world of TypeScript out there that we haven't even began to touch. Like I said, there are interfaces that you need to think about.

[00:00:15]
There are generics and all these other things that you could do with TypeScript. But to be honest, my recommendation when it comes to TypeScript is similar to my advice when it comes to learning frameworks. Which is don't try to learn every single technique in the world in an attempt to create the perfect code.

[00:00:29]
When you have a specific problem that you have, that's when you reach out and find a solution for it. So a great example of that is when I realized that we had a constant that was keeping a source of truth for our diet lists and that kind of stuff.

[00:00:40]
And then I realized that the TypeScript was replicating that in the types. This is when I went out to learn which admitted again, ODS and tax but it does solve a problem for me and that's when I reached out for it. It's really tempting I think as developers to try to learn everything at once cuz you're afraid you'll miss something.

[00:00:57]
But honestly, I think perfection is the enemy of progress and code purity can really get in the way of team progress when it comes to really what's most important, right? And so again, I can't stress this enough, TypeScript like many tools, it's wonderful in many ways, right? We saw it do a lot of good things for us but don't forget that we did that in a progressive way.

[00:01:16]
That was like let me help myself out by setting my intentions and then just picking it out when it makes sense for me. But you'll notice there are some times I didn't define types either and that's okay. That's actually a great way to just get your feet wet and figure out what makes the most sense.

[00:01:30]
The moment you get caught up in abstraction, that kind of stuff, that's when it can just blow up in your face. Then, instead of shipping useful features to customers, you're sitting there fighting types. And I don't know, that's probably not the best use of our time right, at the end of the day.

[00:01:42]
Because if you think about it, this is what users see, right? When they get your code, they don't see beautiful types, they don't see all that stuff. That's for us, that's for us to help them maintain and to ship faster. But at the end of the day, it's all about the features that we ship and don't lose sight of that when working on code.

[00:02:03]
With that, thank you everyone for joining me again today. It's been an absolute blast. I just realized, I have some questions I need to answer, right? Yep, go for it.
>> Is there a litmus test to know when it's better to migrate to TypeScript for scaling an app for the future?

[00:02:19]
>> Great, okay, yes. Thank you for the reminder. Okay, so this is for Shiva. When it comes to really thinking about scalability of code. Basically, in my opinion when it comes to the scale of code, it's about the ability of people to how quickly someone can understand your codebase.

[00:02:33]
And that really sets apart something that's scalable and maintainable versus something that is basically tricky to scale at an enterprise level. And so TypeScript is one of the things once again, that if your team is ready to start bringing that in and incorporating it and in a way that doesn't halt the progress of the tool chain.

[00:02:53]
Then by all means, it certainly is useful for that. But again, there's so many real world scenarios where people try to migrate and they find themselves stuck in build chain tools, like errors constantly. And so rather than making progress, they're just fighting over it and then no one wants to touch any of the files.

[00:03:10]
And then I've to say at the end of the day, you might be using a enterprise grade like TypeScript but if it's hindering progress, not a good thing at all. So once again, it's all about comprehension and ease of maintenance. As long as you get your team to feel comfortable with that, even if you just use JSDoc, you don't gotta use TypeScript, that works too.

[00:03:29]
So I think that's really the key thing to focus on and not the TypeScript part.
>> Which is better for bigger projects, Options API or Composition API?
>> Yeah, so when it comes to using Vue 3, I do think that at the end of the day, it's really hard to escape from Composition API.

[00:03:44]
We'll see this a lot in the rest of your workshop upcoming. But because of how modular it is, Composition API will be a part of basically every Vue 3 project going forward. That said, that doesn't mean that what you're doing with Options API is out-of-date either because there's sometimes some components benefit from that structure that Options API provides.

[00:04:00]
And so it's one of those things where choose the tool that best suits the problem that you're trying to solve, rather than trying to be like, I'm only gonna use this one method. So understanding the trade-offs and knowing your team's abilities, that will be the key to success for your project.

[00:04:12]
>> Is it possible to export computed props or methods from the setup script into a test file?
>> Yeah so, obviously testing is a whole thing. But as far as I'm aware, everything that we've done as far as types and all this stuff should be able to be imported into a test file so that you can use that and make sure everything is typed correctly.

[00:04:29]
And there's a couple key resources out there that I'll try to add to the resource list. But Worthman, yeah. So in case you haven't had a chance to check it out, I do actually have another workshop on Frontend Masters called Production-Grade Vue. Where I talk about basically different enterprise patterns that I've seen over the years.

[00:04:45]
And so basically, when it comes to testing with types, again, everything that we've done in the code should be able to be exported and imported. But the key thing when it comes to testing is in my opinion is to make sure that you have the end-to-end test. Cuz I know that a lot people get caught up in the unit tests but end-to-end testing in my opinion is the key part of basically figuring out whether or not your app is gonna survive or not.

[00:05:05]
And so the joke that a predecessor of mine always said was that there are two tests I always make sure that every app has. And that's one, can the user login? And two, can they pay me? After that, everything else is optional so something to keep in mind.

[00:05:18]
But in all seriousness when it comes to typing these things, everything should work as expected. I would recommend checking Vue test out for your unit tests. That's really taking sort of the community by storm as far as almost being like the next assessor to Jest so definitely check that out.

[00:05:34]
Great.
>> [APPLAUSE]
>> Thanks everyone.
>> [APPLAUSE]