Great, welcome back.
So, there were a couple of questions in the chat during the exercise that I wanted
to address before we actually go through this together.
And they were revolving around revalidating.
So, when you make a form submission and that form submission is successful,
Remix will revalidate all of the data that's on the page.
First, I will say that there are some use cases where you don't want to revalidate
on all the data on the page.
And we have definitely thought about this use case but
we haven't landed on an API that we feel really confident in saying it's stable,
and so it's prefixed as unstable.
And you can totally use it today.
We are satisfied with the use case, we're just not sure about the API,
that's why its prefix is unstable.
It's called should Reload and it's unstable underscore should reload and
that runs in In the client to determine whether or
not a particular route should revalidate.
You can think of that as sort of like the comparator argument to react up demo.
You may never have used that before but it's the second argument to react on demo,
that allows you to compare the props to decide whether that component
should re-render very similar in concept.
Another person asked about, Martin, asked about whether, If there's any
way to trigger a revalidation imperatively to just revalidate the current
route because they have some data that they just wanna keep fresh on the client.
This is possible to do and
I'm not gonna dive into how to accomplish that in this workshop.
One thing I wanted to mention and why I wanted to answer this question
is they mentioned that they can't use WebSockets.
Remix actually supports streaming and Server Sent Events,
which may be something you haven't ever used before.
I know it wasn't something I use because I skip straight to WebSockets because
WebSockets was the new hotness and everything.
Server Sent Events are actually pretty cool and
are have been part of the web standard for quite some time.
It's basically a long lived HTTP request that the server can send
additional stuff over time, just stream new stuff in overtime.
The client cannot communicate the other direction, that's one of the reasons why
people just went to WebSockets cuz WebSockets have more capabilities.
But for a lot of use cases, all you need is the server sending stuff to the client.
So, there's this demo by Jacob EB on the Remix team,
where he shows how to create a resource route.
So here's our loader that creates a readable stream that
which is like web platform mdn or mdn.Io readable stream.
This is again, another web platform thing that you have access to in Remix.
And to have a readable stream as the response that you send to keep that long
lived HTTP request going.
And then inside of that you just use the API, the controller,
to enqueue different events that you're sending along.
And then on the client, you can use this event source thing, which again,
web platform thing to subscribe to that resource route and
then get those events as you go.
And so, if you have a situation where there's only one specific piece of data
that I just need to keep up to date,
I don't need to revalidate everything on the page, every minute or whatever.
Then you could totally go for something like this, and
it would probably serve you quite well.
Certainly would be a little less resource intensive than what you're trying to do
with, just revalidating everything every single time.
And this is just a demo for his thing.
I think it's actually pretty cool.
It'll just show how many people are looking at the site at once.