Workshop Structure

[00:00:00]
>> Richard Feldman: We gonna get started with this, and go through this, and learn them over the course of this workshop. The structure of the workshop is essentially we're going to be working on a RealWorld example app. So if you haven't heard of RealWorld, it's sort of the bigger cousin enough to do MBC.

[00:00:14]
It's basically designed to be a Medium clone called Conduit, like medium.com. Get it, Medium, Conduit? And essentially, you've got these concepts of you can make a post. You can post an article. You can edit an article. You can see a feed of articles of people that you follow.

[00:00:31]
You can follow and unfollow people. You can like things. You can tag articles and do a feed in terms of the tags. And it also got a lot of basic web app stuff like login, logout, sign-up, and so forth. So we're gonna start off by just rendering a basic static page, and then we're gonna, over the course of the workshop, expand, expand, and expand.

[00:00:50]
And eventually we're gonna transition from the thing that we've built up from scratch, to actually working on the fully completed version of this code base. And we're actually gonna learn how to do things like fix bugs, and get a feel for what it feels like to modify and to work on to maintain an existing larger Elm code base.

[00:01:06]
Because that's really where most of Elm's benefits come up. It's not when you're building a toy application, but rather, when you're actually working on some application that's got a substantial bit of heft to it. Most of Elm's benefits are sorta of, for applications that get big and serious, and need to be maintained over the long term.

[00:01:22]
So, we've got nine lessons and nine exercises that go with them. And we're gonna start out with part one, rendering a page. Before we get in to this, are there any questions on any of the stuff we just talked about? All right, let's dive in. Talk about rendering a page.

[00:01:35]
So we've got four things we're gonna talk about here. First we're gonna talk about compiling. Just like how to build an Elm application using the command line. We'll talk about functions with the syntax and how Elm functions work. We'll talk about if-expressions, pretty basic conditional. And finally, we're gonna talk about the virtual DOM, which is how Elm accomplishes rendering.

[00:01:51]
All right, let's start with compiling. So as previously noted Elm compiles through JavaScript. The way that works is we will start up with file called Main.elm and we will end up with a file called elm.js, after running it through the elm compiler. So the way that works is you have your basic elm executable, which you should all have on your path at this point based on the workshop instructions.

[00:02:14]
You say elm make Main.elm and that's gonna tell the compiler read this Elm code, compile it, and then figure out what the corresponding JavaScript should be, and output it. You'll then give it a --output flag to say the name of the JavaScript file you want. And that's it you're done.

[00:02:29]
So there's no need to have an entire eco-system of build tools to build Elm applications. Really all you need to get up and running with Elm is this one Elm executable. If, on the other hand, you already have some build tools. Well, it's looks like, let's say you have an existing JavaScript application with webpack and all that good stuff.

[00:02:46]
Then you can introduce this using plugins. So there are plugins for webpack and grunt and things like that, depending on what you're using. So you can either use it like this, like we're going to use it in the workshop with just elm make and that being the only tool that you need.

[00:02:59]
Or, if you've already got a more elaborate build process you can also incorporate this into that build process using plugins. When you run elm make, you're probably gonna see this message quite a bit. Dependencies loaded from local cache. Dependencies ready. So what this means is, whenever elm runs elm make.

[00:03:15]
The first thing that it does is it looks at your dependencies, which you specified in your elm.json file. And it says, hey, are there any packages that we need to download? And if there are any packages that it needs to download, it will just download them right when you run make and then make them available as it's running.

[00:03:31]
All dependencies are downloaded once to a local cache directory in your home directory. They're not downloaded per project. So when we go into these different parts, we have exercises for part one through part nine. You're only getting the dependencies for all of those packages once. And each time you run elm make in each of those folders, it's just going to download any new packages that it needs, that you've never downloaded before.

[00:03:53]
Everything else is just gonna be from the cache, so it's most common to see that, yeah, when you run a new project, when you build it, you don't actually need to download any new dependencies because as it happens, you've already used all those dependencies at least once before.

[00:04:04]
We'll see a little bit more of that in the actual exercise. And then finally when it's done it'll say cool. Success, compiled 1 module. You can have multiple modules, so Main.elm might import several other modules with .elm file extensions. But at the end of the day all you need to do is .elm make at your entry point.

[00:04:22]
That's sort of the main file from which everything else is going to get imported. So it might say compiled one module if all you have is main. But if, let's say, you have 20 modules and maybe five of them change then it would say compiled five modules. You don't need to run Elm make on each of those modules.

[00:04:36]
You just need to put it at the entry point and it'll figure out all the other things that it needs to compile in order to make that entry point work. Also worth noting that it's only going to compile modules that have changed since the last time you ran it, or if their dependencies have changed.

[00:04:49]
So if you have 100 modules, but only five of them changed, or maybe one of them changed, but it had some dependencies that also needed to be updated, Elm's only going to bother compiling those. So, it's sort of as efficient as possible with your cpu, as well as your bandwidth, as well as your hard disk.

[00:05:06]
Okay, so once you've got your JavaScript file, we're gonna need to import it into our index.html file. So this is done pretty similarly to how you would import any JavaScript file. So, you add a script tag, src="elm.js". Maybe you also have a stylesheet with css. That's totally valid.

[00:05:21]
In this workshop we're going to have a css file, a stylesheet that sort of styles our application. But it's also totally fine not to have a stylesheet. You can do css in Elm, just like you can in JavaScript. There's a library called elm.css for it, it's pretty nice I think the guy who wrote it is very handsome and that's something that we use at work and have been pretty happy with.

[00:05:41]
But importing your JavaScript, your compile JavaScript is as simple as adding a script tag. What that's gonna do is it's gonna provide this Elm.main value. If you're using web pack or something like that, this can be set up to be required. Depending on what your set up is.

[00:05:58]
But, if you're not using something like that it will just be made available as a global, which is how we'll do it for this workshop. You call Elm.Main.init and then you give it a node to render into. Now, this is the typical way that people do things for incremental adoption of Elm.

[00:06:11]
So, you have an existing Elm application. People will just say, you know what? I'm gonna make a new feature in Elm, it's just gonna be this one part of the page though. It may be a sidebar or one little widget on the page. And you can just call Elm.Main.init on whatever node within the body that you want, even if it's just one part of a page.

[00:06:28]
As your applications get more elaborate, you eventually get to the point where Elm is taking over the entire body and doing routing and all that stuff, which is ultimately, what this example, that we'll be working with does. But when you're using it at work and just introducing it from the outset it's much more common to embed it in a single node like this.