JS Nation

JSNation 2022

SolidJS: Reactivity Unchained

Hi, I'm Ryan Carneado, author of SolidJS, and today I'm going to present an introduction to it. What is Solid? It's a declarative JavaScript library for building user interfaces, like so many that have come before it. Solid on the surface at least is a very React-like framework. It values the same things. Unidirectional flow, read-write segregation, and immutable interfaces. It's built on the same building blocks, hook-like primitives, function components, and JSX. And it has a lot of similar features, things like portals and fragments, suspense and transitions, streaming SSR, and some others too that aren't in React, like custom directives and primitives for data fetching. And there is a but, a rather large one. Solid is sort of nothing like React. Solid's built entirely on fine-grained reactivity, similar to MobX and Vue. Its components only render once, and there's no virtual DOM. The whole mental model is completely different. Same values, entirely different implementation. But what does that actually mean? Well, modern front-end web development for years has been about components. Class components, function components, option components, web components. And for good reason. Components are essential building blocks that allow our programs to be modular and composable. However, in almost every JavaScript framework, they have runtime implications. The update model and the life cycles are tied to them. And this has led to basically two views of the world. Either you use a top-down diff, like a virtual DOM or tag template literal, or alternately, you rely heavily on compilation to separate creation from update. But both of these still have components that basically run top-down. And this kind of begs the question, when and what to memoize? This is important for performance, because if you're going to call something over and over again, you don't want to repeat the work. There's a great talk from Sean at ReactConf 2021 that addresses this exact thing. Your first inkling might be to build your to-do app in a framework like React, kind of like this. Declare some state and wire it up. But on any change, even unrelated to the to-do list, you'd be re-rendering the whole list. But maybe that's okay. That's why there's a virtual DOM, to make sure this isn't as expensive. But maybe you still want to optimize. As your program grows, you apply your optimizations, and things may start looking like this. Maybe you add a filter and some theming. And there's nothing innately wrong with this. But now we are annotating things with memo and use memo and use callback and adding our dependency arrays and ensuring that everything runs exactly how we want it to. But it's a bit of a departure from where we started. So let's compile it. And this might be what you'd end up with. To be fair, this is not the code you'd write. This is compiled output, kind of pseudocode from an experimental compiler that React team is working on. But it isn't actually all that different from what a framework like Svelte would be doing. It's a bunch of shallow referential equality checks that at every decision point rerun when your component is marked as needing an update. Common ground is a component update state, then runs an update function and checks against these memorized values, as shown here in this mem cache. But what if we didn't? What if we only ran what was needed to be run and didn't rely heavily on compilation? What if the boundaries of our components didn't dictate the performance of our web applications? To do that, we need to kind of go back to the beginning. And I'm going to go all the way back to the beginning. Remember the first program you wrote? Maybe it was a hello world. You were able to set some data in a variable and log it on the console. And it didn't take too long before you realized, well, you could set a new value to that variable and log it again. This is the beginning of programming. But then you realize, well, that's a lot of repetition. So let's extract that out into a function. Maybe a greet function here. And we can set our name and call greet and set our name and call greet again. And this is all great. But at a certain point, maybe you're like, every time I set the name, I want it to greet without having to call it. And that's where reactivity comes in. Reactivity is based on primitives. It's kind of like a promise in JavaScript. In our case, we're going to introduce the first primitive here. And it's called a signal. Signals are relatively simple. They are just a wrapper over a value. They have a get function name here and a setter, which is set name. And in this case, we have to replace this assignment we have here now with set name so we can update it. And we need to replace our name. We need to call it now because it's a function. And once we've done that, it basically acts the same. We can still see hello world and hello solid JS. That in itself, to be fair, is not terribly interesting. So we have another primitive we're going to choose here called create effect. And what effects are is they allow us to interact with our world whenever a signal changes. In this case, we're going to take our console log and we are going to put in the effect and have it listen to name. This lets us clean up the rest of this code, essentially. So now we just create our signal for the name and then create the effect. It runs once. And then when we set the name again, it runs again. And again, it does this because we call name as a function. It lets us intercept reading that value. And this can actually extend outside of the effect itself because this is not a compiler trick. This is completely runtime. So we can make a like uppercase. And now we can basically call our name in here and change it to uppercase, stick it in our effect. And because it's just using the runtime stack, we can see hello world and hello solid JS now in capital. So you might be wondering how this works. And it all comes down to this idea of fine-grained reactivity. Creating a fine-grained reactive library can be done in about 50 lines of code. I'm going to simplify it even further here for demonstration purposes. But it all starts with signals like we saw. And at its core, you just view a signal as a getter and setter function pair that close over a value. Of course, there's a little bit more to it than that. And for that, we're going to need subscription. So let's update our signals to do a bit more. Now on read, what we want to do is check if there's a current observer. And if there is, we're going to add it to a new subscriber set that we create when we create our signal. On write, we update our value still, but now we actually iterate over those subscribers and call them to basically notify them that something has changed. And that something that needs to be notified are our effects, which are the other side of our equation. Here you can see the implementation for get current observer. What we have is a stack. This context is just an array in global context. And we just grab whatever's atop the array to see what's currently running. For our effect itself, when it's created, it's executed immediately. And then it goes through the cycle of cleanup dependencies or subscriptions, push itself onto that stack, so that when we execute the provided function, it's there and can be added to the subscriptions. And finally, it pops itself off the stack. I'm going to put the code side by side so you can kind of see this better as we go over our example. So essentially, we create our signal, like our name signal, and it returns our read and write functions. Then, we create our effect. It executes, pushing itself onto that stack. Then it runs the function, and it reads from our name signal, at which point it sees the current observer, which is that effect, and it adds it to its subscribers. Then it logs it to the console, and the effect finishes running, popping itself off the stack. Sometime later, our signal is updated, which sets a new value, and then executes our list of subscribers. In this case, it's that effect, which executes it again, cleaning up the dependencies, and we just start the whole cycle all over again. That's really it. From there, we can build a foundation for other primitives. A lot of them are not essential, but can be used as needed. An example of a few important ones that ship with Solid are createMemo, which can be used to cache expensive computations, createStore, which is a proxy, which enables deep-nested reactivity, and createResource, which is our first-party primitive for data fetching and suspense. But enough on reactivity for now. Let's get back to our example. When we teach reactivity, we always use console logs, but let's do something a little more substantial here. Let's actually create a DOM element this time and see what it does. What we're going to do here is we're going to create a header, and we're going to set some text on it, and then we're going to attach it to the DOM. Then we're going to take setting that text on it and put it in the effects. Now, whenever the name changes, it will update the DOM. In this case, we set the SolidJS right away, so you don't even see it. We just see hello, SolidJS, because it updated right away. So to deal with that, let's create a button, and we'll put the setter inside a click handler. So we're just using vanilla DOM APIs here so that we can make it work, and there we go. Now our hello world has a greet button, and when we click greet, it changes it to hello, SolidJS. But, I mean, this is a lot of code. Who wants to write all that vanilla JS? Wouldn't it be great if we could just write something like JSX? And in Solid, you can, because JSX and Solid is just DOM elements. So this is a real HTML button element we're creating here, and we're just going to put a click handler on it, clean up that code, and our example still works. We can give the header the same treatment. The one difference here, though, is that the header has a reactive statement, and Solid's compiler can actually see that we're calling a function in the expression, so it knows to wrap it automatically in effect. And when we do that, sure enough, it still works, and it's a little bit cleaner here. But we don't really write our apps this way, so let's abstract this into a function or, you know, a component, so to speak. But this is just a function. We can clean this up a little bit and maybe return the elements as an array, and then we can just call our function and just attach it. And as you can see, clearly still works. But let's inline the JSX a little bit more, clean up a bit more, remove all that, and then format it with prettier, and here we go. Okay. We can actually replace the array with a fragment, because that's all fragments are in Solid, and this is starting to look pretty good. Last thing we really have to deal with now is just how we're attaching to the DOM. So Solid provides a render function, and we can just render our greet component, and there we are. This looks like any modern framework. But there is one big difference here. Solid's components only run once, because as you saw, we're just calling this function. So if I put a console log in here, like greet, let's say, let's say greet, and you'll see it log. When I press it, it's not logging again. It only logs once. Okay? So let's do that one more time. Okay? Here we are. Hello, world. See greet. Press it. Yeah. Only once. And, yeah, let's extend this a bit further. Let's actually use two greet components now. We're going to put this inside an app component that we use. And by doing this, you can see that each component can wrap over its own state. So now we have two of them. We can see that it logs the console greet twice now. But when we update each one, it doesn't log again, and they update independently, each maintaining their own state, because they have their own signal. But we can actually take this signal and pull it right out of the component above. And now it's shared, because both instances of the component are reading from the same variable. Like, it works in JavaScript. And sure enough, it doesn't matter which button you press, they update the same state, and the console logs only a log on creation, not an update. But most of the time, you're going to put this in props. So let's put this into app and pass it down as props. So we can also move the click handler up and pass it through as well. And this is kind of how composition works in Solid. The important thing to understand here, though, is only where that header text is, is it what actually gets updated. We are sharing the state passed here, but the components all only run once. So this app console log will show that even when we update it, it's not going to log it again. And actually, to make that more clear, I'm going to take this set name, and I'm going to actually have it increment differently for each component, even though it's using the shared state. Even though we're kind of passing everything through, when we actually do an action, there's only two effects on this whole page, and those are for both headers to update that text. Okay. So what's going on here? Well, it's because of the way we handle component props. In Solid, the only thing we actually transform is the JSX. And for components, when we see an expression that contains JSX or something that could be reactive, like a function call, we wrap it in a getter, like this get name. What this does is allow it to be evaluated lazily. It's very similar to what we do with DOM elements, where if we see something that could be reactive, we wrap it in an effect. Basically everything is lazily evaluated all the way to the final effect, which actually does the work. And, as I said, there's only two effects in that demo. The only work being done is updating that single text node inside each header. Nothing else re-executes. The last thing you probably need to know about Solid rendering is that we're dealing with real DOM nodes, and creation can be wasteful. So we need to do some special handling for things like lists. A simple array.map would never run over every item and map new results. And we don't want to create all new DOM nodes every time we add something to a list or sort it. So we need to do something a little special here. For Solid, we have helper functions, but we chose to ship them in the form of components. As they fit well with our patterns, and they are very composable, like the rest of the primitives in our system. What do I mean by composable? Well, pretend now we need to update this. We only want to show ten items on each page. We need to paginate. Luckily, someone has created this component for that. So what do we do? Well, maybe we import it, and now we just change our for component. And as you can see, it's exactly the same pattern. Lists become paginated or virtualized lists. Conditionals become layouts or suspense or error boundaries. It's all the same thing. You don't like Solid's for component. It's just a component. It's runtime. You can write your own. This is really powerful stuff. And armed with this, we can kind of return all the way back to the beginning with our to-do example. So I've recreated that example in Solid that we saw at the beginning. And we have a to-do list, and we have a handler that can... We have set up our state of our to-dos, and we have a handler that will update our to-dos to done. And what we've done here is we're actually passing in a visibility filter and a color picker. And this gets passed all the way through to our add to-dos to kind of set the theming. So this adds a little bit more complexity, or you'd think. But in Solid's case, without the need for adding any memos or use callback or dependency arrays or basically anything additional, we can just take our list, filter it based on that prop, and only have the things that need to update update. For example, when we click this three, yes, now we're going to update it to to-do. And when we unclick it, we update it. When we change the filter, it gets called. But as you can see, updating the to-do did not cause the filter to get called. And if we go back, well, we're going to have to recreate those three elements. So yes, we called the filter again, and we updated three times. But this prop getting passed through here for the theme color, us changing this doesn't cause the to-do updates or the filter to update. It just works. We did this all without any kind of memo. Actually, the hardest part about making this example was trying to show what updated, because so little does. This is what happens when you have fine-grained rendering and updates. For me, I call this the reactive advantage. Basically, components run once. There's no hook rules or stale closures or dependency arrays for that matter. Templates compile to real DOM notes. This is super low abstraction over the DOM. It means that you have that escape hatch. You need to do something with the DOM. It's right there. But most importantly, state is independent of components. Component boundaries are for your sake, how you want to organize your code. It's not about performance. The performance is good regardless. So if you want to experience the freedom yourself, maybe give Solveit a try. Thank you. This has been a presentation of Solveit.


Ryan Carniato

React Summit

React Summit 2022

5 Years of Building React Table

Tanner Linsley

Vue.js Live Conference

Vue.js London Live 2021

Modern State Management with Vue 3

Hi, now we are going to talk about modern state management with VUE 3. Hi, I'm Vanessa, you can find me online as Wanzel. I'm responsible for the frontend at SEVI. I'm co-host of two different podcasts, Expect Exception, where we talk about frontend testing and Working Draft, a German podcast about web development. And roughly a year ago, in September 2020, I can remember as I sat there watching Avenue on the VUE.js conference, finally saying, hey, VUE 3 is out there. And now I want you to go with me on the journey, how I installed VUE 3 and used alternative concepts to use VUE 3 completely without Options API and also without VUEx. I do not suggest that you should use VUE 3 without Options API or replace VUEx. I want to tell you that the Composition API is so powerful that we actually can use VUE without both of those tools. And it made sense for me in a state where I had a really small application, which I started with VUE 3 from scratch and did not have to migrate from a VUE 2 application. In the code examples I will show in the next couple of minutes, I will use the setup function. And I prefer to use ref over reactive. But everything I will show now, you of course can use the script setup syntactic sugar instead. And you can choose to use reactive instead of ref if you prefer to. And as my components of my very small VUE 3 application roughly a year ago started to grow because I had some more complex problems which needed some more complex solutions, I and therefore also this talk were mainly inspired by those three articles. Group extract share pattern, state management with Composition API, and should you use Composition API as a replacement for VUEx. Let's focus on three of the VUE's APIs for now. The options API, reactivity API, and composition API. The options API, we can think of this object structure that we know from VUE 2 single file applications, single file components, where we have our data, computed methods, watch mounted and many more. And the reactivity API is not that different of that. We have ref reactive for reactive data computed, watch, watch effect, unmounted, and many more. But the clue is that I can now import those functions directly from VUE. I don't have to use a VUE single file component or a mixin to use those tools. I can import them in any JavaScript or TypeScript file. And then the composition API is providing us with a setup function where I can bring all the magic together and use all of those powerful tools of the reactivity API in my VUE component. So let's have a recap of how to write a component in VUE 2 or in VUE 3 using the options. Here I have a template with a paragraph with greeting and full name. If I scroll down to my script block, I can see here that I have a data function, which is returning an object with greeting and hello. I have properties for first name and last name. And I have a computed property for the full name, which is returning me a first name with a space and the last name. So this is one component with just one purpose, which is doing its job quite well. Kind of a funny side note is that I initialized this greeting here as a reactive data attribute, although I actually don't ever change this and won't need this observers on it anyway. But I was never sure where to put this constants using the options API. The problem I now want to focus on is that logical units, if the component is growing and growing, are spread over the whole script block. So what do I mean with this? I've prepared this code sandbox here. And here we can see as well, we have our greeting and full name to say hello to the user. But then we also display the user's items where we loop over and also provide a delete item function to delete something. If I scroll down to the script block, I now want you to focus on the order of how things are happening. I have the data function, which is running an object with the greeting and items. The properties having stuff from the greeting, a computed property with the full name of the greeting, then a method with the function delete item of the items. So the categories bind to the way that the view skeleton, the view object here is structured. So everything in data is in data. Every computed property is in computed property. Every function is in the methods block. So now we have a point where we have now greeting items, greeting, greeting, greeting. So they are shattered over the whole file. And this is kind of grows and grows and grows looking like this. Of course, it can be a solution to split the component, but let's focus on it doesn't work anymore. We can't split any further and we still have this lines of code not really bind together. And what the composition API is providing us with is the possibility to group logical units together again so that everything is related to the greeting. We can imagine being in this light blue box on the top and everything related to the items, we can imagine to be bind together in this darkish blue, almost black box here. So the composition API enables developers to encapsulate logical units in one single file or in shared with others. What I mean with that, as I learned about the composition API a year ago, it always was sold to me as this is the go-to thing instead of mixing. Use the composition API to share functionality. It's really powerful. But then I started with Vue 3. I thought, but do I really need to share logic to use the composition API? Because I really like how it works, the composition API. And I actually like to use it also without sharing functionality. And this is exactly what we will do now. So I have created some Hello World files on this Vue single file component playground. And the first one is a reimplementation of just the greeting stuff we saw beforehand in Vue 3 composition API. So here we have our template with the greeting and full name. And we import computed from Vue. If I scroll down to the properties, I see the first name and the last name. And here below, I have the setup function, which is giving me a const greeting with hello and a full name as a computed property. And then I return everything to give it over to my template. What is kind of cool is that it's just JavaScript, right? It feels good to me. Actually, it felt a bit sweat the first time I saw it. So here we have the const greeting as just a pure const without wrapping it in a data object, not using a created lifecycle hook to initialize constance, just a const. And when we have a full name as computed property. But of course, also here, the functionality can grow a bit. We are switching to our Hello World 2 component, where I have also my items, which I also can delete. I loop over them in the template. And I have my method to delete them. I import computed and ref now from you. And if I now scroll down to the setup block, what we can see is the same implementation for greeting with a greeting and full name, and then a logical unit of the items and a method to delete the items. And as I started with U3, all of the time, my muscle memory was like, oh, yeah, I have to put everything data related in the beginning and then all of the computed properties and then all of the methods and then all of the lifecycle hooks until I remembered, no, no, I don't have to use this anymore. I can now bind the logical units. I can display them together. But then, of course, my component was growing a bit. And I was like, yeah, how do I actually say that these things belong together? Do we have a comment like start items block and items block? How do I achieve this? So I started to refactor this component a bit. The same template we saw before, but now on top, we have two different functions, the use greeting and the use items, which encapsulate all of the functionality in those function where I have everything related here and return the necessary properties to the outside. And if I scroll down to the setup block, I can now see that it's getting a bit more cleaner if it was getting a bit nasty. And I can outsource all of this logic to somewhere else. And here, I can clearly see, OK, I have the greeting and full name items and delete items coming from those two composables. But now the next step is, hey, it would be super amazing if I can use the use items also somewhere else because I really need this functionality also at another component, which leads us to Hello World 4, which is also refactoring a bit further. I only import computed now again from Vue and not ref anymore. But now I also import use items from use items. Switching to this file, I can see import ref from Vue on top in a plain JavaScript file. And the same function with the use items we saw just before is now an exported function in this file, bringing us all of the functionality as a composable in our Vue single file component. If I scroll down to the setup block, I can see here again I have my use greeting and the use item. I want to give you a small hint what I'm doing here. So what you can see here is that I first thought it is super cool to use ECMAScript destructuring to get everything related to the use items directly into the template. This is just one line of code. This looks super cool. But then a problem that occurred to me is that I don't have any IDE support here on this playground. So if I try to look for the delete item, I'm lost. I don't know where it's coming from. And therefore, what I tend to do is really to go the explicit way, to not use magic provided by a language by me, but really saying explicitly, OK, I import those things from there. And now I can see, OK, the delete item is coming from the use items, and the use items is coming from this file. So we already wrote our first composables. If you are looking for a bit more inspiration, check out this Vue Use Git repository where you can find already a lot of in TypeScript pre-written composables that you can use, Axios functions, and so on and so forth. I think it's also already Hektoberfest time. So also if you want to get engaged in open source, this could be a start point for you. OK, but now let's focus on state management. So how did I thought state was working when I started with Vue 2 in 2017 or something like that? First, I did the anti-pattern of props drilling. So I used props emit event handling to get something from a root component to its really like grand, grand, grand, grand, grand, grand, grand children to just emit, emit, emit, emit everything up again. This was not really maintainable. Then I thought I'm smart and I used the global root, the dollar root, to attach variables to this global root thing until I realized this is not working. This is not really reactive. I think I should really not use this. It was also not really discussed. It was just really hidden in the API documentation that there is something like a global root. And then I sat down and thought, OK, state management sounds important, sounds difficult, store sounds difficult, observables, VueX, I'm not sure, but I will install VueX now. And it was really just mind-blowing how simple this made it for me to create state management by only creating this index.js file. And already I had some state. It was a really powerful tool because it was so simple to use to then focus on the complex parts of writing code or finding solutions for bigger problems. But when I was starting with Vue 3, I thought, hey, give me a second. I think I can do achieve state management actually with composable. And it was really like, it was not because VueX wasn't ready for Vue 3 yet. They were pretty quick and there was a migration guide. But I was interested in what is everything I can actually achieve with composables. I want to get a step further here. And here I have another code sandbox, which will probably load soon. But I think I also have it preloaded here. Yes, I do. So here I want to focus first on the cart items, which we see here. And now I have a bit more of a realistic example. So if I reload this, you can see that there will actually be like three seconds of a loading time because usually I fetch the items from a server. So I have three seconds of loading. And then I see the items. And here I have a first item. So what I have to buy next are the eggs. And then I have my list of items. And here I really use now a state with if loading where I can set a loading state if it's still loading. And in the script part, I additionally use now the unmounted hook where I can fetch the data. So going to the setup function, we can now see the state with the items and the loading. And then I have the important function here are the load items where I set the if loading to true. Since I don't actually have a real endpoint that I can talk to, I use a use sleep function for three seconds. And then I set some dummy items, my eggs and my milk. And if everything works out, I can set if loading to false again. I also have my method to delete the item. And I have a computed property for the first item. And I use the unmounted lifecycle hook to load the items as soon as my component has mounted. OK, so far so good. We have something looking like a state, but it doesn't really feel like state management right away. So now I want to go to the app root component and switch to a different alternative of this application and use now two different components which are both providing us our items. So if I save this and reload, in the meanwhile, I will go to the cart items alternative, which is looking pretty similar to the favorites. So they are both just showing our items. So on the cart items alternative, I scroll down. And instead of the whole logic we saw beforehand, I can now see that I import the use items composable. And I get all of the necessary data from the state, load items, first item, delete item. And unmounted, I call the load items function. Now I can see here my three seconds loading. And I can see two times my list for my items. And here I want you to focus on the local state management. If I open the file, which I thought I had opened before, but I do it again for this composable, I can now see that the state here is outside of the component of this export function. And the rest of the implementation is the same one as before. It's just copied over with one important difference. So here I import additionally the read only keyword by view to have this store like of feeling of this composable, to have the single source of truth what we expect how a store should behave like. And now I want to put the state inside of this exported function. And if I'm doing this and wait for it to reload here, come on. And they are loading for three seconds. And I have my X, which I can delete in those local state. And here below, I can delete the fresh milk on those local state management as both the card items alternative and the favorites are both using this use items, which has the state initialized inside of this function. But if you think, hey, this is kind of weird, this is not what I expect from state management. I expect it to be global. This is achieved by just moving the state on top of the export. And I will reload this again. And then you can see that, therefore, I just created the state now once. It's no global. It doesn't change. We don't initialize it a couple of times. We just export this function a couple of times. So after I installed all of those dependencies, you will see that I can now delete the X and they will be deleted twice. So they are loading. And global state management. And the next point, if you think, hey, this is not looking like I would expect like a store really to look like, you can also use an alternative to this alternative. You can use the provide and checked pattern, which was already given to us at view two. And this is this code sandbox where I start with the app.vue root component. And you can see here that I import a store and I import a hello world. And I register the component hello world and I provide the store. What is the store? Let's have a look at the store at the index.js file here. So in here I have computed ref and read only where I have my state, a first item, a computed property, which is looking like a getter. And then I have functions that looks like a setter. And just out of fun, I called them set items in this uppercase syntax. And then I export for the state, which is read only my getters and my setters. So this should feel more like the view X way, the store way of doing things. And if I check out my components, I can go to hello world where I actually don't have any knowledge of the store at all, but I registered the child one. And in the child one, I import and checked from view, scroll down here and I in check the store and I can use the store in this child component using provide and check pattern and delete my data and my items here because I finally bought them. And this is also a global state management. So if I would inject the store in some other component, it would still work. So that's everything about the state management in view free using composables. Thank you very much. See you later.


Vanessa Otto

Taking Vue.js to the Backend

Hello and welcome to my talk about taking Vue.js to the backend. My name is Marc, I am a self-employed software developer based out of Luxembourg. I work a lot with Vue.js and Nuxt, also with Node.js in the backend. And I have a podcast, it's called Decoding the Code and you can always find me on Twitter. I'm quite active there, so if you have any questions or raising up from this talk, just hit me up and I will follow up with you of course. So yeah, Vue in the backend. You might think yourself, are you insane? Why would you do that? So yeah, a quick disclaimer, this talk is not about a very production way of how to build Vue backend things. It's more of a thing of how to provoke the thought for some things we could use Vue in the backend for and this is Vue reactivity. And I got the idea for this talk earlier this year and I even tweeted about it. I wrote to Evan Yu, hey Evan, do you see any problems using Vue 3 reactivity engine in a Node.js backend? And I was glad that he replied, so he wrote, just be mindful what you want to make reactive. The API defaults to deep reactivity because that makes more sense in the browser environment, but in Node.js you'd want to avoid deep proxying node, node buildings. Make sure to use shallow ref and shallow reactive. So yeah, so we basically have the thumbs up from Evan Yu to do this. And I got another reply from Alexander Lichter. He actually pointed me to that Oscar Spence had a talk about it in Vue Conf US. He wrote this totally great talk by Oscar Spence about Vue 3 reactivity in the backend context, which was exactly what I wanted to do. So some of this code that I'm going to write today is inspired by Oscar Spence's code, a little bit different, but the idea bases a little bit on his talk. So thank you Oscar for the groundwork you made for this. All right, so we want to use Vue 3 reactivity in the backend. So before we get to that, we first have to know what is reactivity really. So reactivity is when you change one thing and you update it wherever it's needed. So in order to do that, we need to listen to changes and we need to notify when a change happens. So we can do something that's called an effect, a side effect, something that should happen when something changes. For example, a number value changes from 3 to 5, so the slider has to be on another position, for example. All right, so yeah, this is the observer pattern. So Vue 3 reactivity, in Vue 2 we use the object.define property and in Vue 3 we override the getters and setters for object properties by leveraging the magic of ES6 proxies. And we are going to go a little bit deeper into that. So what's a proxy? So if you create a proxy from an object, by default it behaves the same way as the object. So for example, if I write a value to this, it writes it to the object, to the target, and also when I read from it, it returns the value from this target, so it behaves exactly as we think it should work, which is great. But proxies have a superpower, and this superpower is that we can intercept these two hooks, as it's called, set and get. Of course you can intercept more hooks, but these are the two that are interesting for this use case. So you can write whatever code you want to replace the setter and getter methods with. And in the demo we are going to see what we do with this. So yeah, let's get this party started, or better, let's get this live demo started. First starting with getting a little insight into ES6 proxies, and then we are going to make a little live demo where we see how to implement some Vue.js backend. So let's see. Alright let's get started with proxies. To show you how it works, I will just create an object first, it's called person, and this person has a name, mark, and it has an age of 34. And we create our proxy as such, new proxy from person, and it expects a second argument, which is called a handler, and we are going to see in a bit how that works. But for now I can play around with this on this side of the screen. So let's just see first what's in there. So it's this proxy, and what we passed here. So nothing spectacular so far, but when we go there now and say proxy.age is 35, it sets it to 35, and when we read it again, it actually updated. So this is pretty much what we expect, how it should work, and that is how the proxy is shipped by default. But we can modify the proxy by overriding some so-called traps or functions in this handler. So the getter function, it takes two arguments, target and key, and let's just see what it is, console.log target, target and key. And let's see. So this is invoking the get method. So here we can see it logs out what we wanted to log out, the target. Now we can see what is the target. The target is nothing else than the real object, and the proxy is just the front of that. So this is what is in the back of the proxy, if you will. And the age is the key we want to get, so in this case age, and when we say the name, well it says name, perfect. So let's just call this here get, so we see what we're working with. And you might have noticed that it always replies undefined. Why is that? Well, because we're not replying anything. I told you we can completely overwrite these functions, but now we broke it, so we have to re-code the functionality. So what we're going to do is we're just going to return the target with the value key. Let's see if that worked. Like a charm. Perfect. Now let's overwrite the setter. Setter takes one more argument, value. So let me just be lazy and copy this. Set key to value. What happens when we set the name to Jimmy, for example? Yes, set, and then name. What do we want to set the name and to which value? To Jimmy. So now when we output the name, it didn't change. Why? Because again, we didn't set it. We just overwrote our original function and broke it. Okay, let's fix that. Let's set the key in the target to the new value and let's try again. Name is Jimmy. And then when we try to read the name, hey, it updated. Perfect. Now we intercepted these functions, but what should we do with it? In view reactivity, we do something like, in the get, we track. Do something that's called track. And here in the setter, something that's called trigger. Well, it's actually, we pass the target and the key here. So what this does is the track is, so we noticed that there's something that in effect, something that wants to be observed. So we just take it in and we write it in as a dependency. And then when something changes, when we set a new value, we trigger that. So we tell the system, hey, something changed here. But that goes all way too deep. And I have another conference talk, various conference talks about this topic where I go a little bit deeper into the view three reactivity. But for now, this is enough. Also in the real version of view three reactivity, we don't use this. We use something called reflect to solve some caveats, but I'm not going to go into that too much. But because we are looking at something different now. So yeah, view three has a function called reactivity and it's more or less something like this. Function, it's not called reactivity, it's called reactive, sorry. So we pass here target. And what do we do with it? Yeah, we just make a proxy out of it, just like this. And we return the proxy and it's not the person, it's the target we pass. So now if we want to make an object reactive, all we have to do is reactive this. Okay, let's try it out. Let's go. All right, let's go ahead and get the value. For example, the age. And yeah, so it invokes our get hook where we lock things out and in the real version of view reactivity, we track. So we tell the system, we want to know when the age changes. And then when it does change, we trigger it. So we tell the system, hey, this changed and then do your thing and execute that side effect that needs to be done. All right, so this is proxies. Now we're going to move on to some demo where I'm going to use all of this in the backend. All right, this is my backend, nothing impressive going on here. It's just my express server, boring, and three routes that I work with. One is join, leave, and message. They also replicated to in my rest client, it's called insomnia. Login is just passes the username, message, which username and which text, and then we leave and again, the username. So there's no identification here. There's no real interaction with real users. Those are all stuff that we have to imagine that will be added later. But for the moment, let's just focus on the reactivity for this one. All right, so the first thing we have to do, we have to add actually Vue.js in our backend. How do we do that? Well, yarn add Vue.atNext. If you do Vue.atNext, it's version three. All right, it's installed. Perfect. Let me hide the sidebar. Perfect. Okay, so let's first import a few things that we need. Require view. And what do we need? We need the reactive function we saw earlier. We need effect. We're going to come to that later, what exactly that is. And we might use a computer property. All right. So far so good. And let's create a reactive array that's called users. Users is reactive, and it's an empty array to start with. All right, so far so good. Nothing happened yet, because we didn't write any real code yet. But let's start by join. When we execute this, we want to add this user to the array. So this is the easiest part. We just go users.push. And what do we push? The body of our request. All right, which is exactly this. So just the username. All right, when we do this now, nothing really happens yet, because we're not reacting to it. So that's our first effect. And so I told you I would explain what this effect does. But to do that, let me write the effect first, and then I'll explain this. So here we console.log usersChanged. And let's just go to the length of the array. So when we go there now, we say usersChanged 1, 2, 3, 4, 5. So this effect, how it works is you pass a function here that if something inside this function changes, then execute the function again. So it might seem a little bit complicated, but that's the easiest way to put it. If something inside a function changes, execute it. So in this case, the length of usersChanged, so it's executed. So it's an output. All right, but we don't want to access here only this. We want to do something like this. User this and this joined the chat, right? And it's going to be something like user.username. We just have to get the user first. So the user is going to be the last one in the array, because yes, when you push something to an array, it's on the last position. This is convenient for us, because it's an easy thing to do. We just access the index of length minus one. And here again, because here we access the length of the user, this is executed when it changes. So hopefully this works. It did not work. Why? Because username of undefined, of course, it's undefined at the beginning. So we have to make a small check here. If there is no user, just return and ignore the rest. All right, let's see. Okay, now it works. Then we send the request and bam, it worked. This is perfect. So the user mark joined. Awesome. Now to leave, that's the next thing we're going to code. How when a user leaves. And this is a little bit more tricky, because we're going to do something a little bit more unconventional. So let's say the username, we have something like this, right? What we do is we set the leave to true. So this user is leaving. And then our effect is going to catch that and it's then going to set left to true. So we know when a user wants to leave and then we know when the action is completed. So that's what we are going to do. So first we need to use that's leaving and we are going to do it like this. The user is, we find a user where the username is the same as we pass here in our request body. So request body, come on, body username. And also if they haven't left already. So we filter out the ones that have already been marked as left. And then again here, we might run into some trouble if there is no user. So if there isn't a user, just do nothing and if there is, set the user leave to true. All right. So yeah, this is going to find the user with the, what the username is the same one as we pass here and which hasn't left yet just on what he wanted to leave, but the operation isn't completed yet. So to do that, we create an effect and here we are going to do the following. I filter the users for users that are leaving, leave and, but not that haven't left yet. So and not left. And for all of these, we do the following. Let's go in the next line. We set the left to true and we log out the user, this and this left, and this is going to be user.username. All right, let's try it out. Let's first join, mark join. Perfect. Mark left. Perfect. Again, not working because there's none in the list. Okay, perfect. All right. The last part is to send messages for that we need another array, a reactive array messages. And here we need to add the message messages.push request body. Awesome. And then we need a similar effect to the ones we had for the users. So I will just sneak that and I will replace user for message and we are going to log out another message. So we put the user in parentheses and then we write the message. So it's message.username. Awesome and then message.text. Okay let's try that. Let's log in. Works. Let's send a message. That works as well. Awesome. And let's leave. Awesome. All right, unfortunately we are done. I would have loved to show you a lot more, for example, computer properties, but that's just not in a time. But this is how we could use Vue.js in the backend. Of course, this is not how you would exactly implement the chat, but just to visualize or to show you what is possible with Vue in the backend. With that, thank you very much for your attention and of course for not falling asleep. And if you have any more questions about this, make sure to send me a DM on Twitter. I will respond to you and yes, have a great rest of the conference.


Marc Backes

#reactivity