Recap & Resources

[00:00:00]
>> Richard Feldman: So we're gonna do three things in this wrap up. We're gonna start by recapping our goals that we laid out at the beginning of the day. We're gonna talk about the topics that we ended up covering, and finally list some additional resources in case you wanna follow up on some of these concepts that we talked about earlier on.

[00:00:14]
Okay, so first we're gonna talk about the goals that we lay it out at the beginning. So we talked about ruling out more problems at compile time. We sure talked about a lot of that stuff. That was really a recurring theme throughout. We talked about how to organize and scale Elm applications.

[00:00:30]
So we talked about things like where to put your modules, where to draw the boundaries. How to think about how to organize modules in relation to one another. How to scale. In other words, in what order to build things out. We also talked about how to reuse parts of a user interface.

[00:00:45]
Whether it be parts of the UI, helper functions for some of the logic. All those different things, and all the different tactics we can potentially use to reuse things. And finally we talked about how to manage external data, thinking in terms of caches. External data coming from the server, coming from JavaScript.

[00:01:00]
Who is the source of truth, how can we make sure there's only one source of truth, and we don't have competing notions of those as we build out our application? In support of those goals we covered a bunch of different topics, we talked about opaque types which came up a lot.

[00:01:13]
We talked about extensible data, the idea of using a custom type to model like full articles and article previews. And how we could do that instead of open records which is sort of a more flexible, more powerful way to do that. We talked about ways to create constraints.

[00:01:27]
We talked about ways to introduce constraints at the type level with phantom types or without. We talked about ways to link articles, sorry, link views and update by adding additional arguments to messages. We've talked about scaling. And how to go from sort of a small application to a big one, while keeping our types nice and narrow so that, no matter how big it gets, we can always mentally break it down and slice it up into just the things that matter, just by looking at the types, and sort of more quickly traverse through a large code base.

[00:01:54]
We talked about reuse and a couple of different techniques for doing that, both in terms of UI elements, as well as in terms of internal logic. Talked about sources of truth and how to sort of keep them as small in number as possible, ideally to one. Talked about decoding and a couple of different ways to deals with that.

[00:02:12]
We talked about decode.map and contrasted it with result.map and maybe.map and decode.and then all of which are concepts that appear, not just in deciding, but in other data types, as well throughout Elm. And finally we talked about single-page apps and sort of concepts around how to organize the modules within them, how to name space things, how to load data, how to persist it between pages and expire caches and how to deal with things like routing and pages.

[00:02:37]
And all these we focus on sort of techniques. None of these were really with arguable exception of JSON decoding revokes on a particular package, but rather on just concepts that you can sort of apply. No matter what type of Elm application you're building, as long as it's at least related to these concepts.

[00:02:55]
Some additional resources, I mentioned a few talks in the course of this. Those are listed here, as well as a few others. So The Life of a File, by Evan. He talks about the idea of module boundaries and how to think about files in Elm. Accessibility with Elm by Tessa Kelly, she is the author of the accessible HTML package.

[00:03:12]
This is where she talks about that and how she designed it. The Importance of Ports talks about sources of truth by Murphy Randle, and specifically sources of truth with JavaScript interopt. He also goes into a number of other topics that are useful there. Working with Maybe, this has to do with when to use maybe and in a lot of cases, when not to use maybe.

[00:03:31]
This ties into our idea of reuse, and is it always the right choice to go for reuse? So maybe is something that can be overused, and he talks about some of the tradeoffs around reusing the logic that comes with maybe versus rolling your own custom type. Custom Elements in Elm with Luke Westby.

[00:03:47]
He talks about the alternative to other forms of JavaScript interopt which I alluded to very briefly in part six. Making Impossible States Impossible. That's one that I talked about at the very beginning of the workshop with regards to ruling out the things that ought to be impossible. Scaling Elm Apps also deals with a number of the things we talked about in the scaling section.

[00:04:10]
And finally, Make Data Structures, which is sort of my overall big picture advice in terms of in what order to build Elm applications, and it talks about sort of, focusing on the data structures firs. And the module and building module around them and then layering the view code on top of that.

[00:04:27]
Okay, that concludes our workshop. Thank you so much for coming.
>> Group: [APPLAUSE]
>> Speaker 3: I have to imagine so like I don't any place more than one in this metro that using Elm and production. But when like if I were to go somewhere and introduce it, and everything, it definitely would feel like I would be introducing a lot of legacy in the.

[00:04:56]
>> Richard Feldman: [LAUGH]
>> Speaker 3: Cuz I don't have all of this knowledge that we went through out of the gate and it would be silly to try to think that I could start there.
>> Richard Feldman: Yeah, but I mean the good news is like, you could re-factor, right. I mean like, even like own code that is like quite suboptimal is still pretty awesome.

[00:05:15]
I know having written a lot of it. [LAUGH] It's like the point of this course is to be like, you can do even better than that, but even if you don't, it's still pretty great in my experience. So maybe I should have made it a more overt disclaimer like, hey, by the way, it's totally fine if you're not doing all this, don't feel bad.

[00:05:32]
Cuz I know that's not necessarily true in a lot of JavaScript things. It's like, if you're not doing the best practices, you are screwed.
>> Group: [LAUGH]
>> Richard Feldman: That's not true, it's more like if you're not doing the best practices, then you're missing out potentially, on even better. But the floor is very high on how good the experience is.

[00:05:50]
>> Speaker 3: Would you say you can get pretty far [INAUDIBLE]. With a pretty good, create a pretty good application and miss some of the stuff, and then come back to it?
>> Richard Feldman: Yeah, the only one of all the stuff that we talked about that I would actually say is a genuine caution is, don't overuse html.map and command.map.

[00:06:12]
The only like, the thing that I've seen people say, I did this, and then I had a really bad experience. Was like, every time I use something, it gets its own model, and its own message and its own view and its own update and its own everything and I was like, I am 90% wiring.

[00:06:27]
How did this happen? And it's like, no. And I think that is an easy trap to fall into, because if you do all those things, you end up with something that has the design characteristics of a react component. So it's sort of a natural thing to do to be, I'm used to doing it that way, this is a way to get something that's familiar in Elm.

[00:06:46]
But it leads to a pretty bad outcome if you try to do that. So don't do OONFP, just leave the OON, [LAUGH]. Things will work out better. But, other then that all the other stuff it's just sort of like. This is good, but even if you don't do it this way I think you'll still end up having a good time.

[00:07:03]
I certainly have. [LAUGH]