Elm Store Pattern

Elm Store Pattern

Martin Janiczek joins us to discuss a pattern for declaratively managing loading state for API data across page changes.

PublishedJune 6, 2022

Episode#58

Martin Janiczek (github) (twitter) (youtube)
Martin's Store Pattern talk
Store Pattern example GitHub repo
Gizra fetch pattern blog post elm-fetch, and Easier HTTP Requests to Reason with
Gizra elm-fetch package
RemoteData package
RemoteData blog post How Elm Slays a UI Antipattern
elm-program-test is useful for integration testing data loading
elm-suspense proof-of-concept repo
Okay to use Store pattern for mutations, just kick them off outside of dataRequests
Defunctionalization
Wrap early, unwrap late
Derive from source of truth instead of storing derived data

Transcript

And today we're joined by another guest and indeed another Martin.

Martin Janacek is joining us.

Martin, welcome and thanks for coming on.

Glad to be here.

Yeah, we're really glad to have you.

And today we are talking about the store pattern.

You gave a talk recently about the store pattern and definitely worth watching the talk.

It's a really fun topic.

You want to introduce what is the store pattern?

So the store pattern is basically, I'm just popularizing something that I saw in a codebase

that I worked on at a previous company.

And I think it's a really nice way to structure things.

And I haven't seen it done in other places.

So yeah, I thought it would be nice to share some kind of like golden nuggets that we have

And yeah, so it definitely isn't my original idea.

And I believe there's even prior art by the company Gizrara.

There are some blog posts about a fetch pattern, which I believe is very similar to this.

Although maybe we are diverging at some points.

But yeah, I think it's a pretty good indicator that we have stumbled upon something nice

when two unrelated developers have found a similar pattern.

So what it is, is store is just a record of data that you have received from a server,

from some kind of HTTP call.

So it is mostly a convention where instead of each page having its own requests and holding

pieces of the data and passing them to child view modules and so on, the data all lives

at the same place.

And then instead of using API commands, like HTTP request commands, you have a message

type or message like type.

You have a custom type where you can say fetch users, fetch posts, fetch details for a single

user and so on.

And this custom type, I call it the functionalization into, let's say a request type.

It unlocks some very nice things for both developer experience and for the user experience.

So like for example, if you are on a page listing out users and you click to a page

that's the detail view for a user, if there's maybe like there's a certain type of data

that is for listing users, there's a certain type of data that is the detail user view

which might have additional data.

So your store would be like a global type for all of that, like a record with all of

the possible data that could be consumed in your entire application.

So you'd have a record which would have users is a web data, remote data of a list of users.

And then you would have maybe a dict of user ID to web data of user detail.

And so you mentioned the developer experience and the user experience.

From the user experience side, since you have it as a global store across the application,

when you're on the user listing page, you might have a spinner saying I'm loading data

You click to a user, you have a spinner that says I'm loading the data for this specific

user's details.

When you go back, there's not a loading spinner because you have that data already.

Yes, it encourages data reuse.

So instead of when you're changing between routes or pages, instead of dropping all the

data that could be, let's say, in the model of that page, you have it somewhere top level

and it outlives the page.

So then you can change between pages and the data stays loaded.

And other pages, if they need access to the same data, they don't need to load it themselves.

They can just reach into the store and it's already there.

Or perhaps they are the first ones to load it.

They will load it, but then it's free for all the other pages to read it.

And when you say they don't need to load it themselves, they need to declare that they

depend on that by saying, if it's not there, I need it to be there.

But they do that declaratively.

And then the store can figure out whether if it has it, then it doesn't need to do anything.

If it doesn't have it, then it says, oh, this page that is loaded depended on that data.

I don't have it yet.

I need to start fetching it.

So as you said, each page declares what data it needs, but it doesn't really care whether

it's loaded already or not.

It just says, I need the list of all users and I need the full details of this particular

user and the store and the main module handle that behind the scenes.

Basically the main module, whenever you change a route, it will run that function.

It will decide, okay, we need to run all these requests, but we can skip some of these because

they are already loaded.

And so this happens whenever route changes or whenever the store changes, because there

can be, let's say second order data dependencies.

You might load the user and then figure out, oh, there are some other entities related

to it that I need to load for this page.

So on the first run, the route data dependencies function might tell you, I need just this

But on the second run, when the user is loaded, it might tell you, I need this user and then

I need these three images, let's say.

So the way that you declare what dependencies you have is using a, I guess by convention,

a data requests function or constant, which is kind of like a subscription, right?

You declare based on this model or based on just constant, these are the things that I

It looks very similar and feels very similar to the subscriptions function.

And in my experience, it doesn't depend so much on the model as on the route itself and

on the store, on the contents of the store.

But yeah, definitely, I think if you, let's say paginate the list, you might have the

current page in the model.

And so this function would then depend on the model too.

And as you said, sometimes some pages are just so simple that this data requests function

is just a constant because it just doesn't depend on anything to decide what it needs.

So in a lot of Elm applications you have, or a lot of pages, you have init, you have

update, you have view subscriptions.

Here you would add data requests.

Also sometimes we see these same patterns in non pages.

We see them in smaller modules for components in a way.

Would you think that this would be applicable as well?

Would you have a data request in a sub element that is not a page?

Yeah, I believe that would be doable.

There's nothing wrong with it, I feel.

Although I have tended to just let the page declare all these things and kind of magically

know about what the components need.

But yeah, it might be a little bit unsafe.

Definitely you could have the data requests function also in small components and let

them know about the store also.

So usually I have just reached into the store from the page and given the components the

data that it needs instead of the whole store.

But yeah, you could definitely do it.

There's nothing wrong with that.

Yeah, I mean there definitely is a trade off of convenience of being able to perform commands

from somewhere, being able to change the model from somewhere, being able to have implicit

state that is sort of sub component style thing has an Elm.

But then there's also the traceability and being able to follow where does a change come

from, where can a change happen and the wiring of wiring up new things.

So in Elm it seems to work pretty naturally when you have more top level sort of controller

style things that are, hey, I've got the data you need and I pass it down to more sort of

dumb helper functions.

That was one of the things I was wondering about is like how do you differentiate between

when it's a good idea to create these abstractions that have these sort of Elm style hooks that

have like a store has and a knit and an update and a piece of it that stays in the model

and it's responding to these sort of actions that you call them, these messages that it

You could imagine going too far with this where you turn all of your logic into these

many componentized things that have everything but the view and they all are able to manage

their own data.

How do you know that you haven't gone too far with those things?

How do you decide if it's a good idea to create these abstractions?

Yeah, that's a tough balance and I think it's tough to somehow condense into simpler rule.

But for the store pattern, it feels like it does a lot of logic.

So there is the checking whether something should be loaded or whether we don't need

to because it already is or the request is in flight.

There are somehow naturally there are these two message like types.

There's the data request and then there are the responses and the model is already there

by virtue of being this record of the data.

So it kind of fell into that let's say component style automatically.

So it has all of these, it has update, it has in it, it has a second update let's say

for the other message type.

So it felt right.

I think if you try to apply this pattern a lot, let's say in view components and so on,

the pain will tell you.

So there is a certain amount of boilerplate that you need to write for all of these.

And at least for me, I have written a few of these and then I have written a stateless

view component that just gets data and render something and the model of the parent page

handles all the state changes and it's just so much nicer.

So I think it's a balance that everybody needs to find for themselves.

And I remember taking a few parts of a big application and creating those components

out of those because they just felt like almost separate pages although they all lived at

the same place.

And at that point, it felt like I was gaining something.

I was gaining some componentization.

I put these things into little boxes so there was like detail and list and edit.

Although they weren't like pages, there were more like let's say models or just different

states of the page.

It felt like I was gaining some clarity.

So although you can have a lot in one Elm file and it's generally okay to have just

like 4,000 lines of code of Elm, sometimes when it feels like you would gain something,

But I wouldn't do it prematurely.

I would rather err on the side of having a lot of things at one place instead of having

tens of little components that I need to wire into my main page.

Try it out but try also to feel the pain of using it and writing it and then come up with

a better solution if there is too much pain.

In my experience, extracting something around a type and functions for managing that type

and encapsulating parts of it so you can have a private part of the interface, there's a

pretty low cost to that.

But when it's wiring in and it's an update and these things, that's a huge cost and that

should be done very sparingly.

I do wonder like is it just that the user experience pushes us to this by necessity,

Like with this store pattern, you're talking about the user experience it enables, not

just the developer experience.

How would you achieve that same user experience without extracting something like this that

has some sense of globally maintaining the state of all possible requests so you can

share them across without needing to throw away the data when you go to a new page?

I can only guess at what led the original developer to create this pattern in the code

that I have first seen it in.

But I imagine there was some kind of pain involved and they just solved it by creating

Yeah, I think letting the user experience guide some of these abstractions is a really

good idea to say, we don't want a loading spinner when we go back to this page.

Maybe that workflow is happening frequently that you're going back to the main index page

and it's not updated frequently and you want to manage that.

So letting the user experience guide it there, it seems like a very good strategy.

So in terms of the user experience, I think that there are many different ways you could

And I know that like your experience with it has made certain user experience decisions,

but maybe we can dig in a little bit to what kinds of user experiences could this support.

I'm thinking in particular of things like stale data, like how to manage stale data,

how to manage reloading states, and also how to manage maybe purging parts of data if you

send a post request where you're updating something and you know something is going

to change and doing like targeted purges or targeted reloads.

So for the reloading case or let's say for the stale data, I imagine that this problem

would disappear completely with something like GraphQL subscriptions, right?

And this store pattern, I have only used it with REST APIs where the client initializes

the, where the client requests the data and gets bulk of data back and doesn't get automatic

updates, right?

What is a GraphQL subscription?

It uses WebSockets under the hood.

I mean, it can use long polling as well, but it's like GraphQL has the concept of saying

you want to select data for a query.

You want to select data that represents a mutation.

So you say, go and create this user and give me back the data, including I want the new

user ID you created.

And then there's a third type of thing you can do in GraphQL, which is a subscription,

which is like a query, but it's a query that it will keep resending that data you selected

like in a query, but it'll send it anytime it changes.

So you could use that to build like a real time chat application, things like that.

And usually it does it over WebSockets.

So yeah, you can have an always up to date list of users because the server is listening

and it says, oh, a new user was just added.

A new thing was just updated and then resends the data.

So it's never, never stale.

So with the applications that I've worked on, it was fine to generally assume that nobody

else tempers with your data, but it is very application specific, right?

There are different applications with different data access patterns.

And so for me, it was fine to just assume I have the data I have is always up to date,

but there were some, let's say flow patterns where in one part of the page I created an

entity and then I needed to go to a separate page.

And if you do that, you do have the newest part of the, you do have the newest version

But we found that there are users that have two tabs open that have two browser tabs open

next to each other.

And they created the entity on the left one in the left one.

And then they were surprised, why doesn't it show up in this other page?

I just created it.

So we, at the time, instead of doing some kind of tab to tab communication, instead

we just gave them a refresh button.

And so they learned that they can click the refresh button.

It would basically throw away the old data.

It would load it again and they were happy.

So it was kind of a low cost solution with some manual user effort, but it did the job.

So with the store pattern, you can, you still have all the control over your data, right?

It doesn't lock you out of working with the record, working with the dictionary and so

It is just a common place to put things in.

It is commonplace to look at, okay, if I need the data, it will likely be in the store.

So when you say you throw it out, the data to refresh it, you actually set it to an empty

list or you remove the data from the store and then the data requests kick in again automatically.

So instead, I believe we didn't really clear the data.

We didn't override it with not asked, let's say the not asked constructor.

Although that would have worked.

It would kick in automatically, but we just sent the request again without looking at

whether the data is already loaded.

And then the message that deals with the successful response, it also doesn't check whether the

data is already there.

So it just overrides it on its own.

So the user saw the data and they didn't see a spinner that might be possible improvement

where we would have a different remote data constructor that has loading, but also the

data we could actually reload.

But what we did was just have the refresh button send the command again or send a special

command that doesn't check whether the data is loaded.

And it would, when the response would come back, it would just override it and they would

see their new entity in there.

I love this recurring theme in this conversation that I think is one of those things that you

can always safely say, which is let the user experience guide your data modeling.

In one sense, it's the kind of thing when a consultant says it depends.

It's like, all right.

But it's also the most honest answer.

There's no one size fits all approach to your data loading patterns.

It really does depend on how, like, is stale data a problem or is it acceptable?

Is it okay for the user to click on something to reload?

Does the user need to know that data is being refreshed?

That's going to inform what your data modeling looks like as well.

I'm just stuck on the fact that you basically said that consultants are not honest.

No, they're like, when they're honest, it's boring.

Because they say, give me an answer.

And they say, well, I can't give you an answer because it depends.

Like the answer is, well, it depends on these things and these trade offs and which ones

do you want to make and these are some options.

Sometimes the honest thing is you can't just say, this is the way to do it.

I find this is true also in in house applications and in house developer teams.

We always throw around different ideas and like, if you want, we can make it do this

thing and this thing.

But you as the product manager, you have to really tell us what do you want.

And when we know how it should behave, then we can say, okay, let's say we need a new

remote data constructor that allows, let's say, canceling requests.

Or if you absolutely cannot put things on the screen that are stale without showing

that they're updating.

You could imagine an application where that's very important.

Someone's bank account.

Maybe you're like, don't show stale data.

We would rather have a loading spinner than stale data in that use case.

But if it's like social media posts and it's like, this isn't the latest version of the

You want to get those things in front of the user as fast as possible and you don't want

them to be looking at loading spinners because then they're going to switch over to do some

other more productive thing with their life.

I'm sure that in the store itself, you can make it so that it automatically refreshes

some of the data.

I think you could do that because you have the full power of the update function.

So you can return commands and so you can do this kind of timer with commands or you

could even have the store have subscriptions.

So definitely possible.

It's not something I have tried, but you definitely could have just, you know, after five minutes,

just refresh it just to be sure.

And then also like, I mean, yeah, that is kind of the cool thing about this pattern

is that it's a pattern.

It's not a library.

You can choose not to use it for some of the purposes.

And you could customize it to your needs entirely.

So you could have like your store, you could give it some state that anytime a page changes,

you could say I'm on a new page and you could use that state to see has the page changed

since the last time the store was refreshed to do any new requests.

And then you could have some store actions where you say, all right, if I've gone to

a new page, then this store action, if it's the first time performing this store action

since a page change, I want to reload data to make sure it's not stale.

So like really it's up to you.

And that's one of the cool, cool things.

It's just a more general pattern of, I think having sort of application context, right?

It's kind of a special case of this application context pattern, which more and more, I think

it's quite a nice pattern in Elm actually having some application context that is not

managed by every single page.

It is basically just a thing that you pass from the level to the pages as they need it.

So there might be pages that don't have the store, there might be pages that only need,

let's say a specific record of the store.

It's just data, right?

It's just something that the top level model has, but not all the pages.

And to clarify what these data requests are doing, for every page in your application,

you're defining these data requests, which can give back a list of actions, which is

just a custom type.

It's similar to an effect type and it represents go get the list of users, go get the specific

data for this user ID, just a custom type that the store can receive and decide to go

fetch data and then insert it into this record.

And that data requests function receives the store.

So it can depend on pending requests and check if this is pending, I can't tell you what

to get yet because I need to know something from this user record which hasn't loaded

yet in order to tell you which list of friends to go get or whatever.

So you can depend on pending data because it calls data requests every time the store

Yeah, and you can even go a step further and you can just conditionally not return something

because you can't get at the data, right?

It's not successfully loaded yet.

So you just return a list with less items.

And whenever something happens to the store, the function will get called again.

So you don't really have to indicate in any kind of way that I haven't told you the whole

You can just say, hey, for now, I need this.

And if you ask me later, maybe I will need more things.

But it's just a function from the store and the route and whatever into a list of requests.

Right, that's the declarative part.

It's kind of idempotent because if basically if you say I need to go get the list of users,

that's the store action that you are returning in your data requests.

If the web data variant is loading, then it says I'm already loading that.

If the variant it has for that for the users in that store record is not asked, then it

says, oh, I need to go do this.

If it's loaded, if it's success, then it says, oh, I already have this.

So it's idempotent.

You can declaratively just say what you depend on because it's not performing anything.

And that's actually where the defunctionalization part comes in, that it's these effects as

data because you're not doing it.

You're describing what you need declaratively.

Yeah, you are just giving it a recipe and it is going to the store for you.

That's a nice one.

I'm proud of myself.

Also to illustrate this a little bit more, you just get the store in your view function.

So if you say store.users, you have to do a web data to say case success or whatever,

show loading spinner.

If you don't return the action that is going to tell it it depends on users in that page

and it hasn't been loaded, then you're going to get an infinite spinner because you haven't

declared those dependencies.

Yeah, you might also, it depends on what you want to render for the different remote data

So for example, I usually show the spinner just for the loading case.

But then what do you show for the not asked case?

You might show nothing like text and empty string, but then it's kind of hard to figure

out that something is wrong.

The user doesn't really see that anything's happening, but also no data is showing up.

So yeah, it's kind of you need to find these cases when developing the page, right?

So you need to figure out, oh, I depend on users, but I haven't declared that I need

So if somebody doesn't go to this page from the homepage, let's say, or via some flow,

if they go to my URL straight away, they are not going to get the data.

And so the store doesn't really have a way of checking that for you.

And while it isn't really a problem in practice, because usually you just figure it out and

you hit this issue during development, I think it would be nice to have integration tests

So the integration test doesn't really care about any in it or data requests or anything,

but the integration test just says, go to this URL and expect that you will see some

loaded data on the page or that some requests have been made.

And with Elm spec or with Elm program test, I think that's very doable.

So it might be like a sister best practice next to this store by them.

That's a great point.

Yeah, because I imagine you do get into this situation where you, because you have global

application state that's shared between pages for all of your web request data, you could

get into a state that's different if you do an initial fresh page load versus navigate

from another page, because you might be depending on data that another page said it depended

And I'm thinking, I'm wondering whether we could have some kind of Elm review rule to

catch those like store accessors and say, Oh, you are using store.users, but I don't

see get users in your data requests function.

So that might be something to explore.

My mind was going to like a, almost like a decoder style or something where your helper

for accessing things from the store.

Like if you say like store.end map to build up getting data from the store, and then that

store value would not only have the web data for whether it's a loading thing or a success

thing, but it would also have the recipe for knowing how to go and request itself.

And so you say, you know, you could do store.map five with the things you need and you reuse

that same thing to say, here's the data to load.

And here's how I turn my data into something that I receive on the page.

Are you thinking of data sources from Elm pages?

Just any sort of like a GraphQL selection sets, it's like the same idea, right?

In GraphQL, a selection set represents both here's the data to get, and here's how I turned

that into my Elm data type, the decoder part.

That's interesting to think about.

I believe it could work if your only accesses would be from the update function or let's

say from init or wherever where you can send those commands to then, you know, load the

data, but I'm not really sure how that works in Vue because you can try to reach for a

data in Vue, but you have no way of signaling, okay, I need you to load this, right?

You could try and decode it, but then it would not initiate the actual fetching of the data

if you only have it in the Vue.

You would either need to be sure that you reuse that definition of like your sort of

store decoder, which you could do by having a constructor for your like page that takes

the record of your Vue and init and your, you know, store decoder.

That would be one approach or you could have, or you could potentially have your Vue return

something besides just an HTML document or whatever.

Or your Vue return data that it depends on, but that gets a little bit weird.

And also probably a bit wasteful in like you would compute the view in the update, I'm

guessing or something like that.

I haven't thought that design through enough to know if it's a good idea or not, but I

do believe if somehow or other you can share this thing that tells you that the store decoder,

then it would work and I believe there are several good possible ways to do that.

I don't know if the Vue one is one of the good possible ways, but there are good possible

That's exciting.

That calls for some kind of experiment.

I'm sure they will not sidetrack you from other projects.

That's not possible.

I have no side projects.

Well, the cool thing is again that it is a pattern and so it can be explored.

People can explore this by like create it.

You've got an example repo that is a really cool way to sort of look at this pattern in

a more concrete way.

I definitely recommend taking a look at.

The talk is also a really good introduction to those ideas.

People can build their own patterns and write a blog post on a particular permutation of

the store pattern.

I'm pretty sure people are already doing some version of this.

Just that nobody is talking about it and I guess the COVID season didn't really help

with no L conferences being around.

Perhaps we would have heard about it from somebody else already.

I've worked with code bases that use this pattern as well actually.

That's definitely out there in the wild.

I mean you've got to imagine like people building production album applications, some use cases

it's going to be important to like persist some data between page changes instead of

throwing it away.

So it's natural.

So because this is a pattern that you can customize, I feel like it's pretty useful

to build it over and over again in each project.

Would you like to see this in a library?

Would you like to see someone publishes this package or does that feel not useful to you?

I haven't thought about it.

I think you would need to either your library would only solve your particular problem set.

So you would need let's say to show a spinner for reloading stale data but somebody else

So I think either the library would be too narrow in its use cases or you would need

to somehow figure out what are the different use cases that people can have.

What are the different variations of this pattern and then perhaps have some kind of

custom type for customizing this.

I haven't tried doing this.

So it might be possible.

It might be nice to somehow let people easily use this but I think there's value in having

this in your code base and being able to just tinker around with it as your requirements

So yeah I haven't felt the need to make a library out of it even though I have implemented

it in a few applications already.

I think it is just a pattern.

Hopefully there isn't enough in it to be a library.

I mean you can do a library for very tiny things.

Yeah but you can't extend it then.

I think like I remember Richard making a point in a talk once about like you know the example

he used was the HTTP builder package and he said the HTTP builder package is a very nice

little package but you know what's nicer is having some logic that knows the particular

endpoints to hit in your domain that it can have that knowledge abstracted in a high level

nice way and it knows particular types of headers.

So instead of like HTTP builder dot with header well you know what's nicer than with header

is you know with user session and with whatever specific types of headers your application

So his point was sort of like we don't always need to have a package published for a specific

thing custom tailoring them in Elm is so nice and relatively easy and so sometimes these

things are better as blog posts and example repos that illustrate the pattern than packages.

I think this is maybe one of those cases.

I even I think I have tried this once not with HTTP builder but just with the HTTP library

where I was tired of always calling it with tracker equals nothing timeout equals nothing

and so on and so I just created tiny little abstraction where instead of that I need to

give it JWT token and it does the header automatically right and these little things it's not that

much of a code but it makes your life so much nicer and it's very tailored to the application.

It also removes a lot of common mistakes that you can do but just by forgetting to add the

authentication header in one of the calls.

So yeah a lot of nice developer experience improvements.

And sometimes like giving these patterns a name and giving people example repos gives

them something to latch on to so they say oh you know this is what I need to improve

It does seem like this store pattern it does make me think like it's the sort of cookie

cutter wiring that LMSPA tries to solve and I wonder if like it would make sense to support

something like that in LMSPA or to support a more general concept of like application

Like the shared model so I guess maybe with LMSPA you could already do that but I'm not

sure if you could accomplish the task of automatically wiring in the sort of data requests part from

So that's an interesting thing to think about.

Sounds interesting.

I don't have many experiences with LMSPA to be honest but if you have the shared model

that seems like it would support it if you also have a way to then process the shared

I have worked mostly with GraphQL in the past two years and with Elm GraphQL.

With GraphQL you usually only request what you need but this store pattern makes me think

that you are nudged towards loading everything that any page can use potentially asking for

way more than necessary when you make your HTTP requests.

So the store pattern, the store will only ask for the requests on the current page,

So if you are on the homepage and it asks for one specific thing and there are different

pages that ask for different things and if you stay on the homepage it will never ask

for the other stuff.

So yeah I meant for instance page A wants to know this information from a user, page

B wants different information from a user.

So if you have the same users field in the store then both pages will load the same data

but only use parts of it.

Oh yeah I understand.

Yeah this is probably for discussion with your backend team because the store pattern

pretty closely follows the API requests, right?

So if the only way to get data A and data B for the same user is to get the full details

then the store has no other way to do that, right?

But if there are separate endpoints for getting let's say get user friends and get user images

then you could have two different fields in the store where all the data would be lazy

loaded and page A wouldn't need to ask for data that only page B cares about.

So yeah I think with GraphQL it's definitely better in that you can be very granular but

the store pattern in itself doesn't really dictate how your request should look.

It just follows what the API are giving you.

I feel like it doesn't say how the request should look but I think it dictates how the

data should look in your store.

So in that sense if a user is defined to be a record with a name and a list of images

and a list of friends then you need to fetch all of those.

And I feel like even if you use GraphQL I'm not sure how you would model that.

Or the fact that sometimes you want the list of friends and sometimes you don't want the

list of images.

I think you would just have different types with different responses.

So the user friends response could be user ID and friend IDs.

And the other one would be a different record and then the store would hold let's say dictionary

of user ID to web data of user friends.

And the other field would hold again dictionary from user IDs to web data of user images.

So I think it doesn't really dictate that.

You can definitely be as granular as you want but you will need to follow what the API is

able to give you.

It would be interesting to combine this pattern too with GraphQL.

You could imagine getting pretty clever with combining requests to say well I need these

three different things which I have selection sets for.

Let me merge that selection set and run the same decoder against them.

Let me intelligently combine these three selection sets together so I can perform them at once.

I think that's very doable if you can combine different selection sets together.

You can just convert each request from the store to a selection set and then just list

fold them together.

I think that's a reasonable optimization and I think the store pattern is compatible with

GraphQL although I haven't tried.

The one thing that seems like it would get a little bit awkward is the relations because

like I always say GraphQL has two parts, the query language part, QL and the graph part.

And the graph part is very different than what we're used to in most REST APIs where

we're sort of usually getting lists of IDs and then making a follow up request to get

And the way you talk about the store pattern and the demo you gave in your talk, it's pretty

natural to have a dictionary of IDs to web data of user or some sort of thing you're

loading selectively where you go to a user's profile page and you load that one user.

While with GraphQL it tends to be more natural to describe those relationships as a single

request rather than independent things that you kick off and store independently.

That's the one thing I can imagine getting a little bit awkward where it seems to fit

pretty natural with that REST style pattern and then storing things selectively.

I think I see what you are saying.

So GraphQL does support what the store requests want, but GraphQL does much more, right?

You can describe what you will want, what you want in one go, but the store has no way

The store has no way of saying, I want the user and then whatever images he has, I want

So the store needs to go in two passes, but GraphQL could have done it in one pass.

And the store is in a sense optimized to be able to do that more granularly, whereas GraphQL

is more optimized to do it less granularly and say, this is exactly the data I need right

now, go and get it.

So they're a little bit tugging in different directions somewhat.

If the data requests describes what you want the store to load, then surely you can describe

it in a GraphQL way.

Just translate that to a GraphQL request saying, Hey, I want the users and their images.

Like you could probably do that, right?

You could have a special custom type constructor that says this and then interpret it in that

Yeah, definitely.

That'd be a cool experiment.

I would love to see a little fork of Martin's repo for the store pattern to illustrate what

it would look like with GraphQL and if it would work well with things like relations,

that would be really interesting.

And exercise for the listener.

If the listener does it before we release this episode, then we can add it to the show.

Wait, there's always Twitter.

We can ask him on Twitter.

One thing that I'm curious about is how do you pass the store around in practice to all

the view functions?

Do you pass in the store or do you pass in extensible records saying I want these fields

from the store or as separate arguments, I want the images and I want the friends.

What do you do?

I believe all of these would work.

And thinking about the classic Richard's talk where he says about like extensible records

are basically only nice in this view use case.

I think that would be a good idea.

Although I tend to skip extensible records.

So the main gives the store to the pages and then in the pages, it's not as clear as to

whether the page still gives the whole store to some kind of view sub function or whether

it just gives them a specific dictionary, let's say.

And I want to know what you did in practice.

So the innermost children usually receive just a specific dictionary or web data, but

it might have been nicer if store was just passed everywhere and the functions were to

limit what they can take from it with extensible records.

I think it's viable.

I feel like the decoder style would be the best of both worlds there where you say what

you depend on in a way that you eliminate this type of out of sync error where the data

dependencies cannot get out of sync with the data that you actually depend on in the view.

And you don't just have this unconstrained store where you have all these things, but

you don't know if you depend on them or not.

You have exactly what you depended on in the view.

If you need to depend on a new thing, you don't need to go fuss with extensible records

and have the issues where the extensible record gets out of sync with the main definition

of the record, which is pretty painful, right?

But you own the record of your type alias for the decoded thing of the data you depend

on for your page.

Maybe it's time for Elm revolution and where we start to make the views a little bit smarter.

Because I think right now we tend to make the view just return HTML and it's idempotent,

it's stateless, just convert the model to some data.

But perhaps there are nice things to be found if we let the view return a bit more or if

we build some kind of little abstraction on top of HTML that actually tracks what data

It's very interesting to think about.

I have no idea where that would lead.

You are probably the person with the most experience with this, Dillon, for Elm pages.

I like this tangent.

This is a very interesting tangent.

There's an interesting, highly experimental repo.

It's not in a stable state.

It's a proof of concept.

But there's a project called Elm Suspense.

It is an interesting exploration for essentially like...

Don't tell us what it is.

Leave the suspense.

Suspense achieved.

Now you can go.

Well, React had the ultimate suspense with leaving people in suspense for years.

Until they finally released Suspense.

Their users didn't know how to react.

So what is Elm Suspense about?

I'm not really curious.

It has a more powerful view concept, kind of like what you're talking about, this revolution

where the view can sort of describe what it depends on and you can kind of get these loading

states until the data is retrieved.

So that's a really interesting example.

Of course, I've been thinking about this in a somewhat different way with Elm pages where

you have this abstraction of a data source, which allows you to sort of declaratively

say, I depend on this data.

And it's not this imperative thing where you wire up messages and say, when I get this

And the most exciting thing to me about it is that you don't have intermediary states

that you have to manage.

So you don't have to do loading spinners.

And you don't have to manage those loading spinner states in your view.

The reason is because you move the loading state to the server because the server goes

and you say, I have this cookie that gives me the user's session ID.

I'm going to go look up that session ID from the database.

I'm going to go get the user's data.

I'm going to go get the specific data I need to load this page.

Now I've got all the data.

Now I return an HTML response with the data to hydrate the Elm application.

So there's no loading state in your Elm application because the loading state is just the server

building up the response to return.

So that's another interesting kind of revolution in how we can approach managing data in an

Elm application.

Maybe in some cases, it doesn't allow you to do this sort of fine grained control where

you can avoid doing data fetching between page loads.

So you go to a new page, you get new data.

The Elm pages 3.0 answer to that question would be more, well, have really good caching

on your server so that that's not a problem.

In some use cases, maybe that's not a good answer.

But I think that's another interesting avenue to explore that I think is pretty exciting.

Yeah, that's nice.

So should we try to develop a Elm pages store or an Elm library?

Well, I mean, it kind of is a built in store in a way, you know, it's I mean, it has this

data layer built into it.

And it's a more declarative data layer.

But yeah, the data store is an interesting idea.

The this sort of suspense concept of having view like smarter view functions is very interesting.

Another thing I've been exploring with Elm pages is the sort of optimistic UI for states

where you're fetching things.

So if you're if you're creating a to do list item, Elm pages 3.0 has has a way to sort

of see that pending form post as you're doing it so you can so that can show up in an optimistic

But that's another area I was wondering about Martin is, do you have any thoughts on pending

mutations, things that change the server and how that could like purge parts of the store

and how that pending UI could be displayed in the UI and be included in the store?

Yeah, definitely.

I believe you can mostly do optimistic updates with the store pattern.

So in the store, you would insert into the dictionary at the same time as you send the

command to create the data right to create the entity.

And in that way, in that way, you would see it automatically created.

But there can be some it can sometimes be tricky if you need an ID for the new entity.

And so what would you what would you put there as a placeholder?

So I think this could be doable.

It's definitely a solvable problem.

You could have another field in the store where there are like users being created or

something and the view could check both.

You could check the main field primarily.

And then if it doesn't find the user there, it could check the users in flight, let's

And so you could show user even if they don't have an ID yet.

So I believe it's doable.

And again, it depends on what your application needs.

We are coming back to that to that sentence.

So yeah, you would just basically again, because it's your application code and you have full

control over the store, you can reach into the interpretation of that message.

So you can you have full control over how it will send the command, whether it will

check for data that's already there.

You can say it would let's say if it wasn't a get command, but it was a delete command,

you could just delete the dictionary key right there.

And then in the failure case, you could bring it back, right?

Because you still have all the data.

So it depends on whether that's worth it and whether your application needs that kind of

But I can see it being supported by the store command.

Again, it's not that much.

The store command is not that much about telling you how to do stuff.

The store command is really just where the data lives.

So it can do all the things that you could have done without it.

I'm now imagining a store where one of the data requests is deleting something.

So does it sound like a very good idea?

So get commands would probably not want to delete something.

But again, the custom type in your store with the data requests, it doesn't have to be only

for getting stuff.

It is more about what the API can do.

And so you can have get users and get a specific user, but you can also have create a user,

you can have delete user, update user, and these all live in the same kind of type.

And you just don't really use those in data request function.

But you definitely can use them from within update of these pages, right?

Oh, that's a cool distinction.

I hadn't put my finger on that.

But that makes sense.

I think what Jeroen is sort of hinting at with the anxiety around using store for this

is like, if you're like, delete user, and then is it going to keep trying to delete

or is it going to keep trying to create something and somehow the state gets cleared out to

a not added state and it keeps creating?

I think for extra safety, you could split this type into like get requests and mutations,

let's say, right?

Queries and mutations.

We are ever so closer to GraphQL now.

Yeah, very interesting.

But at the same time, like, what I'm hearing is that there's value to still using the store,

not necessarily the data request part of the store where you say, hey, if I'm on this page,

this is the data I'm going to need.

But having it be able to interact with the store model where it can kick off request

through update, like you're saying, and then that allows you to implement that logic that

has access to the whole store.

And it can purge parts of it.

If you're deleting something, it can clear it out, it can, you know, do whatever logic

it needs to do, and it can reuse that same central point where you're defining all of

your logic for your HTTP requests.

Yeah, yeah, it's definitely not just for read only access.

It's for the whole way of how you are working with HTTP.

So do you have thoughts on, we talked a little bit about defunctionalization, but maybe we

can clarify a little more.

And so you define this custom type action, and that's going to have a variant for everything

you can do, and the variant is going to have a parameter for any data it needs.

So if it's like get user, it's going to have an ID in there because it needs that to go

do the lookup, to do the get request.

So you want to just define defunctionalization, first of all?

Okay, I can try.

So in my mind, defunctionalization is a type of refactoring where you have a place in your

code that uses a function and somebody else passes that function in, right?

And let's say that there are three such different functions, and what you do is create a custom

type that lists those use cases, and then you replace the function with the custom type.

So now instead of passing functions around, you are passing the custom type around, and

at the last possible step, you then convert the custom type back into that function and

So it seems like a lot of work for no benefit.

It seems like busy work, but it does have benefits because you now have a custom type

that you can kind of look into, right?

It's not an opaque function.

Every function, you don't really have any idea what it does until you run it, and with

the custom type, you can filter those out.

And we do it in the store pattern, right?

We check whether we need to run it, and if not, we just throw it away.

We couldn't do that with the function.

If we just passed the command functions that run the HTTP requests, we couldn't really

work on those in that kind of way.

And yeah, so I think it's really a nice trick to have up your sleeve.

And in the Elm community, we are already doing the functionalization every day.

So instead of message being a function from model to model, we just have a message custom

type that we can then interpret in...

We translate it to a function, but you could do so many more things with it.

And so in the store pattern with these actions, we run them.

So we convert them to the command returning functions, but also you could have really

nice user experience for the failures, right?

So I have this in the store example repository where if we get HTTP failure, we also remember

the action that caused it.

And then you can convert the action to, let's say, the endpoint, right?

To the HTTP method.

You can derive the request JSON body again and show it to the user.

And so there are many different ways how you can use the custom type, whereas with the

function, you could just run it and then it's all lost, right?

All the information, all the details are lost and you can't really rewind time back and

It's also much easier to test and you can also debug them, which will give you a much

more helpful message.

You could do analytics with them.

The sky's the limit.

So the data is nice.

Maybe this is heresy, but you could imagine having the view message type like HTML message.

You could imagine it being HTML function from model to model, right?

And I'm sure some people do this, right?

But I mean, there's a talk at Elm Europe where they do this.

I'm not familiar with that one.

I don't remember the name, but maybe we'll add it to Shenotes.

I have seen people on the Elms have this light bulb moment when they show you the model,

when they show you the message with the function from model to model and they say, Hey, this

Now I don't need an update function.

And they are happy and this is basically like going, this is the functionalization, right?

So basically we like data more than we like functions in a functional programming language.

Here's my take on it.

I'm pretty sure I coined this phrase, but either way I like it.

It's wrap early, unwrap late.

As far as I'm aware, it may be someone else independently coined it, but I believe I coined

that phrase, but I love this idea, wrap early, unwrap late.

Basically the idea is you want to have the ideal representation of data and also one

that isn't lossy.

It doesn't lose information, right?

So like, I mean, it's like if you have, um, if you have a podcast, maybe how do you store

that recording?

You're probably going to store like raw wave files or some uncompressed thing.

That doesn't mean that you want to send like a one gigabyte file to listeners, but you

want that in the recording and the archive and then you derive the lossy format.

Um, but I mean, that's, that's true for many things, right?

Like maybe you need a JPEG somewhere or whatever PNG, but you might start with an SVG format

or something that's not lossy because who knows, maybe you need a higher resolution

version of that or whatever it is, right?

It's really a similar principle that with your data types, maybe you only need it for

one thing right now, but if you need it for something else later, it opens up your possibilities

when you have the lossless representation in the ideal format.

You, you don't want to limit your options too early.

And it's also very nice for like debugging and understanding the code and it's more like

inspectable by the developer.

You can look at it and say, what is the incoming message instead of just like, there are functions

being passed around.

What do you do about that?

You're like pull out your stepwise debugger, which we can't do in Elm.

Well it's very nice to do a debugger if you're passing around actions, which are just a custom

type with nice data.

I really do agree with the official Elm guy that says the custom types are basically the

most important part of Elm.

And opaque types.

Which I've constrained myself not to mention that the store is a record and not an opaque

I will not mention it and no one will know that this bothers me.

Well I do, I do think again, you know, we've talked about this before, Jeroen, the distinction

between opaque types sort of having an internal representation versus exposing a public facing

And that is kind of an interesting, but I guess you could, so that is really interesting

because you could argue like, okay, let's have an opaque type for the store.

Let's have the actions instead of being just a custom type with all the variants exposed.

Let's have functions to construct each action.

But then you want to be able to inspect them in the outside world.

Because like in Martin's example, you want to show a toast message for an error and you

want to be able to describe what happened.

And you don't necessarily want that logic of presenting the toast error to live in the

That wouldn't make sense.

So I guess, but maybe this one breaks our intuition a little bit of, you know, how,

I mean, we should really change the name of this podcast to like opaque type radio, but

maybe that breaks our intuition a little bit.

Maybe that's a really good example where it truly does belong as a bi directional non

opaque custom type that you want to both create it and consume it.

And that makes sense.

I don't know, I'm still, I would still like to explore it within a big type.

I think it would be nice.

I think, I think it could.

And so I haven't tried it.

So I don't know what benefits would it bring.

I think in the application context, this kind of safety is generally less of a problem.

Or let's say you don't need the benefit it gives with like changing the implementation

underneath and so on.

But so, so in the application context, I think it's nicer to be able with the raw thing and

but, but you definitely could make the store opaque, make the message type not expose its

constructors and so on.

But you would then need to have these functions that let you decide, okay, do I need to show

a notification toast for this message or not?

So it's kind of, does it really belong there or not?

But you could do it.

And since it's all in your application, I think it would be fine.

Even this style with a function for toasts that lives in the store.

But I think it probably gives us an answer as to whether this would be nice as library

Because, because I think the library can't really decide that for you.

Ultimately you depend on a very custom custom type, the more of a bad fit it is for a library.

But this one definitely breaks my intuition a little on opaque types because it, yeah,

but I don't know.

Jeroen, what do you think about that?

Opaque types is always the answer.

I want to see your exploration.

Report back to us.

When I have time.

Just one more thing that I didn't mention yet about the store pattern and that's the

So thanks Dillon for refreshing that part of my brain.

It's really nice when the store is the single place where all the data lives.

Single source of truth.

It's really nice to, if you ever need it to have the derived data live in there because

you know that only the store will mutate the data.

And so I think it's generally better to not drive data and to let's say rather do it in

the view if it's not computationally intensive.

But if you need.

I think you said to not drive data, but I think what you mean is to not store derived

It's better not to store derived data.

It's better not to store derived data because there is the danger of having it go stale,

If you only ever update the main source of truth and you don't update the data, then

it gets out of sync.

So I think it's better to do it like temporarily, ephemerally in the view.

But if you ever need that and we like in my experience, we have had the need to store

different representations of the data.

It's really nice that you can just go look into specific cases of the update functions

And do you know that, or at least there's very high chance that those are the only place

you need to check, right?

So if you get a list of users, you will save it into the users field and into the other

I don't know what that would be, right?

But you store it into these two fields.

And then if you insert the user, again, only in the store will you need to insert the user

into the dictionary and into the other data structure.

So it's really nice that you don't really need to hunt these places around the code

Just like in a pig type.

Yeah, kind of, almost.

This deriving thing, I think is one of the most important best practices in Elm code.

And I wonder if this would be like a nice Elm review rule where you look at things you're

storing in the model and say, am I depending on the model for things I'm putting back in

I mean, I guess you do need to update.

Could be interesting to look at.

But yeah, where would you start?

Because you do need to depend on the model for certain things.

So I don't know if there's a way to distinguish between derived state or really this is now

the source of truth, which depended on the previous model state.

Maybe there's not.

Maybe just like toggling something, for instance.

Perhaps we could have some kind of annotation for derived data, derived fields in the model.

And then the rule would check that everywhere you are changing this one, you also need to

change that one.

I mean, that's usually what I use a pig types for.

So I think maybe, maybe opaque types are the answer.

They are the answer.

And when it's not the answer, there's Elm Review.

There's an Elm Radio t shirt for you.

Opaque types are the answer.

But when they're not, there's always Elm Review.

My birthday is...

Well this was a pleasure, Martin.

Thanks so much for coming on.

If people want to follow you or find out more, where should they go to follow your work?

Yeah, it was a pleasure for me also.

So I am on all the usual places like Twitter, GitHub, the Elmslack under the nickname.

Well it's my surname, but under the nickname Janicek.

And yeah, I also have some Elm videos on YouTube and so on.

And I stream on Twitch, but it's not that often.

So I think the GitHub and Twitter are the best places to go.

They're great streams though.

I love your TDD streams.

You've done some nice ad winner code in the past.

Yeah, definitely check them out.

Also if you want to stumble upon Martin, you can just ask beginner questions on Slack.

Yeah, we are having races with Jeroen and other people on who answers the first.

People should definitely check out the recording of your talk on this.

It's a really great illustration and the example repo.

And Jeroen, until next time.

Until next time.