Build a Universal Reactive Data Library with Starbeam

Rate this content
Bookmark

This session will focus on Starbeam's universal building blocks. We'll use Starbeam to build a data library that works in multiple frameworks.

We'll write a library that caches and updates data, and supports relationships, sorting and filtering.

Rather than fetching data directly, it will work with asynchronously fetched data, including data fetched after initial render. Data fetched and updated through web sockets will also work well.

All of these features will be reactive, of course.

Imagine you filter your data by its title, and then you update the title of a record to match the filter: any output relying on the filtered data will update to reflect the updated filter.

In 90 minutes, you'll build an awesome reactive data library and learn a powerful new tool for building reactive systems. The best part: the library works in any framework, even though you don't think about (or depend on) any framework when you built it.


Table of contents

- Storing a Fetched Record in a Cell

- Storing multiple records in a reactive Map

- Reactive iteration is normal iteration

- Reactive filtering is normal filtering

- Fetching more records and updating the Map

- Reactive sorting is normal sorting (is this getting a bit repetitive?)

- Modelling cache invalidation as data

- Bonus: reactive relationships

66 min
14 Jun, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

StarBeam is a standalone reactive library that can be intermixed with React. It provides reactive versions of JavaScript built-in collections and allows for dynamic arrays of counters. StarBeam also introduces the concept of remote data API and offers features like invalidation and error rates. It handles errors and reloading, filtering logic, and stable values. StarBeam can be used with various frameworks through renderers and aims to be as universal as possible.

Available in Español

1. Introduction to StarBeam

Short description:

I have a bunch of little mini tutorials that I'm going to walk through. There's a few different ways to think about StarBeam. It's a standalone reactive library. I focused on intermixing StarBeam with React. The first step is a standard counter example. 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. The most fundamental unit of reactive state in StarBeam is called the cell.

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.

2. Using useReactive and React State

Short description:

When you use the useResource hook, it will give you the same value every time. Use the useReactive hook to interact with StarView state. It works with React strict mode as well. If you forget to use Reactive, you'll get an error. The hello counter and incrementer examples show how StarBeam works with React state.

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.

3. Implementing Dynamic Array of Counters

Short description:

We want a dynamic array of counters. StarBeam provides reactive versions of JavaScript built-in collections. We create a reactive map called counters. We implement the list, remove, and add functions. The counters.add function ensures a fresh ID every time. The counters.list function spreads the values of the counter. Clicking the button triggers counters.add. The counters.list function maps over the counters and calls the hello counter function for each counter.

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.

4. Using Reactive Maps and Arrays

Short description:

The important part here is that the counter.count goes here. So that's the 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. 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.

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.

5. Using useReactive and React State

Short description:

The date example allows you to select a time format and updates the output accordingly. A new resource called a clock is introduced, and setup and teardown are explained. The setup block sets up an interval and updates the value of the cell. The object returned at the end has a format method that uses intl.dateTimeFormat. The useReactive hook is used to display the time using the format method.

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.

6. Using clock.format and demonstrating invalidation

Short description:

When you call clock.format, there are two pieces of ReactiveState that can change: the time format and the date format. The ticking clock is also changing. The select style is extracted into its own component, allowing for easy intermixing of React and StarBeam. The example demonstrates invalidation and how the setup function provides a stable value. The console log shows that setting up gets called again when the speed is increased, but not the resource. The value obtained from useResource is guaranteed to be the same. The next step is to make the navigation bar work in a smaller window.

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.

7. Working with User Profiles

Short description:

This value is tracked. If you say I want to choose an index, all it does is set the index on the cell. Let's look at how it works. If the current user is undefined, then it says invalid user ID. Otherwise, it invokes the profile component. It's basically just an input field that I wrote. Whenever the number updates, then we call user.choose. The choose method sets a value. You can do whatever any normal JavaScript works. A huge percentage of what's going on here is normal React stuff. It gives a lot of benefits.

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.

8. Introduction to Remote Data API

Short description:

We're now getting into the actual data API. I made a simplified version of a remote data API. It will be explained further later.

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.

9. Introduction to Remote Data

Short description:

So what is remote data? It takes a URL. FetchData takes a board signal. If the result is OK, then we await JSON. On setup, we make a new abort controller. We catch any errors and set the status to error. Otherwise, we just return the whole data. We call remote data. 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. We can build a reactive piece of reactive loading state, handles abort correctly, handles strict mode tearing things down, and all that. We would like to be able to store multiple of them, like keep them in memory. There's a text field with a number between 1 and 10. When you initially load, there's no items in it.

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.

10. Working with User Items

Short description:

I made a user's resource, just like I made the counter resource before. Every single API in StarBeam has a place to put a description. We returned a map, the map which is the actual map. If the map doesn't have an ID, then we're going to call the resource function. OK. So let's see. The current ID is just the standard use date. We get the users as a user resource. The field just changes the current ID. We're just going to call users.all. A user item takes an ID, a resource, and a select callback. When you click on it, it is just going to call select with the ID.

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.

11. Handling Errors and Reloading

Short description:

And if you want to get a sense for it, that's what this is doing. The user name component takes an async API user. The class name, if the status is an error, it's error. 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. 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. 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.

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.

12. Enhancing Error Handling and Data Reloading

Short description:

I wanted to handle errors and reloading in StarBeam. One out of every four times, an error occurs instead of a result. The data can be reloaded by clicking on it, and it displays 'refreshing' while loading. This functionality is achieved using normal JavaScript code.

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.

13. Adding Features to Remote Data

Short description:

I added features to remote data, such as invalidating data and error rates. A marker is a special kind of reactive state that allows validation. The remote data API takes a marker as an option. If the marker is called invalidate, it reads the invalidator and cleans up and resets the setup block when marked as dirty. The piece of data returned has another state indicating validity. The error rate returns an error based on the specified rate.

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.

14. Exploring Statistics and Refreshing Data

Short description:

There's a lot more code here, but 95% of it is stuff we probably already knew how to do. You can basically just keep following your nose on the reactive stuff and it works. The refresh button calls and validate, which just calls mark. Reloading is determined by the status, and mutations should be done in an event handler.

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.

15. Filtering Logic and Stable Values

Short description:

I added a filtering logic to the abstract and wrote a new filter using getState. The matches method checks if the user matches the filter. Changing the underlying value inside the map is sufficient to make it appear or disappear. The current ID is plugged into a normal React field, driving the update of the user. React's strict mode makes it hard to have stable values, but StarBeam handles it by automatically invalidating the setup block. The TLDR is that React tears down and sets up the component, but it's all happening inside the user resource and use reactive system.

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.

16. Using StarBeam with Frameworks

Short description:

StarBeam is an API that lets you create APIs that fetch data. It works with React and other frameworks through renderers. The universal code is reactive and doesn't refer to any specific framework. The renderer glues the code into the framework. There are already renderers for React, Preact, and Vue. The right way to use StarBeam is to learn how to build code without thinking about any specific framework and then use the appropriate renderer when ready.

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.

17. Exploring Starbeam Features

Short description:

In Starbeam, most of the work you do is on universal code. Resources allow you to have access to lifecycle and write code universally. Starbeam also offers features like modifiers and services. The goal is to be as universal as possible, allowing you to write libraries. The UI is the only place where you can't write a universal thing, but you can still access and modify elements. The website will be updated soon with more details, and the code will be available in the repo. Thank you for being here.

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.

Watch more workshops on topic

JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)
React Summit 2022React Summit 2022
161 min
Web Accessibility in JavaScript Apps
Workshop
Often we see JavaScript damaging the accessibility of a website. In this workshop, you’ll learn how to avoid common mistakes and how to use JS in your favor to actually enhance the accessibility of your web apps!
In this workshop we’ll explore multiple real-world examples with accessibility no-nos, and you'll learn how to make them work for people using a mouse or a keyboard. You’ll also learn how screen readers are used, and I'll show you that there's no reason to be afraid of using one!
Join me and let me show you how accessibility doesn't limit your solutions or skills. On the contrary, it will make them more inclusive!
By the end, you will:- Understand WCAG principles and how they're organized- Know common cases where JavaScript is essential to accessibility- Create inclusive links, buttons and toggleble elements- Use live regions for errors and loading states- Integrate accessibility into your team workflow right away- Realize that creating accessible websites isn’t as hard as it sounds ;)
Node Congress 2021Node Congress 2021
128 min
Learn Fastify One Plugin at a Time
Workshop
Fastify is an HTTP framework for Node.js that focuses on providing a good developer experience without compromising on performance metrics. What makes Fastify special are not its technical details, but its community which is wide open for contributions of any kind. Part of the secret sauce is Fastify plugin architecture that enabled developers to write more than a hundred plugins.This hands-on workshop is structured around a series of exercises that covers from basics "hello world", to how to structure a project, perform database access and authentication.

https://github.com/nearform/the-fastify-workshop
React Summit 2022React Summit 2022
51 min
Build Web3 apps with React
WorkshopFree
The workshop is designed to help Web2 developers start building for Web3 using the Hyperverse. The Hyperverse is an open marketplace of community-built, audited, easy to discover smart modules. Our goal - to make it easy for React developers to build Web3 apps without writing a single line of smart contract code. Think “npm for smart contracts.”
Learn more about the Hyperverse here.
We will go over all the blockchain/crypto basics you need to know to start building on the Hyperverse, so you do not need to have any previous knowledge about the Web3 space. You just need to have React experience.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Top Content
Interactive web-based tutorials have become a staple of front end frameworks, and it's easy to see why — developers love being able to try out new tools without the hassle of installing packages or cloning repos.But in the age of full stack meta-frameworks like Next, Remix and SvelteKit, these tutorials only go so far. In this talk, we'll look at how we on the Svelte team are using cutting edge web technology to rethink how we teach each other the tools of our trade.
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
JSNation 2023JSNation 2023
28 min
SolidJS: Why All the Suspense?
Solid caught the eye of the frontend community by re-popularizing reactive programming with its compelling use of Signals to render without re-renders. We've seen them adopted in the past year in everything from Preact to Angular. Signals offer a powerful set of primitives that ensure that your UI is in sync with your state independent of components. A universal language for the frontend user interface.
But what about Async? How do we manage to orchestrate data loading and mutation, server rendering, and streaming? Ryan Carniato, creator of SolidJS, takes a look at a different primitive. One that is often misunderstood but is as powerful in its use. Join him as he shows what all the Suspense is about.
React Summit Remote Edition 2021React Summit Remote Edition 2021
43 min
RedwoodJS: The Full-Stack React App Framework of Your Dreams
Top Content
Tired of rebuilding your React-based web framework from scratch for every new project? You're in luck! RedwoodJS is a full-stack web application framework (think Rails but for JS/TS devs) based on React, Apollo GraphQL, and Prisma 2. We do the heavy integration work so you don't have to. We also beautifully integrate Jest and Storybook, and offer built-in solutions for declarative data fetching, authentication, pre-rendering, logging, a11y, and tons more. Deploy to Netlify, Vercel, or go oldschool on AWS or bare metal. In this talk you'll learn about the RedwoodJS architecture, see core features in action, and walk away with a sense of wonder and awe in your heart.