Vite Templates & Setup React

[00:00:00]
>> Without that, let's actually look at the templates. Because I think it is pretty good for demonstrating the next big question that if you have not set it all out yet, you have thought about which is, all right, can I use React now? Can I use Vue now?

[00:00:14]
Can I use Svelte? Can I use whatever? And I would say get off my lawn. But I will show you how to do it because it is shockingly easy as well. So I'm gonna go and I'm just gonna show you how to use a template. And so we can go ahead, and we'll take a look in the answer for how to support a given framework will be in the template, and to nobody's surprise, shockingly easy as well.

[00:00:45]
And so we'll go up, I'll go up a level here. And I'm just gonna say your choice of, if you use npm, this is npm create vite, I almost slipped, @latest, and then where you want it to go. So we'll call it vite-react. And if you don't give it any arguments, It gives you this very pretty list, right?

[00:01:10]
You could have it wire together, I had a repo with a bunch of files in it, but guess what that started its life as? One of these templates, right? So you can do it with vanilla JavaScript. These are the built-in official ones, there's other things, Heidi and others.

[00:01:26]
Let's go take a look. The Electron and a Vitextra. All right, that one's new, I don't really know what that one is, I'm gonna find out that later. But for our point, all right, I called the directory React. We want React, it can be whatever, the answer's gonna be, everyone's like, React, all right?

[00:01:46]
All right, I know my audience. Let's do that one. Look, more choices. And you saw one of these earlier, right? We can do it with TypeScript or without TypeScript. And then basically, speedy web compiler is a Rust-based compiler. Is it as full-featured as some of the standard JavaScript ones at this moment in time?

[00:02:07]
Maybe, maybe not, right? Not for the most part, but for those in the room, no, it's not. If you watch this six months from now, the answer might've changed. But at this moment, it is faster, it is better, but it is not as battle tested as just not.

[00:02:22]
This is just processing a JSX. Let's do without just because I think it'll make it easier to see. Do we want with or without TypeScript? What are our feelings right now? We don't feel strongly, but yes, there's a thumbs up for TypeScript. Okay, and you say done and we do that vite-react, we'll do an npm install just so I don't see red squiggly lines everywhere.

[00:02:45]
And if you use yarn, then it's yarn create. If you use pmpm, it's pmpm create, it's all the same. Cool, we've got in place, and let's just open it up in our editor. And you can see a very similar layout here, right? It did give us a ts.config, it did give us a vite.config, we'll take a look at that because that's gonna be the first time we saw a config file.

[00:03:12]
So let's look at what it takes to support React. You grab plugin-react and you plugin React. And now you have full support for JSX and everything along those lines. Without even this plugin, since it uses ES build and ES build has this idea of a JSX parser, you could theoretically write your own JSX parser as a fun way.

[00:03:39]
You can have your own, cuz all JSX does is it turns the stuff looks HTML into a function name, whether it's React, or JSX, or whatever. And then the node name, the attributes, and then as children, it's always gonna compile that. You can give it a different function if you wanna write your own framework during launch, go for it.

[00:03:58]
Yeah, you could even use it to make regular vanilla dom nodes if you really wanted to as well, but all it's doing is adding this plugin here. And this is the first time we're seeing configuration, so it's worth talking about it. Really, all you need to do to have a valid Vite configuration is to export default some object that has the right shape.

[00:04:22]
This define config is useful because it's using effective whether or not you use TypeScript, it doesn't matter. This will work with JavaScript, but in VS Code, it will use the type information that the Vite comes with to help you with autocomplete for a lot of these, and let you know if you made a boo boo or misspelled something.

[00:04:42]
So generally speaking, I would always use to find config because why not opt into the safety? But if you just wanted to have an object like this, go for it, right? But that is the entire process, right? So a lot of these things, again this is that first act, right, of it is simple, right?

[00:04:59]
And it is powerful because all of a sudden, now I've got whatever framework, I've got whatever CSS build tools that I need. I have all of the common infrastructure that I personally find myself wiring up over and over again, and I just kind of have it all in place ready to go, and I'm not spending a bunch of time doing that.

[00:05:20]
And so you got, yeah, Mark.
>> Somebody was linking to the plugin checker, have you heard of that?
>> Yeah, there's one that will check the plugin itself, right? And also, I think that's the one that does the TypeScript checking for you, right? Yeah, I don't want that.

[00:05:39]
[LAUGH] Personally, right? So there's Vite plugin checker, see whenever I made a mistake, before I got that big box on the screen, if your types don't work, it'll do it in a separate process, it'll show you on the screen. For me, personally, having it in the editor and having it at build time gives me everything that I need.

[00:05:59]
Because a lot of times, I like the fact that it's not blocking me from rendering when I'm still prototyping. A lot of times, I'm still figuring stuff out, I wanna see, does this work at all? And then I'll kind of add in some the type safety, I kinda like treat it like JavaScript at first and I don't necessarily.

[00:06:17]
Cuz it'll start yelling at you for stuff like, well, your TS config is such a strict and you used an any in here. I'm like, I'm still figuring out what I'm doing, I'm pulling in some library, and I'm doing object keys on it, because I'm too lazy to not do dig through all the types.

[00:06:31]
So yeah, the Vite plugin checker will like do all that type checking for you. I personally don't like that in my workflow, but I would say if it works for you, go for it. The list of official plugins, you've got your view, you've got everything you saw on that list, basically.

[00:06:48]
And there's a site Awesome-vite, which has got a whole bunch of various plugins for various things. There's our Vite plugin checker that we talked about earlier, we'll use some of them later on. For whatever you need, there's also various other frameworks in here too that you can kind of play around with.

[00:07:09]
The other thing that you can do is, Rich Harris, the creator of Svelte, made this tool called degit, which basically is like Git clon. If you've a Git cloned and then removed the Git directory, cuz you just wanna use it as a template. You can just use this tool and give it the name of the repo, and it will effectively clone it, and remove the git, so then you can do your own git in it, and not have the template history.

[00:07:35]
And so mostly community plugins use this. And so what I've done personally is for all the projects I do, I've got two templates that I just use all the time, right? They're set up with prettier the way that I like it and es lint, the way that I like it, and my ts-config the way that I like it.

[00:07:50]
Everything's set up and ready to go to the way that I'm happy, and so that I can just do this and I've got my own Vite template ready to go. So even some of these initial configuration things once you get everything nailed down to the way that makes you happiest or the way it makes your team happiest.

[00:08:04]
In a lot of these cases, you can just basically use the repo as your template, and you're good to go. And then occasionally, I'll update the dependencies and stuff along those lines, so I always got a fairly fresh version. But as an easy way to do either for any of these community templates, or to make your own, or you can use mine, whatever makes you happiest are various effective ways of using these templates.

[00:08:31]
Somebody asked if import was a Vite specific thing or-
>> Nope.
>> Web platform.
>> It is a web platform thing. Import is not a Vite specific thing, it is a web platform thing. It is supported, by definition, in development, where actually the browser is using the ES modules out of the box, right?

[00:08:54]
Again, not compiling is faster than compiling, right? And so most modern browsers have support for ES modules these days. So all that import syntax is actually web platform syntax that just Vite happens to use, right? So if you put imports all over the place, you do all this stuff.

[00:09:12]
And then you find that you're not gonna use Vite, along as you do something that takes modern web standards, you're good to go. Especially, because again other than pulling that React plugin, we haven't really done, we've basically just written web platform code with a little bit of relative links.

[00:09:29]
And I guess that module.css comes from post CSS in a way it's configured. But predominantly, we've been able to use web platform stuff and using the web platform and to inform Vite about what the best thing to do is in this situation. But these are kind of standards that should apply broadly.

[00:09:46]
And don't, even if you've seen that ES syntax before years and years ago, under the hood, Babel was compiling it to common JS and it wasn't actually ES modules. I've been writing import, whatever from whatever forever. Yeah, that was unintentional rhyme, we'll go with it. Then in those cases, it was actually turning into const whatever equals require, and then the library name, but these are actually using real ES modules.

[00:10:12]
In development, at build time, it is then trying to chunk stuff and all that stuff to have the widest amount of support, and do tree shaking, and code splitting, and all that fun stuff.
>> In ts config, module resolution Bundler could you explain that.
>> A little bit.

[00:10:33]
So again, we live in a terrible time for a lot of reasons, but one of them is we are currently in this world straddled between common JS and ES modules. I know that Bundler is a new algorithm that came with TypeScript 5, right? M project doesn't use it because it would start before then, theoretically Vite is doing the bundling in this case.

[00:10:58]
It's just the semantics on whether or not you need the file extension, so on and so forth. I can't claim to be an expert on that one, so I don't wanna say something that's not definitively right on that one, because it is one of the newest algorithms for how TypeScript chooses to bundle it.

[00:11:14]
Interestingly enough, Vite is the one doing the bundling in this case, TypeScript is only doing the type checking. So as long as you're not getting necessarily the red squiggly lines or errors, TypeScript is not the one doing the building and compilation. So it doesn't really concern us at this point, but it is kind of the default standard that I grab over and over again, but for when I'm not using Vite.

[00:11:39]
But the actual details of the algorithm itself are not something I'm an expert on.