Check out a free preview of the full Advanced Elm course
The "Impossible States" Lesson is part of the full, Advanced Elm course featured in this preview video. Here's what you'd learn in this lesson:
When we have multiple sources of truth for the same information, our application can end up in states that ought to be impossible. Richard gives an example of how this can affect the tabs in the sample application.
Transcript from the "Impossible States" Lesson
[00:00:00]
>> Richard Feldman: Sources of truth, we're gonna talk about a few different topics here. One is impossible states and the making impossible there of. Derived data, authentication and JavaScript. Okay, lets start with some impossible states. So when we're talking about sources of truth, generally speaking these break down into a few different categories.
[00:00:21]
One of which is essentially do I have agreement on where a particular piece of information lives. So let's say I have a model that has selectedTag which is a string to represent which particular tag I have selected. And then let say for some reason. I have another field, I call theSelectedTag which is also a string.
[00:00:43]
Okay, which one's right? They're both claiming to represent the currently selected tag. We have sort of multiple alleged sources of truth, here. It's even worse if I'm actually using them in different places, like in some cases I'm setting the one but not the other. In another case as I'm reading the one but not the other.
[00:01:00]
That's going to lead to all sorts of nasty blogs if I'm doing that. So hopefully, we can avoid something like this when we're designing our models. But usually, it's trickier than that. Usually, it's less obvious. It's not that you have two things that are the same name but rather that you have some piece of data that is nested somewhere in some record or nested in some custom type that represents the same piece of information as some other piece of data that's nested somewhere else in some other thing.
[00:01:26]
A classic example of this is the current user or the current username. Sometimes that might appear in multiple different places and as long as they all agree, maybe there's no problem. But if they can get out of sync, and then different parts of the UI think that we have a different current username, that can cause a problem.
[00:01:42]
Okay,
>> Richard Feldman: So when I first built out that tab box that we saw a moment ago, this is what I had as a design. I'm sorry not that part of the tab box, but rather this part. This is the The global feed, your feed, and then the tag if you have one of those tags selected.
[00:02:03]
So each of these is a tab. I could represent these in this way which I have. A name which is a string, so Your Feed, Global Feed, or perhaps the name of the tag that we've selected, so dragons or happiness or elm, or whatever those things may be.
[00:02:18]
And I can store a Boolean for whether or not it's the active tab. The problem with this is that it allows an impossible state to be represented. It is entirely possible that we end up with multiple tabs that have active set to true as is evidence in the bottom here.
[00:02:34]
And this is not a contrived example because actually when I was browsing their react reducts example for this project, the real world app, I encountered this. In fact, this just, I don't remember how I got it, but I was just clicking around and somehow I ended up with two different tabs selected.
[00:02:51]
This is I would guess probably a symptom of the fact that in React it's encouraged to use components that have local state. They manage their own state. In this case, that's a source of potential bugs in the form of multiple sources of truth. Each of them thinks that they are the active tab but in fact there can only be one active tab.
[00:03:10]
That is one of our rules for these tabs. And so if each of them thinks that they can potentially be it without having any innate coordination with the others, that means they can potentially end up in a situation where we have multiple competing sources of truth and bugs as a consequence like this.
[00:03:25]
Where we ended up with this is a different structure. So we have type tab and this represents which tab we're on. It sort of inverts that and says you know what? We're only gonna have one source of truth for what tab we're on. We're going to enumerate the three possibilities which is to say your feed is the active tab.
[00:03:45]
The global feed is the active tab. Or we have a particular tag feed and if so, we also have the tag that is associated with that, so dragons or whatever else. So this is a custom type that enumerates all of the possible states completely, and it's one source of truth for all of them.
[00:04:03]
So we don't have the possibility of competition just stores, this is the tab that we're on like this. So this becomes impossible. This is an impossible state that we have made impossible by virtue of modeling our data differently. As a consequence we've now reduced our multiple sources of truth down to just one.
[00:04:23]
I did a whole talk on this concept a couple of years ago. It's called "Making Impossible States Impossible". It talks about techniques like this in a variety of different scenarios so we won't go into too much detail on that right now except to note that this is one form of potential multiple sources of truth causing problems is impossible states.
Learn Straight from the Experts Who Shape the Modern Web
- In-depth Courses
- Industry Leading Experts
- Learning Paths
- Live Interactive Workshops