Build a Universal Reactive Data Library with Starbeam

So basically, I have a bunch of little mini tutorials that I'm going to walk through. I haven't yet published the packages that would allow you to follow along if you're at home. And so hopefully by the time you watch this, maybe I will have done that. Either way, I basically created a bunch of little steps that can help me get across some of the points about what StarBeam is good for.

So another thing to say is there's a few different ways to think about StarBeam. One of them is just that it's a standalone reactive library. I've given talks about that and even started writing some slides about that, but I instead decided to focus a lot more in this set of examples on intermixing with React. So originally, it was always intended to be a React focused tutorial, but I also focused a lot on interleaving StarBeam reactive stuff with useState and things like that. So there's a way to get more all in on StarBeam, and it does—there's tradeoffs. It helps some, but it requires to be all in. I decided to focus a lot on interleaving StarBeam stuff and the benefits of StarBeam with just regular React stuff.

So I'll just get started, I guess. The first step here is a very standard counter example. So let me just show you the example. We have some increments. I have a little text field here, and if you increment, it basically adds the number to whatever counters are being implemented. I think I could have made an example that's just pure React, but you can probably figure out how to implement that in pure React, right? So like I said, I decided to focus on intermixing StarBeam with React. So in this case, I'm just starting by using a regular useState to get me the start variable. So that's let's see if I can pull off a React inspector. So here's how we'll counter, right? And you can see that there's a start props that goes into all the things. And if I increment start, right, then like that's going to be a props are going to update. So that's like very normal React stuff. And then how I implemented the text field is just like an input field. Basically, I did the new use ID hook that React added to make HTML 4 work, blah, blah, blah. This is all like bog standard React stuff. But then the counter is like because I think I'm legally required to make a counter tutorial, the counter is a React is a StarBeam example. And I decided the way I decided to focus on this is basically to make a little custom Reactive value called a counter and I'll explain how that works in a second. And then I'll explain there's basically two things going on here. One thing that I'll just generally want to say is that a thing that's interesting about StarBeam but it's hard to get across in this kind of demo is that when you implement something like this, which we'll talk about in a minute, it will work in Preact, it will work in Vue, it will eventually work in Svelte, Ember, et cetera. But when you first encounter it in React, you're probably mentally comparing it to what you would have to write by hand, and it's probably fine, but it's not like it's unfamiliar and it's not that much better. So I think I decided anyway to focus on an example that basically just give it five minutes is what I would say. So let's get through it, even though at first glance, this is not really buying Vue a lot. But the point is, as you'll see, as we build on it, we'll see that you get some benefits and also the universality is good.

So basically there are two things going on here. The first one is a hook called useResource, and a resource is just a general purpose ... It's the main unit of StarVM functionality. And if you write the resource that's on line 38 over here, like I said, that same resource will work in other frameworks. So what you would probably do if you're writing a library or something is you would write this as a standalone thing. You wouldn't be using any React code here at all, and then you would be able to use it wherever you want. And again, the second half of this tutorial is building up a data library, and hopefully it will make more sense when I get into that. So what is going on here? So first of all, the most fundamental unit of reactive state in StarBeam is called the cell. And that's like if you're familiar with signals, it's like a signal or a use state variable or anything like that. It's just the most fundamental unit of reactive state. So we're just inside of the resource... The resource function is kind of like the promise callback, right? It's place to set yourself up. So inside of there, we're just making a new cell and then we're returning an object that has a getter on it, which gives me the current value of the cell and an increment method on it. Now if we go back to the react code, the hook just takes one of those things and it gives us back this value. It can do a lot more things than that, including like setup and teardown but we'll get to that soon. Importantly, the value that you get back from useResource is always the same. That means if your hello counter re-renders a bunch of times, you're not going to get new copies of cell every single time because of course that would not work.

You can't subscribe to something or you can't interact with something that's changing all the time unless you're useState. So when you say useResource, that is going to give you back the same value every single time. I think one way to think about this is that it's giving you a lot of what if you're familiar with solid, solid is basically a way of writing something that looks like React, but there's a part of your code that runs one time and then there's a part of your code that keeps running every time. It's basically that same model, but it uses a familiar looking React hooks and you can use it in React. You get the counter, it's the same one every time, and then this code over here is something and it's something that you have to write in React basically because of React internal details. Notably in preact, which has almost the same API, you don't have to write this. It's just a thing that React makes you need to do. So basically useReactive is just a hook you wrap around any code that interacts with other StarView state. So here you're making an instance of the counter and here you're just saying I'm going to interact with the counter. So if you just use Reactive as a hook you can pass dependencies and in this case importantly here like I said before start is just a normal React state variable so you can pass it in over here and that all works as you would expect. I also should mention that I have a bunch of stuff on the website that goes into detail about this, but starbeam also works perfectly well with React strict mode and that turns out to be a little trickier than it looks in general, but basically whenever I say this only runs one time or like this dependency etc etc, there's a lot of gotchas that come up if you just try to implement stuff like that yourself and make it work with strict mode and basically under the hood we make that work. So basically you say use Reactive that just means you're interacting with the Reactive state. You can put you can wrap that around anything, but you don't need to do it if you're not interacting with any Reactive state. Also if you forget to use Reactive, what's going to happen when you try to interact with the state is you're going to get an error that's that's pretty clear. It says you attempted to read this Reactive value and it gives you a line on stack trace, but it's a Reactive value that was created here. Please wrap it in use Reactive. So basically we have this hello counter, and we're saying counter.currentplusstart. Again, I focused a lot on interleaving React state with Starbeam state just to show that it works. And so we have an H1 and then on click we're doing counter.increment, and that's going to call this increment. So kind of got into detail here, but if we just reload here, it basically behaves like you would expect. So increment the start thing that is going to update the start in all these places. And I also have this incrementer. When I increment that, it obviously works. So I think that's like, I'm belaboring the point a bit, but I think it works the way you'd expect more or less. Now let's go to the second step.

So the second step is, OK, I want to have a dynamic array of counters. And I want to be able to add and remove them. And I think just showing you that it works the way you would expect. And so basically think about how you would implement that in a normal React context. And then let's look at the implementation here.

So first of all, I made a new resource called counters. And here is where a piece of StarBeam that's really valuable shines, which is StarBeam comes with reactive versions of all of the JavaScript built-in collections. So in this case, there's something called a reactive map. And that behaves exactly the same as a normal map. And if you look at the TypeScript type of this thing, it's just a map, right? It's just that whenever you read or write from the map, it's reactive.

So OK, so we have this resource. We made this reactive map. And now we're going to write a little implementation for it. So first of all, we want a list of all the counters, right? And that's going to give us a, it's just going to spread the values of the counter, right? So that's using the normal JavaScript API for spreading, right? Looks the way you would expect. Very quickly, a counter is just an object that has an ID and a count. The ID is basically there for the key in React. OK, now, how should remove work? So remove is going to work by just deleting the item from the array. How is add going to work? It's going to work by, it's going to increment this variable that's basically just, again, it's just so that we get a fresh ID every single time. We're going to make a new reactive object. So just like there was reactive map, there's reactive object. And reactive object also has exactly the same API as a normal object, but it's reactive. So that means if you do object.entries, object.keys, object.values, if you look up a property, you do in, any of those things is going to work reactively.

OK, so we're going to start the count at 0. And then we're going to set the counter into the map at that ID. Now, so now, in the implementation, we're going to say, we're going to start as, once again, just going to be a normal React state. And we're going to say, give me the countered resource. Again, that gives us a stable value every single time. And then the start ID is basically just for the label. OK, so same deal as before here. Now, when we click on the button, by the way, this board here is just like an ESLint thing. If I delete it, ESLint is going to yell at me. And I auto, when I save it, that's it. That's just the thing to, if you're using TypeScript with very strict ESLint settings, that's what happens. OK, so yeah, so when you click on the button, you say counters.add. I think it's worth noting, when I said before that you get a stable value, that is a meaningful thing here because what that means is that there's no such thing as a stale closure problem here. The counters is always the same value. So it doesn't matter when you created this closure. It's always doing the right thing. The next thing we're going to do is we're going to do counters.list. And just as a reminder, what all list does is it spreads over the values, and that's using normal JavaScript math API. And let's see. And then we're just going to map over it, and we're going to just do the normal reacting once we've mapped. So each time we get a counter. I'm using the vanilla framework for CSS just because that looks nice but not very important here. So we have key if counter.id. And then we're going to call hello counter. Hello counter takes a start like before. It takes a counter now. And it also takes a remove, which is just counters.remove. And if we go look at what hello counter is, so it has the ID.

If you go back to here, each one has this ID. Let me see if the React inspector. Why am I getting yelled at? I don't really know. OK. Anyway, the ID. I may have forgotten to put strict mode somewhere. Anyway, I normally do everything with strict mode just because I worked very hard to make strict mode work in React. So I want to make sure I catch anything very quickly if anything doesn't work. And all the React tests in StarBeam use both loose and strict mode. They have the same tests. There's a test harness that runs in both.

OK. So you get this ID over here. That's that ID. And then this is all very verbose. But it's just vanilla framework. The important part here is that the counter.count goes here. So that's the counter.count. So if I increment that, so what is that count? That's just this thing that I am modifying. And then start is just that React variable. And then I just have a thing that's start plus counter.count. And then the increment button just does counter.count++. Decrement does counter.count minus minus. And the Remove button just does Remove, which is that we pass in the Remove function that takes an ID. So we have an ID. So we call Remove and that works. We still have to pass Start here as a parameter. That's just because Start can change. And that's one of the things that React needs to know. In order to, it's basically a normal hook. But you don't have to enumerate all the things that are StarBeamReactive, because StarBeamReactive is automatically tracked. Remember, we call it auto-tracking. OK. So importantly, I think it's, I can believe the point. Because I think it's cool. And it's easy to look at it and be like, oh, I don't see what's cool. I don't see what's going on. It seems pretty normal. But I think if you think about all the things that you would have to do in React to get something like this working, the fact that you can just make an array, make a map, put stuff in the map, in event handler, and then add stuff, remove stuff, increment values, and it all works, I think it's basically magic. And it doesn't have the problems that, I mean, it has some philosophical problems if you're obsessive about mutable state, but it doesn't have the React problems of mutable state. Basically, the only caveat that you have with starter meme and React is that you have to say use reactive around code that uses it. Again, Preact has the same API and does not require you to use reactive, but in React, that's the only caveat. And then everything works perfectly. OK. So that's the second step. And, again, the big takeaway here is that there are track built-ins, auto tracking built-ins, that are reactive maps, reactive arrays, reactive objects, and you can use them and they work. OK. Now, let's look at the next step. So now that's all up for counters. The next thing I want to show is a date example.

And so the date example here is basically you can select the time format that you want. These things are basically just the built-in, the Intel date format, you'll see it in a minute. And whenever you change it, it's going to update the output and it's going to give you the time. I was like, why isn't it ticking? That's because the short time doesn't have seconds. But it's basically ticking. So more or less, this is a set interval example.

OK. So I made a new resource called a clock. And now we're getting into setup and teardown. So the way it works is you first can, just like before, we can create any reactive state we want. If we want to set stuff up and tear stuff down, we do that inside of an on setup block. And in React, the main reason why this is important is that React needs something to render initially. But it's not going to run your teardown code if it didn't run your effect. So basically, that's a React jargon. But basically, the way to think about this is that this is going to be present, whatever this value is going to be present on initial render, this is only going to run if React gets around to setting up your effects. And then it will automatically do the right thing. So in on setup, we're going to set up an interval. We're going to set the value of the cell. Oh, I should have mentioned this before. There are three different ways that you can update cells. So you can say now.current equals new date. You can say now.set new date. And you can also say now.update old date. And then whatever you want to do. Those are basically just three different ways of saying the same thing. So that's that. And then, like before, we're returning an object. It has a format in it. I want to point something out here, which is that the object that we return at the end is still a single value that doesn't change over time, even though this block here can change. And we'll see in the next step that this block can change. We'll see in the next step that if something inside the setup block invalidates, then it tears down the setup block. But it doesn't destroy this code. So all we're doing here is we're returning an object that has a format method on it. And it takes a date style and time style. And all it does is use intl.dateTimeFormat, and it reads now that code. So now, just like before, we're going to say useResourceClock. And then we're going to say useReactive. useReactive, before it takes a callback. There's no dependencies this time. And all we do is we're going to say the time is dot, dot, dot. And then we're going to call the format method on the clock with time format and date format. Actually, I probably, it refers to me. I probably should have had time format and date format. Basically, the deal here, by the way, is that more or less, you don't really need it. But in certain cases in strict mode, if you don't pass it, you end up with a stale value. And basically, for better or worse, that's what React wants you to do, and that guarantees that the behavior is correct. But most of the time, if you don't pass dependency arrays and the outer component re-renders, you get the right behavior. It's not like the useReactiveBlock is not only cached based on the ReactiveState inside of it. It also re-evaluates whenever the outer component re-evaluates. That's a little in the weeds.

So importantly, when you call clock.format, we have a time format and a date format. Those are two pieces of ReactiveState that are allowed to change. But also, there is the ticking clock that's changing, and that's used here. So we're just doing a pretty normal bog standard thing. I just extracted select style into its own component. And again, part of the point here is it's pretty normal React stuff. You can easily interleave it, intermix it. So I have a thing that's a normal component that gives me SelectStyle. You can use normal hooks, et cetera. And then, since I'm just calling another component here, and I'm not using any ReactiveState out here, I don't have to say use ReactiveState here. We're like, as far as this code is concerned, there's nothing Reactive going on. But then when I call a clock, that code is using a resource, or that code says use Reactive. And again, that just works the way you would expect. Now I have one last step here, which is basically just I want to show you about invalidation. So here I have an example where the resource takes the speed, which is an update in milliseconds, and it reads the update in milliseconds when it sets up the interval here. And so the idea is I would like to clear the interval and set up a new timer whenever the update in milliseconds changes, but I want to keep around the old cell and the old object. So basically, if I slow down, what you'll see is it will stop, it will take more time to update. If I speed up, it updates faster. And the way that this works is, so the setup function is basically just a function that all it does is give you a stable value. So I made a ReactiveObject with updated milliseconds of 1,000. I got a stable version of it. I passed that into clock. And then the clocked function takes the speed and then, like I said, it accesses the update milliseconds property inside of my setup. And what that means is, let me do a console log here. Let's do a console log here. Creating resource. Let's actually pop it back in so we can show. OK. So if I reload now, so this is strict mode, creating the resource, creating it again, creating it again, whatever. And then it eventually calls setting up. If I speed it up, you can see that setting up gets called again, but not the resource, right? The outer resource is stable. And the setup, but the setage rule is getting torn down. That's important because it lets you hang onto the value that you got back from useResource, and it is guaranteed to work. No stale closures or anything like that. You're guaranteed to get same value back. OK. So that was the only point of this whole example. Yeah, and just so you see it, how does it work? I'm just using like slash equals and star equals to update the value that's inside of ReactiveObject, and that just works as expected. So now we're going to move on to the thing I said that I would do in the proposal. So we're going to go step 2. Yeah, I forgot to actually make the navigation bar work in smaller window. So OK, so basically very quick, like the quick demo is, I am able to, I'm using, in this example, you'll see in a second, I'm just using like local data. And as I increment the user ID, it gives me the right value. And this is a boring example, but there's a specific point I want to make here. So in this example, I have a current user resource. And the current user resource, so as you'll see here, I just copied and pasted from the, forgot what it's called, from JSON placeholder. I just copied and pasted all the data. But the resource has a cell, which is just a current index. And it returns an object that has a current getter that returns the member of the array at the current index dot current. And the important thing here is that even though all that's changing is the current index, the fact that this getter accesses current index dot means that this value invalidates.

This value is tracked. And then, same deal here. If you just access the index, it's tracked. And then, all choose does. So if you say I want to choose an index, all it does is set the index on the cell. So again, same deal. You have a cell. You return an object. The object is stable. It doesn't change over time. You can get the current value. You get the index. You choose, et cetera.

So now, let's look at how it works. So we get the current user resource. So basically, what is the profile? If the current user is undefined, then I basically say invalid user ID. So user.current, remember, is just this thing. It's not doing anything super special. But it is accessing the index. So that means that every single time the index changes, this whole thing invalidates. So if there is no current user because you're out of range, it says invalid user ID. Otherwise, it invokes the profile component. And the profile component, notably, just takes the API user. API user is this thing. It is not a star view thing. Because we called it with user.current inside user reactive, now it's just a regular API user. And from the outside world, it just looks normal.

I made a little JSONify helper that all it does is it calls JSON.stringify for you. So all it does is makes the profiles free with the JSON.stringify. I'm so sorry. And then, you can look at this if you're interested. I like it. But it's basically just an input. It's an input field that I wrote. I don't think there's no star beam in it. It's a very bog standard React thing. So whenever the number updates, then we call user.choose. We get back a string, although, yeah, we get back a string. Because the user IDs are off by 1, so the user ID 1 is actually at array index 0. So we subtract 1 there. Notably, you can do whatever any normal JavaScript works. You don't have to think about, did I do the right Reactive thing here? No, the choose method sets a value. You can subtract this all the time. And then the value of the field is just user.index plus 1. And user.index, remember, is just this thing.

OK, and then profile is just this. So I think, again, when I decided to do this style, one of the things I want to show is that you don't have to drop into star beam world, and then you can't use any normal React stuff. A huge percentage of what's going on here is normal React stuff. It's just that if you decide that you want to use star beam state instead of use state, you can do that. And it gives a lot of benefits.

You don't have to think about this kind of stuff you have to think about if you're doing React buff, OK. OK, so that's step two, very boring. But I feel like I have to write label equals now everywhere. I can't change it. I forgot to update it. So now we're getting into what about it being an actual data API. So in order to show you this, I have to show you something. I made a remote data API. And I'm going to I made a simplified version just for clarity. You'll see as we get later on, there's more to the actual implementation. But this is a close enough approximation.

So what is remote data? It takes a URL. The data is just a reactive object that has a status and a value in it. And then I made an async function. FetchData takes a board signal. I didn't have to, but I decided to support aborting. And that means that in strict mode, you get an abort, and that's just how it is. I think that's what strict mode wants from you. So basically, we do a fetching here. If the result is OK, then we await JSON. This should be pretty understandable. We're just updating some values. And then on setup, so this is just a function. On setup, we make a new abort controller. We call fetch data with a signal. So that's how the signal got there. And then we catch any errors and set the status to error. And then the cleanup of the setup is to abort the controller. Otherwise, we just return the whole data. So we're starting to get into something more elaborate here. But it all builds on what we saw so far. OK. Where are we? OK, so use resource. We call remote data. Again, profile just takes an ID as a string in normal React values. So we can just pass it in over here, pass it there. What we call use reactive. Use reactive doesn't take anything special I think. Right? And then all we're doing here is we're saying, OK, if the user status is loading, then just say loading. If it's an error, print the error. Otherwise, if it's success, do what we did before. This is just like you don't really need it. And I actually do. But I think TypeScript makes me want to have to say something there. But I don't think it can ever happen. OK, so just to show you if I move on to the next example. So you can see it says loading. Right? And if I implement. Now, every time I change it, it's loading it again, which is not necessarily what we want. And that's what the next steps are. But still, this is pretty good. Like basically just building on what we already learned, we can build a reactive piece of reactive loading state, handles abort correctly, handles strict mode tearing things down, and all that. By the way, I could have done more here. But I think just showing you the JSON is probably clear enough. OK, so like I said, that's all very nice. But we really would like to be able to store multiple of them, like keep them in memory. So here's what this does. There's only 10 in the database, so I just wanted to break the 10. But basically, now there's a text field. The text field has a number between 1 and 10. When you initially load, there's no items in it.

And hopefully you can get a sort of a sense for how this is connected to the counter example we did earlier. OK, so as I increment, it's loading. And then if I select them, you get it. You get the right one, right? And great. OK, so how does that work? I'm on step four, right? Yeah, so how does that work? So first of all, I made a user's resource, just like I made the counter resource before, and just like before, I make a reactive map. Every single API in StarBeam has a place to put a description. And if you use the debugging API, it basically shows you how everything is connected to each other and shows you the description if you supply one. OK, so what did we return? We returned a map, the map which is the actual map, and all. And the all is basically just going to loop over the entries and it sorts by ID. Again, this is like standard map.entry, standard sort, standard normal JavaScript stuff. And then get says if the map has the ID, then we're going like, here's the next interesting thing. So if the map doesn't have an ID, then we're going to call the resource function takes a use. We saw on before, but also takes use. And that allows you to create a new resource inside of the existing resource that gets connected, and its life time gets connected. So user is just a wrap around remote data. But this basically means that when the outer users gets cleaned up, all the individual ones get cleaned up, not so important with fetch, because probably you have a ton of reports hanging out, but if you have a channel or something, it'll work. OK. So if the mapper does have ID, we set it. Either way, we return the doc.

OK. So let's see. Let me put the label here. Label equals user ID. So current ID is, again, just the standard use date. We get the users as a user resource. Since current ID is a normal React thing, we pass it as a dependency here. And then same deal with the field. The field just changes the current ID. Now here's the important. There is a critical thing here, is that, OK, we're just going to call users.all. And what is users.all? We remember, it just does this standard spreading thing. We loop over it, and then the ID is the key, the React key. So then we just make a user item. The user item we'll look at in a second. So a user item takes an ID. It takes a resource. Async is just this thing, like it's just this thing that has this union. Basically it has this different statuses. So it's a resource of that. Resource just means you call that current to get the current value. And then, you've got the current as a number, and you get a select callback. And select, if you look over here, just call set CurrentID, which is a normal React thing. And that's, again, what I mean by interleaving. You're setting the current ID, which is normal piece of React state. And that is going to affect what happens in Starbeam land as well. So what is a user item? Well, first of all, what does it mean if it's current? It means that the ID for this user is the same as the current ID, so we passed in the ID, which is this ID, and the current, which is the current ID. Again, it's a piece of React state. Then we return a user item. This is a normal React button. When you click on it, it is just going to call select with the ID.

And if you want to get a sense for it, that's what this is doing. And then I have a user name component. The user name component takes an async API user. And I think I don't need to see Reactive here, but I'll leave it for now because I don't want to mess around with it. I think I don't see any Reactive state being used. OK, so the class name, if the status is an error, it's error. And then, we are checking user status. And this is a little, I think this is confusing. It comes up in a, this is just an API design thing about this example. In the next step, I end up, I support reloading. And in a reloading state, you can be, basically, it will result in, if you're reloading from an error, I'll show you the next step. If you're reloading from an error, then you get the error class name, but you also might be loading. Or you might be value. I agree that in this particular example, that's a little, it looks weird. Either way, you're switching over the user status. The user is just an, at this point, we passed in the current value. So it just, I think I can leave this. And I think you will work it. It does not. Why is, ah, that's because, it's because the user is also reacted. This thing. Like this thing. Okay, I think, in general, you get a good error if you mess it up. Typically, I end up, if I'm like, if I know I'm interacting with the reacted state, I just end up wrapping a lot in it and it works out. Okay, so that's just what the user name is. It's like, let's reload. So it's basically this little piece here, right? It's this piece. Now, when I select something, right? What that does is it calls the select function that I passed in and that is ultimately going to result in this set current ID getting called. And that is going to result in, that results in the user variable. So the user variable is just like all my users that get and then this piece of react state, right? So whenever I update that piece of react state, the user gets updated and I can pass it in over there, right? So again, there's interleaving going on. And the profile is what we saw before. I don't think there's anything special that's beyond what we saw before.

Okay, next. So that's all cool, but I wanted to handle some additional cases. I want to handle errors and I want to handle reloading, revalidating, right? And I think this is where StarBeam starts like pulling away from what you're normally able to do if you're not already convinced. So let's take a look at what this example does. Well, let me show you first. So I basically just rigged it up so that one out of every four times you get an error instead of getting a result. I'll show you how it works in a second, but same as before we get these things, they load, but now unlike before I can click on this thing and it will reload and you can see it says refreshing over there. Whenever I click on it, you can see a things. If I happen to be loading it, it does the right thing. This errors thing and this download thing is just, it's account. And the critical thing here is it just, it just looks like normal JavaScript, how you describe it.

Okay, so got to right that. So everything so far is basically the same. However, I basically added some features to remote data that I didn't show you before, which are basically a way to invalidate the remote data and the error rate. If we look at it, what may, what's probably apparent by now is that when you have a piece of reactive state, if you read piece of reactive state, it invalidates whatever computation uses it. There's a special kind of reactive state called a marker. Now you could have used like a cell and incremented a number or something, but it makes debugging nicer if you just explicit what you're doing. So a marker is just something that you can validate when you want. And so the remote data API takes a marker as an option. Now inside of on setup, if the marker is just called invalidate, inside of onset up all it does is it reads the invalidator. And that means that if you later on mark the invalidator as dirty, it's going to result in cleaning up and resetting up just the set up block. Everything else is gonna be the same, but it's gonna recycle this set up block. Otherwise, so that's all that's doing. It's basically just another consumption. And I think the way to think about this is that the piece of data here that we're returning has another piece of state, which is like, am I still valid? Is this a valid user? And if you invalidate it, that's just a fact about the underlying data, right? So just reading it, it could have been a revision. It could have been anything. Otherwise it's the same. The error rate is just over here. I basically just say, okay, if, like, if there's an error rate, then just, like if you said 0.25, I, whatever, this is just math. Basically, if there's an error rate and it's the right mod, then just return error. That just allows me to demo the error. So going back to step five. So everything I think looks the same. Don't remember. I think this is one of the reasons I haven't published the package yet is try to figure out how to make this not necessary. It's a thing you would have to do in React, but I, like it's not really necessary, but I think fixing it was making tests fail. Okay, so.

Ah, so a few things. So there's a lot more code here, and I think I would recommend looking at it when you're following along, but nothing, there's nothing major here, so I added a statistics thing. Statistics is, it all, it's basically the same as what we did before, right? It's saying like, give me all the users, filter by user.status.length. Here's the error stats, if there's any errors, and like, whatever. Basically, I think a good way to think about this is, if you were writing like a node version of this library, like an ORM or something, like this is just the code you would write. And you don't have to think much beyond that, right? You have to say, useReactive, you have to useResource, but once you have a object in your hand, you can basically just filter it to your heart's content. And what that results in is, right now there's one error because one user status says error. Let's quickly look at this. So that, and all that's... The only reason that the user status is error is because we have a reactive object and when there's an error, we set the status to error here, right? So it's just pretty normal. Yeah, so that's the statistics. In some sense, I'm just repeating myself a lot here because I think it's hard to really like, there's a lot of code here, but 95% of it is stuff we probably already knew how to do. Right, you can basically just keep following your nose on the reactive stuff and it works. Okay, let's see. Ah, so basically what does this refresh button do? All it does is it calls and validate. All that does is call mark, ah, I made a class just for fun. So that's the other thing is like, you can just like put stuff in a class because it's just an app, like, there's no, you don't have to write any like derive blah, blah, blahs or like at computed whatever's like basically, however you wanna store your objects, however you wanna read them, as long as you actually can read them somewhere, you're good. So is reloading basically just says is the status reloading? And that happens if we go back to remote data, the way we get reloading is that on, if the set up is, if this teardown happens, then we remember the last piece of data and we store that inside a value and we also set the status to reloading. So yeah, so that's what is reloading is. And again, I'm just trying to say like, you can think of all this as just pretty normal data reading and the mutations just not like, you need to do the mutations in an event handler. But I think that whatever, that's normal. And that's like also what React wants and you get a good errors if you don't do it. But it's pretty easy not to mess it up.

Okay, so great. Ah, so get data, I added a little helper here that's just basically like unpack the reloading thing. Yeah, I don't want to have to, I'm not gonna read all the code here. I think if this is a real workshop, I would probably get our hands a little more dirty, but I think it's probably worth reading yourself if you're interested. I'm trying to think what, if there's anything super interesting here. I think we covered most of it. I think, yeah, so users that all that map, like everything's still working the way it was working before. Again, I think the only, the only thing that this example adds it adds fundamentally is the invalidator marker thing. And I also started writing more abstractions, but that's kind of the point. The point is that as you build up your library, you can really refactor it however you want. You can, if you like this getAcing thing, for example, maybe you don't understand it. Where is that? Maybe you don't understand it, but the important point is like, you didn't have to think, oh, I've already wrapped your thing. I need to write use getAcing, I need to write derive, I need to whatever. Basically you can just pull these abstractions out of works. Okay. So yeah, so that's that. Yeah, I already started doing some filtering here, we did some sorting already, right. And what's gonna happen is it's all gonna work like before I can select stuff. If I select an error, it's gonna refresh and that's gonna do right. One last step, and then I'll take any questions from the one person who has stuck it out if there's any. So the last thing is because I put it in the abstract, I wrote a filtering logic. And the filter logic is basically just like if I write towel or something, I happen to decide to leave the 404s around because otherwise there's no way of refreshing them. However, if you do refresh them and then they become not matching the filter, they disappear. So let's look at how that works. Yeah, so I basically created a new filter using getState, normal stuff, pass it in over here. And then all I do is, instead of saying users.all here, I say users.all.filter. And then I just say, is the user status? If the user status is not success, then leave it because like I said, you want to reload it. Otherwise, check to see if the user matches the filter, which we'll look at in a second. Or if the filter is empty, then that's fine also. And what is matches means? So this is, yet again, it's a method we could put on our local user object and we can just do whatever we want, right? So we just get the data, get the data, success. And this is like the most boring filter, right? Like the names lowercase includes the text, then return true. I guess I can just do this. I'm surprised we have one for the long. So now if I write like. I think it's worth calling out the fact that if you like that, if that error is there, like think about what's going on there, like what's going on there is behind the scenes. There's like a map somewhere. I'm just going to keep hitting it like an error. Behind the scenes, there's a map somewhere. And all we actually did is like we changed the value inside of a map somewhere. And because of the fact that our filter, because of the fact that our filter called this matches method, and because the matches method looked for status, that is sufficient to make it either appear when the error is there or disappear if it doesn't match. Let's make that happen again actually. Four times, one, two, three, four. That is sufficient to so if I write like Leanna without having to like propagate, think about dependencies, blah, blah, blah. All I do is I change the underlying thing and that was enough to make that go away, to change the downloaded thing, to refresh that as it's happening and all that. Okay. Oh, I should also point out, I think I didn't mention this earlier, but as I'm changing the user ID, it's changing the thing that's selected and the way that that works is simply, so we have a current ID, right? The current ID is plugged into this normal React field and because everything else, like because the current user is driven off of users.getCurrentID, everywhere we say user, let's see, right so when we pass the user into the profile, like that is sufficient to get it to update when we just move this around, right? If I write three, if I write nine, okay. So to take a step back and then I'll answer your questions, I think what's cool about this is that you get to basically write your, in some sense, this is like not really ReactQuery, but it's like if you're gonna write a standard like your own ReactQuery, you can get pretty far here and all you have to do is make a map that has the values in it, you can use track state, but mostly you're doing that somewhere deep inside and then everything else is just like an object wrapping another object, but together you're storing some stuff in a private field, like when I invalidate something, that's just another piece of state that you can modify and that will automatically invalidate the setup block and I think something that I spent a huge amount of time on and I'm proud of, but it's like hard to communicate because mostly people try to avoid it, is that React's strict mode makes it very very hard to have stable values. So if you're just doing this in Preact or Vue or something, pretty easy to have stable values and then StarBeam looks a lot like what you already expect. But in React, strict mode in particular tears down and sets up state constantly and so if you wanna be able to say like, I am reading from the stable value, I am having getter on it, it has its reference to this cell and it's not a use state, right? It's a special kind of thing. There's a lot of work that goes into making strict mode seem invisible, right? Like the TLDR is that you get a new instance of, when React tears down and sets up the component behind the scenes, like gratuitously, that actually does tear down and set up the resource but you can't tell that that's happening because it's all happening inside of the user resource and use reactive system.

So I'm like, I'm pretty happy with that and it basically means, I think what it means effectively is that we get to build something that is like solid. It has the same semantics solid but it is just happening inside of React fully within the semantics of React and interleaving just fine with React. I think that's pretty cool. And I think like what is awesome, I think in general what makes me like working on it is that the promise of React is kind of like, oh, you basically wrote the function as if you wrote it one time and then it like magically updates for you. But at some point you're not, like when you get deep at the hook land, you're no longer writing like the ORM you would have written on the server, you're writing some very specific React thing and it's complicated and hard. And like what I like about this and what I want for a start to begin, like what makes me happy is it gets you back that again, right, you can basically go, like if you look at the implementation of, for example, the users object, like what is, yeah, there's a resource here, but it's like a map, like you could literally have written this in, you could literally have written this in a node thing and it would make sense, it just wouldn't be Reactive, right, but now it is.

Okay, I think one last thing I wanna say here is, the resource API as I'm using it here is kind of going with the grain on how the ecosystem is doing stuff. However, now that's stage three decorator have landed, I intend to like, it's on the docket for me to implement a class-based version of all these APIs and there's a lot of cases where it's very nice. So like, I'll just show an example. So here we have a, where is, I don't actually have a great example in this case, but basically if you were going to put a cell somewhere, then you would be able to write like something like at reactive like user colon like equals something like colon users, like, and that basically that behind the scenes would make a cell for you and make a getter that reads from the cell and have a setter that writes itself. And I just find like personally, I sometimes like, like as you can see, I made a class here, it's not like you can't do it, but you end up having to do a little long end here and there's a, you get a nice set of behaviors if you can write decorators and I plan to do that. So it's not because I don't have an opinion, like I don't wanna put my thumb on the scale about which is better, I think I like what we did with this design. Like I like the fact that you, like this is pretty good. Unlike React it gives you the stable values blah, blah, blah but I like it, but I also like being able to use classes more ergonomically and that's coming.

Okay, I think I've covered everything. I don't know who MD is, but do you have any questions before I go? I don't know, do I have to, I might have to unmute you or I don't even know how that works. Do not follow that one. That. Okay. I see, you said. So StarBeam is just an API that fetches JSON data. That is not quite it. It's a StarBeam is an API that lets you create APIs that fetch data. But like, I think the important part is like, if you were going to write your own fetch logic, right. You write fetch logic and then you put it somewhere. And I started from the very beginning of like showing you, okay, you could put in a cell, you could build up abstractions from there. So that's the answer for what to do with it. I think it would be cool if people built like ORMs and stuff around it. There's some stuff in the repo, like there's something called StarBeam store that is just a tiny little store that has filtering and stuff like that. Yeah, I think that's what it is. I think in terms of Visual Studio, there's nothing to stop. It's like I need a release the packages. So there's packages that are already on MPM, but they aren't the API I just showed you completely. There's some changes. Once I released the package, it's just an MPM package. And we just like, what's happening? If you look at the code, it's like you are doing this. Assuming that Visual Studio has some of the same IntelliSense and TypeScript support that VS Code has, I think it will just work. Ah, okay, you don't use React. Okay, so I didn't cover that because that was not what I said in the tutorial. But the way StarBeam works is that this code, so this code we call universal code, not this code. So this code and this code, all the code that doesn't say anything about React, we call universal code. And universal code is just reactive code that describes everything. It has resources, it has lifetimes and everything, but it doesn't refer to any specific framework. And the way that you glue it into a framework is something called the renderer. So I spent a bunch of time showing you the React renderer. There already is a Preact renderer, and the Preact renderer works the same way, but doesn't make you type, use Reactive all the time, basically. There's also a view render in the repo, view.js, and there is a, there's a spell renderer that we built a long time ago we need to refresh, coming pretty soon also. But the basic idea is that you, like, the right way to use Starbeam is you, like, learn how to build this kind of code really well, you just think about everything, mostly in terms, like, you can build a whole data library without ever thinking about React, React, view, spell, whatever. And then when you're ready to use it, then you just say, like, use, blah, blah, blah. Like, you'll just go, like, like, here you're going to say, use Reactive or use resource.

In Preact you say the same thing, in view I think it's just, like, use parentheses. No, it's set up. And, like, there's, I, like, I don't, I'm not sure if I have it easily accessible, but, yeah, there's some, there's the setup. All right. Yeah, I'll just show you, I think this maybe will help. Hopefully I will have answered your questions. Okay, so let's close this and then, I'm just, that's not it, actually. There's a markdown document somewhere, looking around. Okay, let me just do the preview, do the assign. This is like a somewhat new thing, but it's like a 1.0 thing. So the idea basically is like, here's all the renders. And these are the APIs that work everywhere. But SetupReactive and SetupResource only work if you already are in a context that only, you need to already be in a context that runs, that you know runs during setup and not elsewhere. There's ways to do it in React, but in React you basically wanna use a hook. So there's like, there's basically something, like there's a section called hook style renderers and that has the hook style API. But the idea behind this document is basically we wanna have like, we wanna have one set of API style that works everywhere. And if you, basically the idea is this will be fleshed out and then you'll use the same basic API everywhere. And like our job is gluing it all together. But I think the cool thing is like most of the time, like, yes, let me... So I think like you should go to stardomjs.com although it's like a little outdated now and should be updated soon. I was missing something and then I should wrap up. So the thing I want to say is like when you get into Starbeam, like I said before, most of the work you do is on universal code, right? It's code that doesn't... Like you end up writing, like if you even look at this code, like 80% of it or something is universal code. And I think that the fact that resources allow you to like still have access to life cycle and stuff like that. And you can do it universally, and you can think of it as universal way of writing books, right, if you are a React programmer. There's a few other features that I didn't talk about and this I'll just wrap up after here. Like one, there's something called modifiers, which is basically universal way of writing code that plugs into elements. So that's like directives in Angular, directives in Svelte. I don't know what they're called in Vue. Refs in hook-based systems, right? So there's a way of doing that. And there's also called services, which is basically a way of having a singleton resource, like any resource you want having only one copy for an entire application. And like both, the services thing is already in, the repo already exists. I think it's even here. The modifiers is coming soon. Like it's gonna be in some future release, but like in the next few months. So basically our plan is to like try to get as universal as possible. So you can write, you can basically write libraries. The only place that you can't write a universal thing and it's out of scope is like the actual UI, because that's the thing that you were trying to use in framework, right? But like you're, that doesn't mean you can't access, like a modifier's a function that takes an element and returns a resource, right? And so like you can get pretty far down the road of like what you can do. You just, like we're not gonna have a angle bracket div syntax in Tarbin, but that's the point of React or svelte or Angular. Okay. I think that wraps me up. Thanks so much. Thanks for sticking it out and being one person, better one person than zero. Hopefully that was helpful. And keep an eye out for the website. I think the website should be updated in the next few weeks with like all of these detail in more clarity. And I'm gonna push the actual code that I was showing. Like it's in the demo that I just showed you was inside the repo. So I'm gonna push it like in the next few hours, probably you can go and check it out. I'll tweet it probably. All right. Thanks so much. Thanks for being here.