elm-spa v6

elm-spa v6

Ryan Haskell-Glatz joins us to discuss the latest version of elm-spa, including authenticated pages and the updated file-based router.

PublishedJuly 19, 2021

Episode#35

Key new features in v6

Protected pages

Provide/redirect protected custom type
Eject workflow
Vuepress
elm-program-test docs site
Can Eject not found page
Eject workflow stops generating files when they're ejected
File-based routing in elm-spa
Inspired by Nuxt
Page builder API (like browser sandbox)
No more int or string in url
elm-pages 2.0 routing and splat routes
elm-spa add command
elm-live
Vite
elm-spa View module
UI namespace in elm-spa docs repo has a shared page helper function for building the shared header/footer
Shared module
elm-spa 6 has fewer ignored arguments compared to v5 - now wired through in page top level function and you can wire to update, init, etc.
Effect pattern - elm-spa v6 has an ejectable Effect module
elm-real-world SPA example (elm-spa-example using elm-spa framework)
elm-spa.dev
elm-program-test example folder
Blissfully jobs
#elm-spa-users channel on the Elm Slack

Transcript

And today we've got another guest joining us, Ryan.

Ryan, thank you so much for joining.

Ryan Haskell Glotz, the author of Elm SPA.

Hello, everybody.

Thanks for having me.

Elm Radio, boys.

And we talked about Elm SPA v5, and well, now we get to talk about v6 with you, which

I'm excited to hear it straight out of the horse's mouth.

Since we defined Elm SPA in the last episode, why don't you give us your definition?

What is Elm SPA?

Yeah, so Elm SPA, it is, I guess it's a framework for making single page apps with Elm.

So most people will tell you like, oh, Elm doesn't need a framework.

It's got the Elm architecture.

So it's not a framework like React or Vue would be to JavaScript.

It's more of a framework like Next.js or Nuxt.js, if you're coming from the Vue community, is

to Vue or React.

So yeah, so it kind of makes it easy to get your routing set up, kind of pass data between

pages, like choose how complicated a page needs to be, that kind of thing.

For people that are new to Elm, that can be really nice.

Yeah, it is really nice.

I think a lot of people are really enjoying v6 and the changes you've made there too.

So what are the headlines to you?

What are the most important changes in v6 in your mind?

So I think one of the flashier features of v6 is user authentication.

Previous API user authentication required a lot of like custom code, and it wasn't really

supported by the framework.

I kind of left it to the developers to be like, hey, like you can do it.

You can figure this out.

I'm leaving you.

You got to have faith in the people.

But what it turned out to be was a lot easier to just have a few primitives in place.

The current state of v6 user authentication, you can kind of say like, hey, a page can

You can get upgraded to a protected page.

And from there you can say like this page will always have access to a user or a token

or whatever you need for authentication.

In your case, you kind of define your own value that you care about getting to those

pages and you have like the guarantee that it's there.

You can basically just have a check saying like, hey, if the shared model doesn't have

a user, then I'm going to redirect to a sign in page.

If it does, then I'll allow the page to be rendered.

That kind of thing.

And people can define their own authentication system?

They can use JSON web tokens or whatever they're used to.

As long as that value can be stored in some way, that's the way to go.

So I think the most popular examples are API tokens and JSON web tokens and stuff like

And the way that API works is you return this LMSPA protected type, which can either provide

some value or it can redirect.

So there's basically a custom type that has two options.

I'd be kind of exploring maybe there's some extra options that people in the LMSPA users

channel and Slack have brought up.

Just like wait and do nothing might be one that's good.

I still kind of have to explore that.

But yeah, at a high level, you have like one spot in your app, one file called auth.elm

and you define a single function that takes in like the shared state and the current request.

And from there returns a custom type value.

So it's either provide page width and you give it the thing that you're interested in

passing through, or you give it redirect to, and then you give it a route.

So kind of like a URL, like a type safe URL.

Yeah, that's very cool.

It's kind of like a parse don't validate type idea.

It seems like that you're making sure that you have this data.

And if you do, you're guaranteed to get that nice typed validated data.

Otherwise you go to a different page.

And you don't have to re validate the user every time you want to access it.

If logged in all over the place.

That was a big pain point in v5 because it kind of made people implementing pages have

to use this weird model underscore.

We kind of have like the real model and then the model that the framework's expecting and

it was really messy.

But yeah, in the latest version, that's nice and clean.

So I'm happy with it.

And it actually came from a friend of mine.

I tried to convince to use Elm as we all do.

He was working on kind of like a Spotify app and he's like, how does user authentication

And I was like, oh, you just do this, this, this, this, this, and this.

And I'm like, this is a horrible explanation.

There's got to be a better way.

And a lot of the motivation is like kind of shame driven development, right?

Or you're like, if it's hard to explain it, it's like, maybe that's not such a good design.

Explanation driven development.

So shout out to my buddy, Drew.

He was the first test runner and is the reason that the user authentication model is not

And does he use Elm now?

So he's kind of working on a side project.

He wants to make a Spotify app called Boombox.

That's so you just kind of share your music locally.

I just kind of see what people are listening to in your area.

So that's his thing.

He's using it for cool.

He was the first LMSPA v6 user.

Alpha, alpha, beta, beta, alpha.

Like, I mean, you can really tell that these v6 changes were from real world usage.

Yeah, it's, it's, it's cool to see the transformation as, as you've sort of learned these things.

And so like another, another feature that's really interesting in v6 is the eject workflow.

And I found that that to me seems really unique.

Like I don't think I've seen any other frameworks using something like that.

Is that something you came up with or was it inspired by a different frameworks approach

or how did that come about?

Well, I'm glad it looks authentic.

I stole it from a view press.

So they have this, I am, I'm a huge fan of any tool that when you get started, it just

gives you like one or two files to look at.

Like I'm new to the framework, I'm new to the whatever.

So with LMSPA and in our case, it's three files you start with.

You start with the LM JSON file.

You start with the homepage, which is just like a view function that says hello world.

And you start with an index HTML, which is like the entry point to your app.

With view press, it was a similar situation.

So how they used it was for customizing your theme.

So for anyone not familiar with view press, basically it's a way to make like a quick

If you look at Aaron Vonderhaar's program test documentation site, he's actually using

You'll start to see the CMF where it's kind of like the new Git book, I guess, where you

kind of recognize the theme.

But if Aaron chose to customize his theme, he would eject like the default theme.

And then from there, view press would give him control.

So this, the ejection feature in LMSPA, there's like a lot of things that you might want to

customize like the main.elm file.

Maybe you want to add a top level message or the not found page.

You know, that's pretty common one.

But the idea is when you get started, you don't really need to look at all these files

So it's nice to be able to kind of incrementally introduce you to the different things as you

need them, as opposed to say like, Hey, there's like seven things you can ignore these five,

like look at these two and try to convince someone that it's like, it's okay.

Like, don't be scared about these five files that, you know, have a hundred lines of code

that you might not have read before.

And then if you like, like if you wanted to use vanilla elm HTML and have like title equals

title body equals list of HTML, then you don't need to eject view.elm.

But if you wanted to customize that, then you, you literally just move the file from

the dot LMSPA slash default folder called view.elm into your source directory.

And then you could use Elm CSS, Elm UI, and there's like examples for how to do that on

the repo, but that's the idea.

That's super clean.

So do you expect users to eject all the files at the end of their project?

And but yeah, it never ends.

Yeah, no, I don't, I don't expect anything like that.

I think, I think the main dot Elm file can really hang in there for a while.

For example, if you're not using authentication, you never did the auth.

It's really on a project by project basis and like how far it needs to go.

So if you still have files in the defaults folder, if you're out there, you're, you're

a very good developer still.

It's not no shame on you.

Like it's, it's totally cool.

I don't think I have ejected main dot Elm in any of my side projects.

The LMSPA website is built with LMSPA cause that's meta and exciting.

I don't believe that one has a main dot Elm file.

It doesn't have auth and it doesn't have a view ejected.

Does that mean you're a bad developer now?

I'm a bad developer regardless of what I've done.

But yeah, good question.

So the, so LMSPA handles or generates all those files while you haven't ejected them?

So it basically checks to see if the files, these specific files, there's about six of

them exist in your source folder.

And if they do not, it will generate them for you by default.

And what does LMSPA do once you've ejected them all?

It just doesn't generate anything.

So it just trusts that the code that you've chosen, you need to customize will do that.

Besides the other code generation that LMSPA will do like routing and all that stuff.

So these, these six files are separate from like the routing system and separate from

like the URL parameter wiring up stuff that, that you get with the project.

That's probably the big thing that LMSPA does that we haven't talked about, which is that

automatic routing based on the file structure.

Do you want to talk about that?

That sounds good.

So I also stole this idea from plenty of things.

I know like if you're in the C sharp ecosystem, like.NET MVC uses this, React.

Personally I took this from Vue's Nuxt.js project.

I was a big Vue developer before I encountered Elm.

I still love Vue.

I think it's, I think it's great saying I love Vue because it always sounds, sounds

very direct to the listener.

I love Vue.js as well as you.

But yeah, they, they have this really awesome framework called Nuxt where you basically

just create files in a certain folder.

And from that, the app can tell like what routes you want that you don't have to wire

up any routing code yourself.

So for example, if you want a homepage in LMSPA, you just put a new file called home

underscore dot Elm in the pages folder and that would automatically be wired up as your

The docs cover this in more detail, but you've got, you know, static support for like static

things like, you know, slash people.

You can also do dynamic things like slash people slash Dillon or slash people slash a

Jeroen or, you know, whatever, whatever you have.

And that's, that's all covered in the documentation.

But the idea is you don't need to go like looking for a certain page file.

You always know where to find it based on the URL structure in the browser, which is

There's a clean mapping.

It's also very nice that every page and every route has a kind of like a main function because

it reduces all the boilerplate that you need to write.

If you only need a static code, then you do page dot static and you give it a view function

or just no, just HTML.

No, no need to connect it with anything else.

That's really nice.

Every, every page will have a single page function and just kind of like a, an adapter

pattern going on, I guess.

But basically what that translates to in the real world is if you just need to render a

view, you just need to write a view function.

It's that same kind of learning curve that the core Elm has where it's like, you know,

browser dot sandbox, browser dot element, that kind of thing where if you're not, you

don't need to manage state, you don't need to yet.

If you don't want to send commands, you don't need to yet.

And you can kind of incrementally make your pages more complex as needed.

Oh, I'm wondering about something.

When I start a new Elm project, I usually start with something like a browser dot sandbox

I don't remember which one.

And they're very simple.

And as soon as I need more complex things, I like subscriptions.

I upgraded to the next function, like application.

And that transformation is a bit tedious to do.

And I imagine that in Elm SPA, you do it a lot more often.

Do you have ways to make that simpler or is it just now?

Do you have a shortcut for that in your head?

Let's put it that way.

Yeah, I guess, I guess my strategy for that, I still do the kind of manual upgrade.

There's no like, I think to really nail that down and get it right, there needs to be some

intelligent, like AST.

If only there were a static analysis tool that could transform AST.

Yeah, has anyone heard of anything like that?

Doesn't really help.

I keep trying to convince Jeroen that I think it would be really cool to have a code action

API in Elm review.

So it's not like this is something that's wrong with this code and I can either fix

it or here's where you need to fix it.

But like a code action would be like, there's nothing wrong with this, but I can do something

if you'd like me to in this location.

So your cursor is over page.static and then an Elm review code action could say, would

you like me to upgrade this to a page.sandbox.page.protected.

Just a matter of a whole bunch of things.

People applying, giving me the resumes, Hey, I would like to work on this feature and I

would like to do it for free, please.

I would love that.

I do it manually.

I think in like when you get like super, you know, when your app gets super far along,

I feel like there's probably a lot of common wiring that'll make you always lean towards

that those element, those more complex things just to reuse your modals or, you know, whatever

your common component system is.

But yeah, when getting started at, it's kind of the same flow as like the Elm core upgrade

So for the routing, V5 had this like, you know, you would do like source slash pages

slash hello slash name underscore string.elm.

And then V6 changed it.

So there used to be a string and int where the two types you could do.

Now everything is just a string, which I think makes sense and is nice.

Have you run into any challenges with this file based routing approach where, you know,

cause you do give up some of the power of this sort of Elm style API for a URL parser

where you, you know, you parse the URL and you say, if it ha if the URL has this shape,

parse this part into these types and make, you know, this sort of parse don't validate

But at the same time, like if it's just like rest style URLs where it's like slash users

slash one, you don't need to get that sophisticated and parsing and stuff.

So in your experience, like have you, have you found any, any areas where the file based

routing API doesn't quite fit well or does it generally work pretty well?

I guess specifically the change from like the int string to just string.

There's kind of a trade off there that I went with, which is, you know, however boasts here

pages are going to go.

And also something that was weird about the support for string and int is as soon as,

you know, folks would see that in the docs are like, well, what about my custom type,

you know, color?

It's like, oh no.

Well like by doing this now I have to support.

It is like a, an urge to support more.

And initially the string and int stuff I just pulled from Elm URLs, you know, core library,

Where that's the only thing supported natively.

I kind of, I got to a point where I just kind of thought about it and I'm like, at the end

of the day, they're all just strings in the, in the, the browser.

When I thought about the use cases of when I've used integers in the past, for example,

it's been to send a ID up to a server.

So for example, like, you know, people slash one, I might just send that over to my, my

So, and there are some invalid routes you can make, right?

You could say like people slash banana that you'd have to handle manually.

But I think you'd handle that in the same way you'd handle people slash like nine, nine,

If that didn't show up.

So in practice, I'm okay with it.

I will say that, for example, I've taken a look at Elm pages, the new like 2.0 routing

where you have like splat support and stuff like that.

I think that's like interesting things to think about.

In terms of the types of the variables, I think, I think strings are nice trade off

So people don't have to write their own like custom decoders or anything like that.

So I was curious as to why you removed the string and the int because I thought they

were pretty nice.

But once you removed them, that was like, hmm, maybe it's because when you need to handle

people slash one and you say it's an int, then what happens if someone types banana?

So do you need to add another file just to handle the error case?

Was that the reasoning partially?

Yeah, not really.

It was, yeah, it was mostly the whole, the whole idea of providing like an integer is

usually, is usually an ID that you're providing.

So whether that's a number that doesn't have a hit in the database or whether that's a

string that doesn't have a hit in the database, it's all kind of a 404 page type situation.

So you're going to have to handle in some way, like you said, if it's 999 or whatever,

whatever gives results in a 404, you're going to have to handle it somehow.

Also I do like that, you know, cause yeah, we're sort of spending a lot of time thinking

about these things, you and I, Ryan, the routing APIs and stuff cause for Elm pages, I've been

thinking about this a lot too.

And so the, there is something very nice about the consistency, kind of like Yuren was hinting

at like, if you have, if you have an int one, if you do like users.id underscore int dot

Elm in the old V5 API, then, then it wouldn't be handling routes that are not an int.

And then, well, what happens if like, what if you have a string one and what is the precedence

now of these different routes and stuff that you get into that sort of thing.

And it, that'd be messy.

You get a little bit messier.

So it's nice to just have a mapping and say, you know what, the file based routing stuff

is very simple.

If, if you have to sort of scrub the input and, and check it before, or go and hit an

API and look for things, then do what you got to do and let the user know if, if something

But the, the way we split apart URLs is very simple.

And I do like that for the, for the splat stuff in Elm pages, we should definitely,

I guess we'll, we'll talk about that more, we've got a call scheduled to nerd out about

all of these details even more.

But I think it's quite nice because you, so splat can be helpful in certain cases if you

want to just handle N URL segments.

And then the optional stuff is really handy too.

So if you, the optional stuff, like for example, in the, in the new Elm pages 2.0 docs that

I'm working on, I handle, like if you go to slash docs or if you go to slash docs slash

getting started, it's actually the same page and that's the optional segment stuff.

So if you do a double underscore, then that allows you to handle a maybe string for the

optional segment.

It kind of sounds like just regular Elm.

Like if you go to slash docs or slash docs slash getting started, it's just the same

Elm application.

Well, it's, yeah, it's going to the same Elm page.

It's like handling it through the same page module, but then, you know, the routes are

different and like the, the built in Elm router.

So the URL parser in Elm doesn't, isn't really built to say handle one or more segments.

It's built to be very simple where you say slash users slash int and it gives you that

int and you can do something with it, which is great.

But then it's not built in a way where it's like slash file slash whatever else comes

after that with a bunch of slashes after that.

You cannot do that with the Elm URL API, Elm URL parser.

So I actually had to use a custom URL parsing API under the hood in Elm pages 2.0 for that.

So it's, it's a, but I think that there's a ton of value to having like this file based

It's like, it's a game changer.

It's so, and, and like when you're trying to create, when you're trying to create an

about page as an example, right?

Like if you're trying to do that with your own custom Elm SPA wiring, sorry, not like

Elm SPA itself, a generic Elm SPA wiring.

It's a lot of work to create an about route and wire it in and wire up all the pages.

It's like, Oh, here we go.

Like you don't, you don't want to do it, but like with Elm SPA, you, you say Elm SPA

add slash about, and then it gives you what's the syntax slash Elm SPA.

That's totally right.

Yeah, you got it.

And then if you want to do a template, you can use one.

If you leave one off, it'll just give you the default view.

So it's not like static or sandbox.

As soon as you type Elm SPA add and then slash about, you can immediately visit in the browser,

you know, local host, one, two, three, four slash about whatever your dev server is running

at and it'll say about right in the window.

So you know that it works.

It's a game changer, like creating an about page.

It's night and day with that workflow.

And it's just, it's a huge quality of life improvement.

A long time ago when I was first messing with Elm SPA, you and I talked Dillon about this

or it's just like, what's that 20 second demo that'll dazzle them.

And that kind of inspired like the code generation bit.

There's a lot of great code generators out there for doing more sophisticated stuff.

So I kind of had like a conflict.

I'm like, I'm just going to make it simple.

They kind of made the same trade off with Elm SPA server.

There's already Elm Live out there.

I didn't want to say like, Oh, Elm SPA's.

I didn't want to say Elm SPA's dev server is an alternative to Elm Live.

I didn't really care in getting involved in making a dev server.

So what I did was I kind of made a Elm reactor like server.

What did you build that with?

So that's just vanilla node, HTTP.

There's some WebSocket stuff going on.

Just like a simple, I kind of looked at how other projects were doing it.

And the trick is they just inject a little script tag with a web component listener listening.

So anytime in Elm SPA server, anytime you make a file change, it basically sends a message

to tell the browser refresh.

Super super simple.

It's like one line of JavaScript versus like a bunch of dependencies that I don't want

to patch when someone decides they don't want to be an NPM contributor anymore.

So basically like if somebody wanted more sophisticated hot module replacement and web

pack stuff pulling in NPM modules and stuff like that, then you're like, okay, you got

started with the equivalent of Elm reactor.

And it's actually just an Elm map that I'm sort of helping you generate a few modules

So go create your web pack, configure whatever config you want to use, go for it at that

And the CLI has a few commands to make that easier.

So right now the Elm SPA server command, it'll generate the files, it'll build the Elm project

with Elm make, and then it will spin out the server.

So there's also commands that just kind of strip away those extra features so that it

can interop better with web pack or parcel.

So you just run like Elm SPA watch that will listen for file changes and that'll generate

the code, but it won't build your project and electric dev server and your process handle

And there's an example of the change files.

There's an example in the examples folder of how to do this with VEAT, which is one

of the fancier, faster, another view ecosystem based thing.

This is like basically a view sales pitch.

VEAT is the new hotness.

It's like, it's all the rage these days.

It's pretty, I've been very inspired by VEAT's philosophy as I've been building Elm pages

Cause I, unlike you, Ryan, I bit the bullet and went all in on building a custom dev server

for Elm pages 2.0 because Elm pages is different because it has a life cycle on the server

side where it's like running these data sources and stuff, right?

It doesn't just create an Elm map.

So there are all sorts of like things that create a much better dev experience when you

have a proper dev server.

So I had to create a custom dev server for it to get those things for Elm pages and it

was hard, but I was super inspired by VEAT's approach of this sort of just in time.

Compilation approach.

So VEAT is very cool.

Like I love this.

I love this approach of like you start up the dev server and it's like, all right, the

dev server is ready, right?

It's not like, let me go compile the whole world and get back to you.

And then five minutes later, it's ready.

It's instantly ready.

And then you go load a page and it does the work it needs for that page.

I'm a huge fan of like the, just the documentation too.

And that if you like good documentation, like Elm and viewer, like the top in my opinion,

like they're so good at writing like clear beginner friendly docs.

So like shout out to docs, docs authors everywhere.

You're doing great.

The unsung heroes.

So I noticed there's also in the, in the view.elm module, which we talked about in Elm SPA,

which you can you can eject or use the default one.

There's this sort of, you know, API, so to speak for, for that module that the module

exposes a view type.

It exposes a placeholder value, which it takes a string and it gives you the view type.

It it has to expose a none, which is a view type that's empty.

So this is another really interesting sort of like developer experience thing you came

Or I don't know, maybe you, you were inspired by another framework there, but tell us a

little bit about like the view module and like this placeholder thing.

What's the idea there?

Yeah, so so the view module at a high level back in like Elm SPA version three, I was

trying to wrap everything in my package.

So what I mean by that is in order to spin up like a sandbox, it had to be HTML.

And then there was like modifiers for like, Oh, what if you're using Elm UI?

And I quickly kind of realized that I need to cover every permutation of every view library

that ever exists.

And I just at that point would disallow any custom view libraries.

And that's something I'm a huge proponent of, like making your own custom UI type that

kind of encapsulates your design system.

Like that's a huge plus.

So I needed something that was going to be generic and kind of pluggable.

So view is actually a generic argument at like the core library.

You don't really interface with the, so I didn't talk about this earlier, but Elm SPA

is primarily a CLI tool available on NPM.

There's also an Elm SPA package, but that is more so to constrain the CLI and to make

it so you can't modify things that would break the CLI.

So in version five, you could potentially change the page function because it was in

user code land, I guess.

And what that led to is people bricking there, basically giving it the shape the CLI didn't

And then they get these weird cryptic errors that generated code.

So in order to kind of take a step away from that, the new Elm SPA package is really about

saying, no, I control the page type.

This is what I need to be able to generate stuff for you correctly.

But in order to do that, I needed to wrap, or to take your view in as a generic argument.

So that's a long winded way of saying that the view file, the view module is a way for

you to just give the framework what it needs to do all the right stuff.

So connect your pages together.

You're going to need a map function to bubble up messages and things like that.

You're going to need a two browser document function to convert it at the very top level.

If you ever get to the point where you do eject the default main file, you'll see it's

being used there.

It's a view.two browser document, because that's what the Elm runtime is expecting.

It's expecting that core thing.

So whether you're using Elm UI or Elm CSS, there's always a function at the top level

that'll convert those libraries to that.

And you can just wire that up in one place.

And then yeah, the view.none, I needed that when I implemented protected pages.

That's kind of like an implementation constraint there where when you're looking at a page

that you don't have access to a user yet, but you haven't quite redirected, there needs

to be something to render there.

So view.none is called by the generated code for you.

So you just need to provide that.

You don't need to wire that up or anything.

And then view.placeholder is for the LMSPA add feature, just so that no matter what framework

you're using, I can always render something on the screen with whatever UI library you're

It's really interesting.

Did you consider customizable templates as a way of doing that?

Because that seems like that would be the other alternative would be to let users customize

their templates for the add commands.

But I mean, at that point, the users could also create their own custom tool to create

these templates.

But there are a few LMSPA specific things it needs to add in the imports and stuff.

This is an Elm radio listener special.

I'm going to let you guys in on a little secret.

You can do this with the current LMSPA 6.

I hit it because I didn't want to...

I wanted to experiment with it and see...

If you build a foundation on stuff like this, people will send you issues at three in the

morning and say, why doesn't it do this?

So I wasn't sure if I wanted to announce it, but why not?

So if you look in the.LMSPA folder, if you're currently using LMSPA v6, there is a templates

folder and it's got four files in there, one called static, one called sandbox, another

called element, another called advanced.

Those are actually the templates that I use.

I use some bizarre handlebars and text thing.

You can take those out of your Gitignore and actually make your own custom templates there.

And you can even create your own.

So if you created within LMSPA templates, let's go back to the banana example.

If you created a banana.elm file, the CLI would accept LMSPA add slash fruit and then

like banana, and it would use that custom template.

So if you're a power user and you listen to Elm radio, then yeah, you can make stuff specific

There are, that being said, as a disclaimer, there are better tools out there for this.

At my company, at Blissfully, we use Plop, which is like a template generator where you

just plop in kind of random things.

They've got like functions like to camel case and to sentence case, nice helpers and stuff

So for more advanced use cases, don't ask me, just use a better tool for the job.

That's kind of a simple one that gets you up and running.

The framework really is responsible for making a templating language.

That's fascinating.

I'm going to need to look into Plop, but that's really cool because I've got like a similar

thing in Elm pages to like create a new route and you know, it's, and I've been trying out

this like view placeholder pattern, which is cool, but it definitely like as a user,

when I'm using Elm pages V2 working on things, I feel a little frustrated that I have to

then go replace it with my own record type and stuff.

Having a nice templating system is like game changing.

You can really save yourself some time that with good code generation and you you're a

Now, by the way, the, these templates, so the, so it's this templates folder that has

like an advanced element sandbox static.

Are those hard coded options or if you add different named things, will those be exposed

If you add different name things, they'll be exposed.

We're not documented anywhere.

So you're really going in the wild west.

If you're using these things, you're going off the grid.

I can't help you, but you'll see, you'll see examples of where the module name is inserted.

Those templates, your warranty is void and null.

No liability on this, but feel free to feel free to look at those if you want.

I personally don't mess with them.

I haven't, I haven't gotten there yet.

I would use a third party tool for that.

Just like with the dev server.

I think the approach is we need a sane, stable way to like make apps that just work without

any dependencies.

And then if you want to get fancy, feel free to get fancy.

Right, but you strongly endorse getting fancy and building your own templates.

So what is it that plot brings you that the templates that you have don't?

There's a lot, I mean, templating languages, there's so much sophisticated stuff.

It's like when you, when you start to implement one, you think it's going to be easy.

And then you realize there's all these edge cases and then people will be like, Hey, like,

you know, I created a file called about us, you know, with a capital A and a capital U,

you know, Pascal case together.

But for my thing, I really want it to be, you know, hyphenated in between like different

converters like that kind of come out of the box.

So I mean, plop is when I'm familiar with, cause I, cause I use it at work.

But there's gotta be hundreds of these things out there where you just generate strings,

It's then in the day, we're all just making strings.

It's not, it's not special, but I did not put a particular amount of time into making

a templating engine for those things.

Cause I just know there's so many out there and it's not the worth the effort.

It's kind of like the Elm live approach.

It's like someone spent a lot of time making a really nice thing for this.

One, I don't really want to step on anyone's toes, but two, it's like, there's so much,

so many more edge cases that they've accounted for that I would have to like kind of reinvent.

So yeah, I think that's sort of the Unix tool chain idea too, to like do one job really

well and let something else do a job really well and compose together with your tool.

And when you can, when you can narrowly define the scope of something and do something really

useful, really well, it's gold, pure gold.

So I had another question about, I believe in V5, in LMSPA V5, there was like a shared

Am I misremembering that?

That's correct.

So I'm curious about like that change.

And also like as a user, if I wanted to create an LMSPA V6 app and have like a header and

footer on every page, where would that live?

Yeah, that's a really good question.

That's like super common.

Just so I can understand, because I don't remember what it was for.

The shared view was for adding global layouts and it was not for saying, Hey, I want to

use LMI or I want to use LMS CSS.

So the view module, different than the shared.view function.

So shared.view is like you're saying, and this is kind of the naive thing that I think

when you start an app, you think is the case, which is all pages will use this layout.

Which falls apart as soon as you have like a sign in page, right?

It's like, Oh, actually I don't need a nav bar on that.

So I kind of hit this thing where I was providing, I made it easy for people to do the wrong

So here's your shared.view function, put your header in there, put your footer in there.

It'll be great.

And then you, you know, want a sign in page.

It's like, well, how do I support other layouts?

It's kind of a natural question that comes out of this because I don't need the header

and footer here.

So the solution with V6, and you can see this in the, if you go to the LMS PA repo, you

can see in the doc site, this kind of connects back to our earlier conversation about like

the Splat routes and like the optional parameters and stuff.

The way you reuse things in Elm is you just, you know, you make a common view function.

You do the same thing with LMS PA.

So the way that I got around that is I created a UI folder with a module and a called layout,

and I have a few layouts to find there.

And you can wire those up at the view level if you want, but if your header and footer

have to deal with state, you can't just wire that up to the view level.

So depending on your use case, that could be as easy as a reusable function that your

view would call like UI.layout.default.

And then you wrap your page in that.

So just a few characters there.

It's not too bad.

Or if you have like state you need to wire up, you can actually create a different page

So like page.static, page.element, you can create like a UI.layout.element, which takes

in your init, your update, your view, and kind of wraps it in its own special model.

I feel like LMS PA, the site did the first approach.

I don't think it needed state for its thing, but maybe that nav bar search did.

So let me verify that really quick.

But yeah, if things need to get more advanced, you can kind of make a page, a common page

function that wraps your init, update, and view.

And I think that's what we do here.

So going the composition way instead of the inheritance way.

It'll always be more flexible at the end of the day.

It'll always be easier because there was a tech talk that Evan gave a while ago, and

I don't even remember what one it was, but he said something along the lines of like

your view code, it's always going to diverge.

It's never going to become more similar.

You're not going to be like, oh wow, this all of a sudden is the same component.

It never happens.

So just being flexible and saying like, no, there is not one top level layout always.

That's like a good constraint not to set on yourself.

But it has a few characters on each file.

Yeah, that'll get you.

If you're afraid of characters, Elma is not the language for you.

If you want to have a good time, that's when you use Elma at the cost of typing sometimes.

I mean, even just programming is not for you.

It's like Siri, please type all the space.

There's got to be a voice app for that, right?

GPT3, is that what it is?

Give it a few years.

So you're saying like you can have like a suite of helper functions for expressing different

layouts, like wrapping with different layouts.

What about you could also like have your view function be a custom type, right?

That would also be a way to approach that?

Yeah, you could make your view function.

You mean as opposed to just like a view message, you could have like a different, yeah.

Yeah, you could have it be a custom type where each variant is with header photo or whatever

That is a really cool approach.

And that's what I love about accidental flexibility that the framework has.

I really tried not to constrain too much.

And so when Dillon has a great idea, like, hey, you could use a custom type.

I'm like, oh yeah, you could.

You know, it feels good.

It's like, yeah, go do it.

I don't have to implement it.

Anytime I constrain something or I make something unavailable, that's really when I put people

in a rough spot.

So a lot of the progress on LMSPA has been kind of cooling off, like stepping off the

V3 had like transition support and I'm like, this is way too limited to maintain and it's

not what people really need, which is full control over how things fade.

It seems like a Matt Griffith problem to me.

It seems like an animation thing I don't have to worry about.

Shout out to Matt Griffith, LMI guy.

He's always up to something.

I'm sure he's got some cool animation thing in the works.

Oh, he's got some things up his sleeve for sure.

Talk about transitions.

You guys do a transition.

Two transitions.

So how do you handle going from one page to another now?

Like I'm not talking about the animations, but how do you change the model?

How do you initiate your page?

How does that work now?

So right now from a user's perspective, the most common way to go from one page to another

is using that A tag, right?

Where you just have an href.

So from a user's perspective, all you'll do is you'll make your URL slash people.

There's some helpers to make that type safe if you want to use routes.

But what LMSP will do under the hood is it stores a shared model, which persists across

page transitions, going from one page to another, and it stores a custom type for the page.

So there'll only ever be one page state active at a time.

So for example, if I am on the homepage, I navigate to the about page.

I'm going to reset my page state to be the about page, but my shared state is going to

So there's this notion of a shared module that Dillon alluded to earlier, that's going

to store data that you might want to persist, like a logged in user or, you know, I'm not

sure what else.

That's the most common example.

There's plenty of things that you might want to persist, like the time zone or whatever

So this is something I've been wondering about a lot ever since I discovered LMSP.

Imagine I have a page where it has tabs and choose that each tab corresponds to one segment

So it's like about slash team about slash CTOs.

And you go from one to the other, but it's almost the same page.

But there are like UI things that you want to keep, like you want to keep the accordion

open when you go from one page to another.

So as soon as you have a page transition where you need to keep some things, do you put it

in the shared model?

Because that feels like kind of a waste in a way.

Yeah, it's like a weird trade off.

So right now, like one of the biggest constraints of LMSPA is that routing, the routing is managed

by the framework.

So you run into these weird cases.

So yeah, you have two choices there for that example.

One you move things in a shared, which kind of feels a little clunky and weird.

Another one is you use query parameters as opposed to the nested slashes.

So you could say tab equals, you know, about tab equals CTOs.

That won't change.

So it's kind of sad.

And I'm sure there's a better solution out there to it that you can't have full flexibility

of like, hey, this is just like a sub page transition.

Don't clear it.

The third option is you eject that main.elm and you add a specific handler for that.

Like if I'm going from this URL to that URL, don't call page init again.

That makes sense.

So if you take a look at the default main that's provided, I don't hide that underneath

That's not hard coded generated code.

You can take full control over that.

And you can say when I get the page message, if I'm switching URLs on URL change, for example,

if I go from this to this, don't clear things out.

So you have the flexibility.

It's a little extra work.

I think my choice would be the second option because it's the least resistance, which is

just use a query dictionary for that.

So what happens when you only change the query parameters?

What is the flow that happens behind this Elm ESP?

So if you change the query parameters, it will not re initialize the entire page.

So you'll have your current state.

I'm actually, I got a good question in the LMSP users channel about how to respond to

external changes from like, let's say like the shared model changes on a subscription,

for example, how can the page respond?

How can the page plug into that?

LMSP v5 had a mechanism for this.

If you're familiar with like the load function where you kind of get like a, almost a hook

that triggers and says, Hey, like something changed from outside you in this new area

I'm exploring, which would be a compatible minor update.

We would have hooks for query parameters changing as well as shared models changing.

But to, I guess, to answer what happens to your shared state in the current state of

things, your page state will not change and you will have access to your, you will always

have access to the latest query parameters for every page that you use, whether it's

a static page or an advanced page or an element page or whatever.

You'll always be able to view the right tab based on those changes.

So the view function would be called again, but not updates.

Which, which you can actually see in the, in the main.elm in the defaults, which you

can eject, there is a changed URL message and it says, if URL.path does not equal model.url.path,

then it's going to init the next page.

So, so you actually can tweak that if, if you need to for a particular use case.

But I like Ryan's philosophy too, that like, if you can be on the same page, if it, if

it effectively is the same page, semantically, then why not keep it on the same page?

Like do you really need to change the URL?

So it's up to you.

How are the people?

So the, so let's talk a little bit about the, the difference between shared state in V5

So like this is, this is one of the, this is one of the really interesting features

So when I look at the changes here, it, it makes me think like we talked about how shared

no longer has a view function, how that view function now lives in main in LMSPA V6.

So it seems like the shared module in LMSPA V6 is really focused on state.

It's just shared state.

It's not shared anything else.

Is that a fair assessment?

Yeah, absolutely.

I think that's spot on.

It's yeah, the shared, the shared model and everything in that shared module is really

about what state do I care about that I don't want to clear as I navigate to a different

Including flags because you can't like, it wouldn't really make sense to handle flags

over and over in every single individual route.

You kind of, you get flags when the app starts, whatever page it starts on and then you handle

it appropriately.

And you can choose to persist those to your shared state.

If you ever need to reference them again, sometimes you'll have like some, some data

that a certain page will need.

What's cool about V6 is every page will have access that shared state.

I've changed like the external API.

I used to have like a, like an Elm core main function that returned one value.

Now I return a function that takes an arguments.

So the arguments are the shared model, the current like request, which includes the URL,

the query parameters, the route and everything, and then you return a page.

So you can choose like if your view function is the only thing that needs access to the

shell, you just pass it to the view.

You don't need to type all this weirdness where it's like init taking a shared, taking

a request and ignoring them.

That was kind of the old, the old API that I'm glad is gone.

That, yeah, that's a really interesting design you've got there.

So the, so you're saying like when you, when you define a page, the equivalent of like

doing like a browser dot application browser dot element, when you define that for each

route that top level page function has, has arguments, which you can choose to wire into

the view function, init update and all those places, right?

Context that you might opt into, but it's always available.

So you don't have to complicate your, your code to deal with the fact that they're there.

You just choose if you need them or not.

So you don't have to annotate, init, update, view subscriptions with all of the things

that it has access to.

You just wire it through if and when you need it.

Super interesting.

So V5 had save and load.

So like, tell us about that change.

Cause that was like a really interesting design.

What what made you change directions there and what are the benefits of the of the new

So save and load in the previous iteration of V5 was a little bit, it was interesting,

a little controversial.

It was a little like, what the heck?

Very quickly to summarize what, what that kind of mental model was.

It was let's keep the init, update, view and subscriptions function just as they are in

Like people coming to the framework will have the exact same APIs.

They'll return commands, you know, init and update the subscriptions, return subs and

we'll all be happy.

Commonly, if you're building your own, wiring up your own SPA with Elm, you, you, you'll

commonly see people do like a triple out of an update where they do like model.

I've got a command and then I've got some type of you know, shared update thing.

And out message type thing.

So the idea with the save and load is when you get to that, that final most advanced

type of page where you want to potentially update like the signed in user and the shared

state you would create these two like implement these two functions.

And one of them would write to the shared state when the model changed.

And one of them would read from the shared model if the shared model changed.

So you could do effects.

What I found was happening in practice from that design.

So the API was nice, but what that led to, and this kind of goes in tandem with that

the page design that we talked about where you always have access to shared and request.

Previously init was the only function that had access to the shared state.

So what you were seeing people do was they would cache a local copy of the signed in

user and it was up to them to make sure that if the user signed out that they were listening

and that they correctly invalidated their local cache.

So I was forcing everyone to deal with this local cache and no one really complained but

they should have because that it was a lot of typing and it was ultimately for a less

reliable experience.

So with v6 the way I fixed that was instead of doing that triple pattern, I extended kind

of the second bit.

So instead of model command, now it's model effect.

And what that unlocked for me was the ability to play well with Aaron's own program test

Also allowed me to say like to send shared messages from an init and update as you could

in previous versions of LMSPA or like you might want to in a real world app without

the need for save and load and without some of the headache of that.

What I got rid of was load is actually useful as we talked about a little bit earlier where

you might want to respond to an external change that you don't know about.

So I'm looking to add that back in in a way that doesn't break anyone's code base.

It's like an optional upgrade.

A hook that tells you that the shared state changed.

So like if a user gets signed in, you know, off some asynchronous process to basically

allow you to turn off your loading spinner on a page or something like that.

It's a pretty common thing.

So but yeah, so save and load are gone and I'm happy.

And with messages like so let's see the effect to command is where does that code live effects

That's a default module.

So you can also check this effect module just like you would view or shared and control,

you know, if you want to define your own custom things for doing program testing.

But by default, it has two functions to command and or sorry, I think it's from command and

from shared message where you give it a command.

Well, you give it a shared update.

Okay, so that so that's an effect type that you you have in the default, ejectable effect

module that it's just shared with a shared message.

And then that's just going to trigger that.

That's really interesting.

That's really interesting design.

So you kind of kill two birds with one stone you you got rid of this thing that was tending

to lead to people ending up with stale data in their model from the shared data.

And you enabled the effect pattern, which allows people to test with Elm program tests,

because that requires an effect type, it can't directly test commands.

And you can pass these shared effect messages using that pattern.

So you killed two birds with one stone with that design?

Yeah, yeah, I'm happy with where it landed.

Yeah, very interesting.

Yeah, definitely seems a lot simpler.

Do you think do you think there are any trade offs with like, reaching in, like basically

being able to trigger a shared message from anywhere?

Are there like, does that concern you?

Or in practice?

Have there been issues?

Or is it just fine?

In practice, there haven't been issues.

I always feel bad exposing custom type variants outside of a module boundary.

Even even like simple examples where I'm kind of should like think about like, Boolean,

it's like, it always feels dirty.

Lowercase t, r, u, e equals capital, true.

And you can go that route.

If that makes you feel bad, you can kind of create functions that just expose it for you.

So you have a little bit more control over like, what can be caused by the outside world,

like what pages can send.

Yeah, there's there's a, I think the Elm debugger takes care of any, any weirdness.

So you'll see that like, you know, that message is being fired off, and then you just got

to hunt it down.

But that is a, I think it was a trade off worth worth making in the grand scheme of

But yeah, I'd rather have Yeah, I want it's like, I want everything, right?

It's like, I want you to have one place to write your shared update code.

But I don't want you to I don't know.

No, but like you said, I like that.

I like that thinking, like, I mean, you know, once you eject the shared module, it's yours,

you can, you don't have to expose all of the variants of the message type.

And you could have like, shared, like type message equals internal, and then have like,

a bunch of internal ones that you don't expose, and then external, and the external ones could

be exposed, or you could expose constructor functions forward or whatever, like, so you

can sort of define the constraints you want to there, which is pretty, pretty cool.

Yeah, another Dillon idea that you don't need to support.

Yeah, this is great.

Like, it's always has great ideas outside of like routing stuff, then I'm the happiest

You know, it's like, it's like, well, I want a number at the end of it's like, Oh, sorry,

You know, like, I kind of got you on that one.

But yeah, we're all doing our best, you know, to make nice stuff.

But yeah, that would totally be supported.

Yeah, what you described?

Yeah, being giving some flexibility and not over constraining your framework as a as a

framework author is basically the best way to be smarter than yourself.

Because your users are going to come up with smart ideas that you would have never thought

And that's just a fact that you have to accept as a framework author.

So you can't can't try to outsmart your users.

Yeah, but especially in the Elm community, you also want to prevent people from falling

Totally, totally.

Or in my case with v5, enforcing them into pitfalls with that.

Save state caching thing.

Yeah, please fall into this hole, please, please just you don't have a choice.

Follow the line.

You want shared data, don't you?

I really like this.

Don Norman design of everyday things concept that basically like, if there's a door, and

you try to pull it, but you can't because it's a push door.

That's the designer of the doors fault, not the puller of the door.

It's not their fault.

The puller of the push door.

The puller of the push door is not at fault.

And well, I mean, your ruin always references this Elm philosophy idea of take responsibility

for user experiences.

And that it is is a great philosophy, I think.

And I think LMS PA does a great job embodying that of like taking responsibility for creating

nice user experiences in these ways, but also giving the right extension points.

And and I will say from experience, it's hard, it's hard to create a meta framework in Elm

because like Elm doesn't give us tools for doing some of these things.

For example, saying this module must expose these types and functions like a prototype

There's no concept of that, right?

So by the way, have you done any?

I know of a tool that can do that.

Yeah, actually, that I think it's not a bad idea.

But you can do that with code generation.

Not kind of not kind of kind of why I ran into a problem with this with LMS PA where

in order to render just the view function, or you know, in order to plug your page in,

you have to expose the page, right?

If you don't expose the page, sorry, you get a weird error, you know, in the middle of

a generated code that says, sorry, in the previous version in v5, right, you would get

this crazy error saying, oh, generated dot pages dot Elm is looking for dot page, but

I you know, this module doesn't export it, you get this really like nested error in a

file that you're not supposed to see.

So what I had to do, I think is what Dillon's alluding to, which is like, check what's being

exposed and give them a nice error.

You have to intercept it.

So you can do it, but the error is terrible.

Yeah, yeah, you basically get an error somewhere else.

It's pointing to generated code.

That's the problem, which is extremely confusing.

And it I mean, it will prevent you from shipping the code and having users see the problem,

But as far as like, take responsibility for users experience goes, it doesn't really hit

the mark there.

So it requires a lot of like clever design architecturally and a lot of like doing like

putting a lot of love into these little tricks to try to check things to intercept errors,

just to let the user know, oh, hey, you need to do this here.

And so when you see those messages, users just know that Ryan's put a lot of love into

giving giving you those nice errors.

We care here at LMSPA industries.

Wait, we're not all working at fruits.com.

So if you want to start an LMSPA project, you do LMSPA new.

Do you have any tips for people who already have a project that is using the regular elm

slash browser to start using LMSPA?

Yeah, that's a that's a good question.

So I mean, every I think that the trick is without the framework, it's all kind of the

Wild West of how things are structured.

I think the I'm going to assume at a baseline, people have followed Richard's LMSPA example

where you kind of have you kind of have your pages in their own modules.

If that's the case, it's really about I think the upgrade path, the easiest way to go forward

is to create that one and install the you know, Ryan NHG slash elm dash SBA elm package.

So you can start exporting these page modules before you need to call them.

So if you have your init, your view and your update, you can create those wrappers, those

page dot elements, page numbers.

And then once you've done that and gotten the compiler to be happy, there's always going

to be tricky stuff, I think, because when you give people the ability to return, I'm

going to think about like the view function.

Some people handle shared updates by extending the type of message that views can send out.

Some people handle that by extending the types of updates in it and update can do so it's,

it's really a case by case basis.

But I don't know, just using that incremental philosophy that you normally do in Elm where

it's like, okay, let's just see what what I can add before I break my whole system and

trying to reduce the amount of breakage that that one thing contributes.

But it's really hard to upgrade an existing app to it to anything like that.

And like if I wanted to upgrade something on pages, I'd you know, there'd be a lot of

work and that's just inherent to the problem.

So it's much easier to just abandon all of your code, run NPX LMSPA new and get a nice

I will say with it's bug free.

I will say LMSPA is a lot easier to go in the other direction though.

So if you decide that, you know, the routing is too constrained, I, you know, I'm not getting

the like, it was nice getting started, but now I want to have full control of my routes.

Maybe you ran into the tab situation you mentioned up there you mentioned earlier.

You can just stop running LMSPA watch.

You can move those generated files into your source and it's your custom app.

The transition from LMSPA to just a core LMAP is like seamless.

You just all of a sudden it's just LM code I'm generating.

So it's, and it's stuff that you would write yourself if you had the, basically the mental

model that the framework had.

Basically you don't ever regenerate it again and take the things that were previously generated

out of gitignore or move them to your source directory.

Like that's, that's the eject workflow, right?

Unlike, you know, create react app or something like that where the eject workflow is like,

I'll give you the a web pack config and you can tweak it.

Like there's no secret file.

That was another random constraint I gave myself.

I'm like, there will be no config no matter how hard people want it.

I'm like, I just won't do it.

Cause then everyone just gets the same average framework.

That is a forcing function that forces you to get those extension points right because

it would be a lot easier to hack around that with configuration.

So I'm glad you stuck with that.

So if you hate web pack configs, you're going to love lmspa because you don't have anything

It's not even, not even close.

So everyone's going to love lmspa.

They got to, right?

That's gotta be everyone.

That one guy out there, you know, it just starts tweeting at me after this.

I love web pack configs.

It changed my life for the worst.

It changed all of our lives.

Yeah, it's true.

At least it was impactful.

These people know what it means.

At least people have heard of it.

You know, like lmspa needs to, it needs a few more stars to get there.

I think before lmspa can ruin everyone's lives.

That's my goal.

20, 20, 22 goals.

So where should people get started to learn more?

There's so the lmspa real world example is super cool.

It's so great when you, I gotta just like steal all these cool ideas from people.

So I stole that the real world example, Richard Feldman has the popular lmspa example.

Every bone in my body had to stop me from calling this thing lmspa sp example because

it's just so, it's so not funny, but I needed, I just really wanted to make the joke.

So yeah, there's, I will just fork the project.

I will do it for you.

I feel like internally that's what I called it, but I don't remember, but yeah.

So there is a real world example app.

Part of me wants to move that into the main repo just for ease of, you know, ease of discoverability

because there's really no reason that it shouldn't be there, but that's a separate repo.

I think it's called lmspa real world, which is under, you know, my GitHub Ryan and HG.

There's two ends in there.

The second is Nicholas.

You got to get those stars.

You got to get the lmspa real world stars in the lmspa repo.

I got to accumulate the stars.

That's the model repo main benefit.

It's the star accumulation.

If you like any aspects of anything I've done.

I can tell if you split your projects into multiple repos, you don't get a lot of stars.

It's actually an amazing meta.

There's also a bunch of examples on the core repo.

There's an examples folder.

You'll see it when you hit the GitHub repo.

It's designed to be easily navigable.

Is that a human word?

That's a human word.

It is a human word.

Easily navigable.

There's like docs.

The docs site is in there under the docs folder.

There's the examples, which has an ordered list of like zero, one, two, three, four,

increasing complexity.

But really I would go to lmspa.dev.

So elm dash sp.dev.

I've got guides there.

I've got examples.

Oh, you've got an Elm program test example.

That's super cool.

There's so many things I've made.

I get surprised.

Pat's rhino was good.

Pat's rhino is dope.

I wonder if I can use some more memory problems.

And of course the guide elm dash sp.dev.

It's a really nice intro.

Definitely check that out.

I have to say I really like that you made a website for the documentation this time

and not a list of videos.

I'm getting, well, it's like half and half.

Like some people are yelling at me like, where are the videos?

And some people are like, oh, I love the...

So there's no winning.

I think I need to make both, but then that just takes a bunch of time.

A part of me wants to make videos again.

Because I think there's a certain type of person that learns really well.

Like me, I learn really well from videos.

But it's important to have those accompanied with words that people can read throughout

And we got search on the website.

So it'd be very, very hype.

That's exciting.

That is a local search index that I've made up.

That's not even...

It's just a thing.

Don't worry about it.

That's awesome.

But yeah, I would definitely go there and check it out.

Just run npx elm sp anew.

It's really easy to get started.

There's three files.

You're going to feel smart and you're going to make some cool stuff.

That's what I'd say.

And at this point is like, is elm sp a v6 mostly what you're hoping it to be?

And until you get further feedback that there's something really important or that's a really

good idea, this is pretty much it?

Or is there something like that you're kind of itching to clean up or improve in some

Or where does it stand?

What do you want to break?

What should we be afraid to use?

So personally, I feel like this is the first release.

It took six of them, but this is the first release where I feel really good about the

overall architecture.

And there were so many pain points from the beginning that I had been eliminated with

And I feel like having access to the URL and the shared model everywhere, the save load,

not doing the caching stuff.

A huge driving motivation for me releasing v6 was how bad I felt about that caching problem

that I created.

For all these wonderful people using v5, the community is so kind and uplifting and encouraging.

Anytime I do anything, they're always like, hey, Ryan, you're killing it.

Thanks for all the free code you shipped.

So there's all these nice people out there that I was like, hey, cache all your data.

I felt horrible.

So I feel good about v6.

There are some tweaks, but they would be minor tweaks.

If there's anything that I'd be even remotely considering as a breaking change, it would

be adding a variant, actually, to the protected stuff.

But I'm not convinced that's going to solve problems.

So I'm not sure if that's going to be released.

Would that be a breaking change?

It would be because there's a case expression.

It would be an incredibly easy breaking change to fix because you'd have one line of code

that you'd have to add saying, in this case, do x.

Wait, did you expose that custom type?

I definitely did.

Or maybe I didn't.

Maybe I'm a good guy.

Oh, wait, hold on.

I'm going to take a peek.

Maybe I'm a genius.

That's why you don't expose custom types.

Oh, I totally exposed the custom type, man.

You didn't do the lower case.

I needed it because the generated code needed to switch off of it.

It's not my fault.

That's another tricky thing with meta frameworks in Elm.

People don't know the pain.

They don't know the struggle.

And hopefully they never have to.

We'll take the pain.

But we'll also take the stars.

So don't forget.

We'll gladly take the stars.

We accept GitHub stars as currency.

It's actually funny how much we care about not introducing breaking changes or about

not introducing a major version.

I have some breaking changes planned for Elm review that have been...

Yeah, I've got some functions that are deprecated for a year now already.

And I just don't want to break anything for people.

But I really respect the rich hickey mindset of if you don't like break your code, just

give it a different name.

So, for example, it doesn't have to be a break and change.

What I did with the auth thing, I could just say, hey, if you want to use the new thing,

expose a different function with a different name that returns this new type.

And all of a sudden, no one's angry.

So if I go that route, I don't want a version bump.

The Elm package is 6.0.0.

That's so pretty.

If I make that 7 and then it's Elm SPV 6, I'm going to be the saddest man in America.

You should release a new package, a new tool called Elm SPA 7.

That's just the name, but it's V1 and then it won't be a breaking change.

That sounds like the opposite of what Microsoft did with their consoles.

We're going to call the new one, the first one, Xbox One, everyone.

Buy them today.

Yeah, that's an idea.

This was so fun having you on, Ryan, to walk us through these changes and kind of your

thinking on these topics.

But thanks again so much for coming on.

I still have one question that I really need to ask.

If you didn't have the other package taken, the other package name taken, would you switch

between Elm pages and Elm SPA?

Like who would have the right to Elm SPA and who would have the right to Elm pages?

Okay, to the death.

I think there'd have to be negotiations in place.

Mine does have a lot to do with pages.

SPA is a horrible name.

It's not even accurate.

It sounds like SPA, which it isn't.

It is refreshing.

There are no cucumbers.

A single page app.

Well, so here's what it is.

A single page app is just an app that has multiple pages.

Yeah, it's like inherently a bad name.

But when people are looking for how to do single page apps, I'm like, okay, maybe that's

the right thing for them to Google.

Yeah, I'm glad Dillon had Elm pages.

So it was an easy decision to not use that, I guess.

So you would go for Elm pages?

I would have to choose, which would be tricky.

I mean, there's no real conflict.

It's a Ryan Elm pages, Dillon Elm pages, choose your favorite.

You could do Ryan Elm pages.

There's so much confusion already.

It's like, what do I use Elm pages for?

I'm like, this stuff.

If they're both the same name, that would just be cruel.

What about you Dillon?

I actually think Elm SPA is such a commonly used term SPA for describing how do I do X

X is SPA, right?

It's not pages.

So I think it's perfectly named.

And then we both get to have our own unique package name.

So you're saying Elm pages is the best name?

Elm pages is the best name.

Thank you Dillon.

Elm pages is good.

I'm on team Dillon for this one.

Ryan, you could do Elm pages under your name, V1.

And then it would look like I never made a mistake.

That would be good.

V6 shows like what happened.

It's like, you think you get it and then you think you get it and then you really think

you get it and then you didn't get it and then you thought you got it and then you nailed

So that's where we're at here with V6.

I think that's our intro cut right there.

That would be epic.

Well, thanks again, Ryan.

So if people want to keep up with what's going on with Elm SPA, with you, we haven't mentioned,

but you work at Blissfully.

If people want to find out more about Blissfully, where do they go to find all that?

So Blissfully, you go to blissfully.com.

That's the job I work at.

I get to work with Matt Griffith, the guy that made Elm UI.

So come through.

Wonderful, wonderful people there.

Are hiring Elm developers too?

Hiring yeah, we've got back end developers particularly, but yeah, we're definitely hiring

developers in general.

Yeah, if you, yeah, we've got an office in New York.

A lot of folks work remote.

So don't be afraid if you don't live in New York to apply.

But yeah, you can get a hold of me.

I guess the only thing I'm on is Twitter and I just unfollowed everything because I just

gave up on social media completely.

I only follow Elm just because I thought that would be cute, you know, just to have the

one, I saw like Jon Stewart's following like Arby's and I'm like, I need that with Elm.

Just the one following.

But yeah, you can follow me there if I ever share any social media updates that will be

I will not be posting gifs of like puppies or anything.

But yeah, elm dash sp dot dev is the number one place to go.

Check out the GitHub repo if you like it.

The Elm SPA Slack channel as well.

That's your social media.

That's my social media.

And if you're using Elm SPA, we do have a channel in the Elm, the official Elm Slack.

Elm dash SPA dash users.

And one day we'll be official enough just to be Elm SPA because there'll be no confusion.

It'll be the Elm pages channel.

Well, thanks so much Ryan and Jeroen.

Until next time.

Until next time.