Rendering Data That Disagree

Hi, I'm Tom, and I want to talk about rendering data that disagree. So let's say you are rendering a web page. And maybe you're using server components, maybe it's a client component that's SSRing, maybe you're back in PHP or Python or Perl or Ruby land, and you need to grab some data.

You're probably going to get it from a database. And so you fire off your first SQL query, which is a select for let's get all the users that are in a given chat channel, and then you fire off another SQL query to get all the messages in that channel. And now you have the data you need. You can just render this thing.

This is discourse or my favorite, Zulip. And in the center, we have a bunch of messages in a chat channel and over on the right, we have the users that are in that chat channel. But hopefully with that first just that problem description, your mind went to, ah, but are those two SQL queries in the same transaction? Are they like here? These are two queries that run separate transactions or are they in the same transaction? That's important information for us because it tells us what we can do with that data.

What if you first read your users and then a new user is added to the channel and they also post a message and then you read your messages. These adding a user and adding a message might be an atomic action that could happen together. It could be a join message or something. And if we read them like this, we read users and then we read messages, and we assume that every message has a corresponding user, we're going to be disappointed. This is one of those cases where, well, let's see. What could happen? Maybe it's just a visual inconsistency. Maybe all that happens is that you see this page and you say, oh, that's funny. There's a person here, but there's nobody corresponding in that user's thing. Often it doesn't matter. And often what you do, what our users are trained to do is refresh the page.

For better or worse, that's how the web has always worked. Like, uh-oh. Maybe it's eventually consistent. You refresh and it's all better. But maybe that visual inconsistency is a big deal. Maybe that's the difference between thinking I have my Taylor-Tomlinson tickets and I don't have my Taylor-Tomlinson tickets. Maybe I see something, it's a purchase, and something confuses me there and I really get worried as a user. But maybe it's not two separate UIs. Maybe it is one UI and I have code that expects both of these pieces of data. I'm assuming every message has a corresponding user, and what this talk is about is that it is your job to know if that data could be inconsistent.

And you know this TypeScript error we see a lot, where you have a map and you say, oh, I think it's a map of every user. And you look in there to get a user by ID and it says, uh-oh, what you went in there for is not there, and you always just slap a exclamation mark at the end because, of course it's there. This was supposed to be a full list. Well, in this case, we don't get to ignore that TypeScript message. What if we are missing users? And we don't get to ignore it because this is what happens, right?

This is a pretty bad thing. Whether it's better or worse than a visual inconsistency, I guess it's up for debate. But in general, I want to say it's worse. So there's a neat idea, call a transaction. And if these two queries had been in the same transaction, we would not be worried here. And then if we did get an error, it would be a very actionable error. It would be, hey, something is fundamentally wrong about your data model. If your database returned these two lists, and you ended up with a message with no user, there's something real wrong here, right? Instead of the alternative of users just complain sometimes that like, ah, it seems like data is loading a lot. And when that's how a inconsistency, fundamental inconsistency in your data manifests, because you've coded around some users just don't have some messages don't have users. And that's fine. You know, it takes longer to find problems in your system. Consistent data can mean that those client side errors are meaningful. But you can't always have consistent data. Maybe you're getting this data from multiple databases or several APIs. So the job of you as a front end or the rack developer here is to know that these are consistent.

Now we're going to talk about React. Turns out, if you're not using your WSGI, this gets worse. Rich clients make everything worse. I mean, they make user experiences better, but they make things harder for us. Because now, say I'm looking at my list of messages, and I send a new message, and then I choose to revalidate. I choose to make an API request to get the new list of messages. So I can have a list of my messages in this channel that includes the one I just sent. But then I don't update the users. And now, if those two are out, they could be out of date for, what, 30 seconds or something. Once we're updating some data, but not all our data on the client, and that data is supposed to be joinable, it's no longer if it's now when.

Whenever we encounter a case where somebody sends a message and is no longer, you know, anyone that joined the channel in the last 30 seconds could cause that front end error. Once again, we really can't ignore this TypeScript error now. And live updates kind of make everything worse. Again, they make things better. But they make it more important for us to reason about consistency. Maybe you're periodically fetching new data. A nice way to do this is with React Query. And let's say that we're being really careful here. And React Query lets you use timers or tab visibility or manual invalidation logic to decide when to send those fetch requests, update the new data. And let's say, just be careful, we're invalidating everything. So we won't run into this messages are new, but users are old. They're all new all the time. But even if we fetch those and we fetch them at the same time, the requests could finish at different times. And now we're gonna have these little flashes in the user interface where, oh, we got the new users, let's render those. Oh, we got the new messages. And maybe they're not annoying flashes, but they are an indication of trying to render the new set of users with the old set of messages. So many renders, not necessarily flashes, but many renders could mean many opportunities for that inconsistent data to bite us.

If this sounds familiar, you maybe were using React back when we had to think more about unstable batched updates, when we had to say, you know what, I have two set states and they are not called as a direct result, a synchronous result of a user action. And so it is my job to note that and if I don't surround these with, if I don't batch these updates, the first set update will run first and I'll re-render and then the next one will run.

And so it is my job to note that and if I don't surround these with, if I don't batch these updates, the first set update will run first and I'll re-render and then the next one will run. And I won't see that flash to the screen, but I will run that code. And if that code includes that client-side join, I'm going to be in trouble. We don't have to do this anymore since React 17, right? Things are better, but it's still a problem for something like fetch, where you fetch this data, you fetch that data. And in between those two fetches resolving, you have inconsistent data.