You’ve built apps with frontend frameworks before? - Then you surely came across the terms ""declarative"" and “reactive”. Since React got released in 2013, most modern UI frameworks or libraries want to be it, but what do these terms actually mean? And what’s the difference between “declarative” and “imperative” code?
It took me a long time to grasp these concepts - but when I finally did, I saw frontend frameworks in a totally new light! And I hope you will feel the same after this talk.
In this very interactive workshop, we’ll delve into a lot of code examples to deeply understand the terms - with examples using vanilla JavaScript, React and Svelte. But the learnings will be universal. After this talk you’ll be able to confidently join discussions about the ""declarative"" and ""reactive"" nature of any new package or library.
This workshop explores the concepts of declarativeness and reactiveness in front-end frameworks like React and Svelte. It discusses the challenges of working with the imperative approach and the benefits of moving to a declarative approach. The workshop also covers the implementation of derived values and conditional logic in both React and Svelte. It concludes with a discussion on Flutter and the advantages of declarative and reactive code in modern UI frameworks.
1. Introduction to Workshop and Speaker
Short description:
This workshop will dive deep into the meaning of these words and provide interactive exercises. You will gain confidence in using these words, discussing frameworks, and understanding pros and cons. We will explore the difference between the imperative and declarative approaches using a room cleaning example. The left-hand side represents the imperative approach of giving exact instructions, while the right-hand side represents the declarative approach of describing the desired state. I am a freelance software engineer with experience in React and React Native, teaching, and providing workshops.
So that's what this workshop is about. And you heard these words a lot, probably you read them a lot, maybe you know more or less what they mean. But we want to really dive deep into what they mean with interactive exercises, so that you can then really use these words with confidence, talk about other frameworks, about pros and cons, and yes, just be part of the discussions.
Everyone of you has been a kid at some point, and maybe you have kids, but there is a situation where you just need to have someone tidy up their room. And in such a situation, what could you do? How could you get someone to clean up this mess? So basically, you could do two different things. You could say exactly what to do. Go pick up the toys, then empty the bin, then remove the dust, then do this and that and so on. Finally, vacuum the floor, and exactly telling the person what to do. Or what you could do. Probably that's not what's done, but for the sake of my example of what we will be talking about, you could say, hey, here's a picture of your room in the way if it looks clean. And here, you have 30 minutes to get the room into this clean state. The left-hand side, you can already guess which of these sides is the imperative approach, which of them is the declarative approach. What would you say? So you can just answer me here or in the chat. Perhaps here in the Zoom chat? Right now, I cannot see the Discord chat while I'm sharing this presentation. So, what do you think is the left-hand side of the imperative or the right-hand side of declarative or the other way around? Is the right-hand side imperative and the left-hand side declarative approach without having defined, you know, the things yet just to see what you already know or do you think?
So, now we get some answers in. Here we see the first one, left is imperative. The one on the left is imperative, left imperative, right declarative. Yes, that's exactly the way. Imperative voice, you know, of exactly telling someone, giving exact instructions of what to do. That's like an imperative way to clean up the room. And the declarative one of describing, you know, the state in which we want the room to be. And then having the kids in this case, figure out how to get there themselves. So, yes, imperative and declarative.
So this we will be talking about just a few words about me. So I'm a freelance software engineer. I build mobile and web applications with React and React Native. And I began with these technologies in 2015, when React Native released the iOS version. And in addition to my engineering work, I also teach and give company trainings. I'm active on Stack Overflow and sometimes do workshops as part of conferences.
2. Exploring Declarativeness and Reactiveness
Short description:
We will explore the meaning of declarativeness and reactiveness in modern front-end frameworks. Additionally, we will investigate how the browser and app state interact and how to improve the developer experience with reactiveness. We will also discuss declarative interfaces and transition from vanilla JavaScript to React and Svelte frameworks, with hands-on tasks in each.
Yes. So also again, in some motivation, while we're here. Yes, the term declarativeness also Reactiveness, they pop up in a lot of different places and documentation and we want to see like deep, understand it in a deeper sense what it actually means. Okay. Because, yeah, modern front-end frameworks, they all say they are declarative and reactive, that's how you want to build front-ends, but we want to also now investigate why. So, we will have a look at the browser and the app state. So, how does the browser and the state in the app we are coding interact? We want to then see how we can improve our web development experience, the developer experience with reactiveness. We want to then look more at the term declarativeness and how use interfaces can be described in a declarative manner and also, more concretely, then moving away from vanilla JavaScript, which we'll be dealing with in the beginning, to frameworksReact and Svelte. And so, you will have some hands-on tasks in vanilla JS, React and Svelte.
3. Exploring Imperative Approach and Challenges
Short description:
We will begin with a vanilla JS counter and explore the imperative approach of directly manipulating the document object model. We'll discuss the constant value synchronization and the challenges of keeping the app state and UI state in sync. Additionally, we'll examine how JavaScript interacts with the browser and the role of the document object model in rendering the user interface. We'll also address the question of why working imperatively is not optimal and explore the issues that arise from this approach through practical exercises.
And you don't have to already know Svelte and it'll be simple examples, but really just to bring home the knowledge of these terms.
Okay, so let's begin with our very first task of just a vanilla JS counter.
Okay, so what could this look like? Eventually, we're just a function here. I created called it, update, which takes in a value and then just renders this value, really updates the document object model with the value given. Now, it's really hard coded. Yeah, it's kind of update, like, always updating this one HTML header here. But basically, this second step, this update step, that's a step we don't have to worry about anymore using modern UI frameworks. Yeah, this is a part they want to kind of do for us.
So, let's have a look at first a little bit of what the browser actually does here behind the curtains. And I'll share. No. Okay. So, you can now see the slides again. Yeah. Okay, cool. Yes. So, I also try to not miss the questions. So, I have more an eye on the Zoom chat right now. Okay. So, if you have any questions, please post them there, not in Discord while sharing. Oops.
So, what we continually have to take care of in this imperative approach of directly kind of grabbing the document object model, getting an element and changing the value, we have to take care of this constant value synchronization. We have to make sure that the state always translates to the thing we also see on the screen, which is in the DOM, so to keep hold of the app state and the UI state. Yes, that's already what we did to update function.
How does JavaScript actually interact with the browser? Here's a small thing I drew to look at it. We have our app, which basically first has HTML for the structure and CSS styles and then some JavaScript code. As we see, the JavaScript can have like has hold off document object model via this document variable. But before the JavaScript comes into play, we are sending the HTML to the browser. And inside the browser, we then have the HTML showing up. Inside the HTML code, we have probably some scripts attached, some JavaScript scripts, which are then read. And via these web APIs, which you see here in the middle, we have access to the document object model, we have access to events, things like set timeout, set interval. These are things the browser provides us as developers via web APIs. But when we now follow the path of the document, the DOM, document object model, we see that the DOM kind of which I drew here is kind of this tree-like representation of our user interface, which is then translated into the pixels you then see on the screen, sorry, which you see here on the right-hand side. Hidden also inside the browser is also the CSS ARM. This is kind of a tree-like representation of all the CSS we have. And all of that is powered by the JavaScript engine, which is running in our browser. And that's, for example, V8 if you have Chrome. So that's basically the browser. And we see we have to constantly interact here Yeah, between these two things. So that's what I just said. The JavaScript engine reads the HTML, creates the document object model out of it. And this is basically then our HTML file and how it gets translated into the DOM, into this JavaScript object. And the engine then uses the DOM to render the user interface. And here again with rendering, I mean really the graphical rendering of something, of a data structure to pixels on the screen. And our JavaScript code can then constantly update the document object model with these web APIs, where we specifically use document object. So yeah, this is this constant synchronization, which we have to take care of if we work imperatively. And the question is why is this not optimal? So, or like, yeah, what can you think? Like what can you tell me? Like why? Yeah, what are issues with working imperatively? Like in this small example, it worked out quite fine. Like we, okay, we grabbed the element and we made an insertion, okay. Oh, let's maybe, let's then find out. Okay, I prepared some exercises where we will stumble upon these issues.
4. Understanding Reactivity and Manual Syncing
Short description:
Reactivity is when changes in one field automatically trigger changes in another field without explicit instructions. In JavaScript, copying a primitive data type creates a separate value that won't change with the original. This manual syncing is required to keep the value of the state in sync with the value in the DOM. Working imperatively requires constant manual synchronization. An analogy is drawn between the bond between a mother and a baby and the need to update the bond as the baby becomes independent.
So, let's talk about the reactivity. And, a little bit. So, what is reactive? Yeah, an Excel sheet is reactive. When I have some formula arranged, like here, I change the date, boom, I change one field, and then via the formula, another field changes. That's reactivity. I don't have to explicitly then say, yeah, okay, if this field changed, then please change the other. I just describe the formula, and it will then make the changes as soon as it sees there's some other field is changing.
And we want to, for example, and here's a small illustration of what that actually means if something is reactive. I'm here in Visual Studio Code, and I am using a small, oh, am I sharing? Yes, you see Visual Studio Code, okay. And I'm using a small plugin here which is called Quokka. Maybe you already know it. Like it's an extension, Quokka is the name, and that's really cool for such live demos because I run it here and you see here in blue, it directly shows me the output inline. I don't have to run node.js separately, but it directly shows me output. And so this is like, I'm having here a value which I declared and assigned. And now I wanna create a reactive value. So let me just create a copy. So I have the count copy equal to count, and I want to also here, with my count copy. But, so what happens? So here I have my copy, then I reassign the value of count. Count copy still remains zero. Yeah, that's, of course, here, that's what we expect because in JavaScript, of course, here this count, sorry, the number is a primitive data type. And of course, if I copy a primitive data type, it's copied by value. And then, of course, the count, although I changed the count, count copy is a separate value and won't change. But that's basically what we want when we wanna have synchronization, reactivity. So what I have to do now, I would have to manually again, keep that whole thing in sync. Yeah, if I really wanna have it reactive, that's not really reactive. I have to manually kind of sync. And that's basically what I have to do. Oops. That's basically what I have to do when I wanna keep a value of my state in sync with the value in the DOM. Yeah. Let me run Quokka here. So I have here again, these two values, the value in the DOM being a copy, a synchronized copy, and they both have the value of zero here in this line. But then I have to, like when I update the value, I have to then again manually kind of copy it because, so in order to really have value and value in DOM in sync. So this is kind of again, just as a simple example to show you what has to be done when you work imperatively. You have to always keep everything manually in sync. And another example one could look at is here. Let me, yeah. You could somehow think of a mother and a baby. And as young kids, they have like this bond. The mother is always connected to the baby. Let me write in the current file. Yeah. And mother and the baby are connected. But then at some point, the baby becomes independent. And if there is no, if this parental bond is not renewed, then the baby will remain independent. Sorry. If the baby gets independent, then yeah, you have to update this bond and then the child is independent. If you don't do it, the child will remain innocent. Yeah. Just as another stupid example, but just to bring home this connection, you constantly have to update.
5. Introduction to Reactive User Interface
Short description:
We want to have a reactive user interface where the UI is a function of state. Modern front-end frameworks aim to achieve this reactiveness. Your task is to start with the code and try it yourself.
Yeah. So this is what I just showed you. And so what we actually would love to have, which we don't have here somehow is some reactive copy. Yeah. That would be lovely if we could have something like that. Yeah. Like I just here and show you this dollar sign and the call on, when we create a reactive copy and the count, and when we then later changed the count, when reassigned the count, if then the count copy also changes, that's basically what we want to have a reactive user interface. So this is actually what modern front-end frameworks try to achieve. Exactly this reactiveness. And this you can also describe as the UI being a function of state. You probably already heard that a lot, and that's the idea of state-driven user interface. The UI is basically only a representation of the state, and then putting a function around it. The function would be any kind of way you change the state. That means the function f, when it changes the state in any way the UI directly represents it reactively. So we get, this brings us to your third task. And in this task, you start with the code, and in here, and I will, this is your task description, right? I will then post it into the mirror board in a second. I will post the hints also there in a second, but I want you to first try it yourself. So this is how you start this part of the code.
6. Refactoring Counter Code and Adding Derived Value
Short description:
We refactor the counter code to use a state object with a value, set value function, and an update function. The set value function manipulates the value, while the update function updates the DOM. We no longer need to manually update the DOM, as the framework takes care of it. We then discuss derived values and the need for manual synchronization. The next task is to add a double field and hide the functionality inside the state object.
And what I now want to do is let us try to just refactor the counter from before. Right now it doesn't do anything, but we have pretty much the same code in the end, but now we have a state object where you define a value, set value function, and an update function. The update function is the function which is updating the DOM. So here we have to, as before, the function which manipulates the DOM and the set value function will manipulate the value. And the onclick is the handler or the button press to then call the set value function. So give it a shot. But now, let's first have a look at what came out of it. Is there any brave volunteer to demonstrate us their solution?
Okay, so this was the code before with the update function. And the way we can rewrite it is with the state object that we have our value and the set value function, then manipulating the value and we can access it with this. And for this case, it was important also that we use really the function keyword here that we write a function expression and not an arrow function expression. Because the arrow function expression inside of a field of an object has access to the outer scope and it's like to have access on other fields inside of an object, we need to write it as a function expression. And then we can also do both things in the set value function, we will set the value to the new incoming value and we will update the value. Or maybe let me rather show you that I can highlight things, showing it inside of code pen. Yes, so inside set value, we are setting the state value and the second thing we update the user interface and using the update function, which takes care of all the DOM manipulations. And what we get is in our on click handler, we have a state that set value function and can set a new value. So there's already one step in what's such a framework maps does under the hood, it extracts away the process of manually having to update the DOM, yeah? We just call a set value function. And here we don't have to care about actually manipulating or re-rendering that's done for us. So we can imagine this being kind of very simplified code of a framework, a front end framework, which is implementing reactivity. Okay. Hmm. And. Yes, exactly. So this is just, we can focus on this part and don't have to think about the rest. And the update is taking care of the rendering. One point I want to discuss, and then the exercise will come after the break, derive values. So there I want to, show you something, and this will be inside of here. So, so far, we talked about just values. So we will now ramp it up step-by-step. We will talk about derived values, and then we'll talk about conditionals, see how complicated this whole thing of, especially conditionals gets with an imperative approach to really see exactly why a declarative approach is helpful. But also now, we'll continue talking about reactiveness first. So, if I have such a situation, I have a count value, and I want to have double value which I, which depends on the count value, yeah? Then I describe it as, oops, wrong keyboard, as count times two. And the thing here, that count and double, at this point, good luck, yes. Both have the value zero, so they are in sync. But now, of course, I also have to keep my, here, my double value in sync at this point. I'm sorry, I have to manually re-run the whole computation just so it also works here. If I don't have it, then double is still zero. So that's, again, a point of reactivity. That's closer to the Excel example. I have to manually re-run the whole computation, and you see how then the imperative approach gets more and more cumbersome at this point. So, maybe already begin to share your next task. So, oops. Which you could already start if you want, but we will have a short break there. But if you wanna play around with it, the next task is the task number four, which you find in the mirror board. And the task number four is it, just give you an intro to it. You start with this code so you can just continue with your code, which you already wrote about here where you edit the state. But you could also, yeah, just begin with the link, which you find in mural. And then I want you to add a double field here and also keep that in sync. But I want you to also hide all of this functionality inside of this state object, which is now a representation of our front end framework. Yeah, cool. So you now got the exercise of adding the derived value into this code.
7. Adding Conditional Logic and Sharing Solutions
Short description:
We added the conditional logic and now we can manipulate the code to show a congratulations message when the count is greater than or equal to five. Let's see if anyone wants to share their solutions before I share mine.
So as far as I understood, it's basically doubling the number that we've had before. Yes. So this is the approach. So now we have the new double variable. The only two additions that I've done is simply doubling the input value in the double and then putting it out in a new H1 that I've created here. Exactly. Yeah. Exactly. Perfect. Thank you. See, isn't that hard to share? Well done. Thanks.
Just as a comment here, yeah, as exactly as Omar did, he had to add two things to the set value function, like updating the value and also having to add again a new entry here for manipulating the DOM. So for every new thing you change at the value, you would have to then think about, yeah, how do I actually update that in the document object model so that it can then be viewed by the user? But let's ramp this even more up and let's now go to the next task of conditional logic. We have some new code, ah, and then we see Karin said her solution was with the getter of function for the double. And that's very interesting, we will get there. This will be later on, I will also use the get and set methods of the object. Yes, so when I talk about real, like truly reactive, as compared to kind of fake reactive with such a set value function. So Karin, yeah, that's cool. So we will look at your solution later. And so what task now? You start with this code or with the code you just left off at. And now you wanna add a conditional condition in it. If the count is bigger, equal five, you want to show celebration, or what was it, what did I say? A congratulations message. And so here, I think I will also now copy the hints. They're quite early because this vanilla JavaScript stuff is something maybe you don't work with every day being used to using React all the time. So here, I also opened the hints for you of what you might have to do. Okay, so now I get a few minutes for this task. How can I actually in an imperative manner get conditional into my code? Okay, now the microphone is moving. I think I have to ask a few, in Miro, I have to lock a few things. Julian, could you move away from this one message you're on? So it's like, I think people cannot really get to it because you are kind of in editing and Vitor as well, you are on this hint and then it's hard for the, oh, Vitor is not here yet. Oh, there you are. You're somehow still at this one. Can you just click, oh, Julian and Vitor, can you just click somewhere else on the Miro board? Okay. Actually, I just refreshed and I'm still on it. So yeah, Vitor managed to go away from it. That's good. But Julian, you are sticking there. Not moving an inch. Okay, this is strange. Give me a second. Yeah. Ah, now. Oh, I got that. So now I'm locking these things. I think then you can all still copy, paste, I hope, but not edit it. Okay. So where are we? Here, now we added the conditional logic and what we get out of it, oops, should be something like this here where we also add some code, whoops, to manipulate it. Oh wait, first, like does any one of you wanna share? It's always exciting also to see some other solutions. And you saw Omar did a great job, you can do it too. I can just share if it works.
8. Optimizing DOM Updates and Synchronization
Short description:
You can optimize the code by creating the note in the start and changing the inner HTML on the update function. This exercise demonstrates the complexity of DOM updates when state values change. You would have to think about how to manipulate the DOM efficiently. For example, you could insert the congrats node only when the double value is equal to five, instead of every time you press a button. Building a UI imperatively requires careful synchronization of state and the browser.
Yeah, let's hop. You see the code panel? Yes, looks good. Yeah, I just declared the element here, put the inner HTML in and then inside the function and checked if the double is larger or equal five and then inserted the node. Exactly, yes. Let's... Can you test it? Just so we see it really works. We already see a little bit. The refresh right now? Or when you just change... Ah, yeah, now refreshed. Ah, we see and then... Yeah, I wasn't sure if it should... Ah, yeah, so... More congratulations and then just thought that one is enough. So you showed us when the double is bigger equal five. I thought the value, but that's pretty much the same thing. Yeah. If this double is bigger equal five. Yeah, but it doesn't matter, yeah? It's pretty much the same. So that's why I... Okay. Yeah, but this is some interesting code here. I had someone of you directly something to add or some comment here.
Maybe some inefficiency they see in the code. You could create the note in the start and just add the inner HTML in the if statement. The inner HTML, mhm. So what are you... So on each updates now, exactly. This is one thing, but yes, in line seven, like you mean line 15 and 16, you could probably get hold of the elements outside of the whole state object, right? Is that what you meant? No, I wouldn't create... I wouldn't append the note in the update function. Because you just add stuff to the document every time you update and you could just create the P element like in the start and then just change the inner HTML on the update function. Ah, yes, yes, exactly. So you would kind of insert like an empty DOM element there at some point earlier, and then only update its contents. Exactly, that's one thing. That's what you could do, because what is actually happening here in the code now, which is shared, that we see that if this, like line 17, if this.double bigger equals five, document body insert before. So like when double has the value of five, we insert something. When the value is six, we also insert, yeah, and seven, and so on. And it would also stay if you decrement, if you add something like decrement, and you added the node before, and you decrement. I know we don't have the feature, but if you would do that, it would also stay there. Yes, exactly, yeah. It would stay there, you're not cleaning it up. So for example, just why I gave you this exercise? To also really give you a feeling of how complex DOM updates are, given state value changes. So you have to really think about how to manipulate the DOM given every change. And for example, here you would reinsert congrats, congrats, congrats, every time you press a button and you would have to really think how can I optimize it in this way we now did? Like Lotte already now proposed another change to make it more efficient. Or what you could also do, you could say because we only have increment here, not decrement, you could say if double equals five, only at this one point you insert the congrats node. And then it remains there all the time. And you not have it for bigger equal five, but for equal five. But these are all things you would have to now think about which have nothing to do with the logic of your application basically. And you see like when you build a UI imperatively, you have to think just a lot about this whole synchronization of state and browser. And Michael's also giving here a comment. I like when let me see what Vitor wrote something validate if the note is already on the Dom before adding it again.
9. Moving from Imperative to Declarative
Short description:
We have a lot of logic involved around DOM manipulation. The complexity of this approach and the difficulty in inferring the resulting user interface from the code are downsides. Let's move from imperative to declarative manner, where we only declare the state of the user interface and let the framework handle the work for us. React and Svelte are examples of declarative UI frameworks. The next task will involve building the same thing in React to experience the difference.
Exactly. You could also add like another conditional and check. Does this note already exist in the Dom? If yes, insert it. If no, don't. And you see we have a lot of logic just involved around Dom manipulation. And Michael says the double won't get to exactly five. Yeah. Another so actually my solution with my suggestion with equal equal five wouldn't even work in this case. The double we'll never get to five. So then he would maybe calculate the double value which is closest to five. So yeah. So yeah. Or we have the double, we have not integers we use but floats as Michael says. So yeah, this whole thing is super complicated and we don't want to deal with it. That's why we have one rather work with modern frameworks to do this work for us. So let me just also show you some slides now.
Thank you very much for sharing Julian. That was really great that we saw your code so we could really have this discussion. Thanks a lot. And let me know. Yeah, this is the conditional logic. That's what I came up with. Like that's only if the value is equal, equal five only then I go into this whole thing. And so yes, as I said, I have to remember all these internals and do all of this stuff. But basically what we kind of and another downside of this whole thing, so when looking at the HTML, we can not directly infer what our user interface will look like. Because we are kind of having this complex DOM manipulation there, it's so hard to really look at this code and then see, okay, what will my code actually look like given a certain state? So yeah, the HTML will look very different given this JavaScript manipulation. Yeah, and so logic is built around DOM manipulation and not around state updates. Instead of bigger equal five, I use like equal equal five or something else. But I want to think about the state change and not about the DOM manipulations. Yeah, so let's move from imperative to declarative manner. So we don't want to give exact instructions of how to tidy up the room, but only like declare. This is the state of a messy room. This is the state of a tidy room. And then let the kids do the work or let React or some other framework do the work for us. Yeah, not the how, but we want the what. So, for example, the description on the left says how to manipulate a user interface. And when we look at the language like Svelte, which also uses templates, we see, yeah, what if we could just describe the thing given the state, given the state of the count bigger equal five, please show me this paragraph. In a very similar fashion, we're all doing it in React as well. So let's look at React and Svelte, and React is a declarative UI framework. And I didn't ask that before. So sorry, I see a message. The problem states value is bigger equal, so the validation should be against value, not against double. Yes, Vittor, exactly. So in my head, I asked for the value. So the value can be five. So this would then work with equal equals five. With double, it gets more complex. So but just, I didn't ask, like I just assumed everyone of you is familiar with React and uses React, I guess because it's part of a React Day, Berlin and the React Conference. So the next task will be super easy. But I want you to still kind of do the next, building the same thing in React, just so that we see, feel the difference.
10. Exploring Reactivity in React and Svelte
Short description:
In React, we use the React use state construct to make variables reactive. Only variables stored in React use state are reactive, and their changes are translated into DOM updates. In Vanilla JS, we can create truly reactive interfaces by using internal variables and getter and setter methods. However, React does not have this built-in reactivity. Instead, we can achieve reactivity in Svelte without the need for special methods. Svelte allows us to create reactive values simply by assigning new values. This makes Svelte more similar to Excel, where values are reactive via assignment. Let's explore Svelte and its built-in reactivity.
And the next thing after that will be to do the same thing in Svelte and see how actually React is not reactive out of the box. But Svelte is, and I will, we will then see exactly what that means. But yeah, so now, we would go to task number six. The counter with React. And so the first task is to just create a reactive state value with React. I will publish the hint in a moment. And I think we will do it as a double exercise to also then already exercise number seven. So, actually the starting code of exercise number seven gives away the solution of task number six. So you can use that to just, and then continue. So we have our, yeah, our default value set here. We have our derived value, the double. We have onClick handler, which uses setValue, which now comes built in into React. We don't have to code that ourselves with all the imperative commands. And, yeah, what about this, what about this here? Yes, so line 12, the conditional is just nice. Yeah, we don't have to think about how to manipulate the DOM. We just describe the user interface given the state value of bigger equal five, this will be shown, small equal five, this will be shown. And you probably have also some other solutions that you can then in different ways and maybe more efficiently, or what. But yeah, this kind of just the idea, there's no direct DOM manipulation anymore. And let me look at the chat. Yes, and there's a comment of Latte, I could use here the double, the logic and operator to get rid of this ternary operation, which I showed you. So this would be a little more efficient code. I just wanted to explicitly highlight the two different states, state value, bigger equal five, and then the state where the value is lower than five. Okay. Okay. Now, I want to talk with you about why is React, like, okay, it's reactive because we kind of, so, it's declarative, definitely that's super nice. But is it really reactive out of the box? And actually the answer is no, we have to like use this construct, React use state, and only variables which are actually stored in this React use state are eventually reactive. We have to also then change the value with the setter function, and on these state changes will be reactive. On this state changes will be translated into DOM updates. And here, I think, who was that who had the comment before of using the getter and setters? Ah, Karin was that, I think. Karin also has another comment here. Yes, which is a bit, yeah, exactly, if we have value equals zero, there might be an issue with these, with some solutions here, which when you use, when you use the double ampersand, and that's very good, but let's not go into that detail right now. I want to focus on a truly reactive use interface. And I just quickly go back to the Vanilla JS implementation. Here I also kind of, you know, fake a set value, function, set a function, like the one in React, yeah? Like the set value here. But when I refactor this code, then, here I refactored the code, I didn't have a set value function anymore. But I, here now, made these values internal variables, and only expose the value and the double here. The double with a get, with a get method, and the value with a set method. And, by using this and like updating the internal values with the set, yeah, and then being able to retrieve the value with the get, I am here and write it in a way that I just really assign a value. I can have a reactive value via assignment. And that is actually something truly reactive. Like in Excel, yeah. We just assign a new value. And we don't have that in React. But let's look at the framework which does have this reactiveness directly built in. And that is Svelte. Does someone wanna share their screen? So what did you do? Which changes did you make? So I just created count here and then change this to use count. And then on the onclick just added count plus plus. Yes. And it's super simple. No need of any special set state something method.
11. Exploring Reactivity and Derived Values in Svelte
Short description:
Svelte has built-in reactivity through value assignment. Derived values and conditionals are next tasks. Svelte rethinks reactivity and the need for a virtual DOM. Svelte is exciting and may influence other frameworks. Vanilla JS becomes reactive with Svelte's variable assignment. Next tasks involve derived values and conditionals in Svelte.
Svelte really has this built in of, with count plus plus, basically when you write it out, it's count equals count plus one, as we all know, which is a value assignment and really having a reactive update of the DOM just via value assignment. Excellent.
So what about derived values? This is your next task. Thanks for sharing Laura. I'll wait. I'll show you quickly. There's one slide just to have everything on one on one slide. Yes.
So we saw that on the left hand side, yeah. We have a set of function, which we somehow were able to yeah. Like mimic, yeah. With JavaScript and the set value coming from React. And then on the right hand side, we have this direct reactive assignment where we have a reactive value directly by assignment. And I can highly recommend to look at this talk of Rich Harris. Calling, he's the creator of Svelt. And talking about rethinking reactivity. This talk is really about this holiday. What is reactive and how react actually isn't reactive out of the box. And how you, yeah. Like how react was about rethinking best practices and Svelt then as well. Svelt rethinking the need of, for example, of a virtual DOM. And Svelt doesn't work with a virtual DOM, but works with, works as a compiler, compiling the code so that then the DOM manipulations are hidden from you, but they can be done efficiently for the different states. So Vicky already gives a reply. Oh, okay. Not really the same. React sucks. Now, this is not... And now there's a lot that says maybe Svelte is the cool one now. So it is kind of like really cool when you look at it this way. React really has also much happening and going on and being in the change, and the ecosystem of React is just still much bigger. But Svelte is truly very exciting. And also, yeah, just thinking about like, do we need a virtual DOM or not? And really having, bringing some new things out, just like React did back in the days, and how React really influenced all the other frameworks. I think Svelte will also probably have some influence on some frameworks out there. Exactly, yeah, and via variable assignment, which Svelte kind of brings to the table, vanilla JS kind of becomes Reactive. Exactly, oops. And did I already show too much? No, this is the code, exactly, which we already saw now. Oops, and this was already too much, but this is your task now. The next one is, let's have a look at the two other things we did, derived values and conditionals. What is that like in Svelte? Just to get an idea. So the next task is already task number nine. You perhaps already found it in the code. And I think task 10, I still have to update the link. So get your hands on task nine. Oops, did I also not update the link? I think maybe that's not the right one. Ah no, it is the right one, yes. It starts with that link. Task 10 I'm updating. Okay, I'll try to add the derived value. And if you don't know how it works, yes, please use Google to check how to do it. And it's really also not very hard to do.
12. Exploring Derived Values in React and Svelte
Short description:
I created a double variable and added an assignment to it. I also added a paragraph that displays 'congratulations' when the value is greater than or equal to five. This is not a truly derived value, as it is updated manually. A derived value is one that changes automatically based on another value. In React, derived values can be easily created without using state. In Svelte, the dollar colon symbol is used to describe the relation between values.
Okay, who would like to share with us there? I just created a double variable and then on click added assignment to double variable. And then I added paragraph with the text congratulations for the value more or equal than five. And it works, I don't know how to reset it. I haven't logged in. Yeah, thanks, thanks a lot. I really like this. I really like this because I wanna, let's look at this together.
So you as a, you created in line three, a double value. Ah, now I can annotate, now I found it. Okay, you created this double value just also as a normal JavaScript variable. But what you also additionally did, you updated the value in here manually. So that is not a truly derived value. Right? So what is a derived value? So because you updated the. The description for radio. Like use effects, interact. So you describe, you describe here, yeah? The relation of this value double to the value to value. So you just describe how they are linked together. And then later on in the code, you actually never have to do something like that if it's a truly derived value. And the thing is this way it isn't a derived value. This way it's just storing value times two at this point in time of execution in line three because you don't want every single value to be a derived value. You don't want every thing to be reactive, like an Excel sheet. That when one thing changes the other one, some values you just want to store. If you want to store the double at this point in time, you do it like you did right now. But if you want to have a value which changes whenever this one changes, then we have to do what Karin already posted in the chat. You use the dollar, colon symbol. So instead of let, you use dollar, colon. Let's maybe do it together here. Exactly. And this makes double a derived value. It is now depending, like it's kind of, you know, like married to the value. Yeah, like this mother and the child, example which I gave you before. They kind of belong together now. That's even easier. Yeah. And that's like this power, like in React also, maybe can I quickly... Share. Where's the React one? You probably know that, like I did the mistake. I think in the beginning, and I see that a lot of React beginners do. I teach also React to beginners, that people in React think, okay, every state, which is somehow, now every value, which is reactive, I have to put in a state. So what people would do often, then create like here in React code, make it double, set double, and then they would make, like take a user fact and somehow then set double and set this to value times two or something. a value times two or something. Super complicated, yeah. And not necessary because in React, derived values can just be made like that. So a derived value where I just described once the relation to a value which can change, which is reactive, and then this one is automatically also reactive. Yeah, in Svelte, I then used the dollar colon to describe such a relation. So there's something in the chat. Ah, the question was, is dollar colon the prop of React? No, yeah, you saw it here. It's maybe, yeah, like a prop, of course, a change in props also triggers a rerender, but it's something different, yeah? So you also have props in Svelte, which you can pass on. But it's really like this derived value. So in React, it's very simple to create a react value.
13. Implementing the Conditional in Svelte
Short description:
The last exercise is to implement the conditional in Svelte. Take a look at the starting code and the hint provided. After completing this exercise, there will be a small quiz on Flutter code. Feel free to stay for a discussion on declarativeness, reactiveness, React, Svelte, and more.
Okay. Okay. And now the last thing, the conditional. Does someone wanna, did someone already do that? Or like, that's maybe a quick exercise for you now. The last exercise. I saw it already a bit in the code. Yeah, Natalia already did some extra work. But let's take a look at the starting code here for the conditional. And here's also the hint. Yeah, where you can check out how if blocks are created in Svelte. So, I'll give you two, three minutes for that as a last part of, as the last exercise of today. And then I'll just wrap it up and give you a small quiz to look at some Flutter code, some very simple one. And after that, you can stay if you want and ask me anything, and we can have a small discussion if you want about. Declarativeness, reactiveness, React, Svelte and so on.
14. React, Svelte, and Declarative UI
Short description:
In React, you can assign a value to something containing state to create a derived value. React's re-rendering process makes it simple to create derived values without a special operator. Svelte provides a separation of template and script, offering out-of-the-box reactive values.
So what does Wiki say here about the $colon operator? I guess it's Svelte specific. Not sure React has same exact thing because of different ways both libraries work. Yes, that's true. They really work in different ways. So in React, you can actually just assign a value to something which contains state and it will be a derived value. And that's because whenever React updates the DOM, it will call the entire function component again. So it will run through and re-initialize this derived value. Because of this workings, it's very simple to create derived values without a special operator in React.
But you need this whole React set state to even create a first Reactive value. Yeah, does someone wanna show us how they implemented the conditional? Because Natalia, I saw it in your code, it worked, I think, but it was not kind of the Swirled way of doing it. We have here our script, not changed at all, and here are markup. Sorry, I didn't really, you see I just threw you into the exercises without giving you a real intro into Swirled. But I think that's also just here to demonstrate a little bit of the basics of Swirled and not a Swirled introduction. But here inside the script tags, you have your JavaScript code and below that, you have your markup, which is like the description of your page, like JSX describes the page. And you, and here you have this, this part of the code where you describe an if block inside of your markup. And so here really, again, very declarative. So if the value bigger equals five, this part will be added to the DOM and will be part shown in the browser. And if it's not, it won't. So I have to say, I still also like, for example, React, I like React very much because I love that everything, oops, let me get rid of this code, that I have everything in one. I really enjoy working like that. I have my description of my user interface, and then I can have my logic. Of course, I would have this logic kind of rather taken out into a custom hook, to use it kind of to really have a nice separation of my, oops, to really have a nice separation of logic of my app state and of my UI, but, let me quickly do this. Small, we've packed up like this. But then I like that I have everything here in JavaScript. So this is my logic and my UI below. Oops, this does not, let's do update. Maybe I have some, messed up something somewhere. You need to move the onclick outside of the use count or return the onclick on the return. Thank you. Onclick is not defined. And yes, there you go, thank you. Thanks, yeah, missed to give that. But here I've got now all my logic nicely in a custom hook. But still, I love that everything is kind of JavaScript. And in Svelte, I have like the separation of my template and my script, but I've got really this nice directly out of the box reactive values, which is super nice thing.
Okay, let me close with some final remarks. Let me see the comment in the chat. I think, yeah, you wrote the onclick. So, yes, so we saw this conditional in Svelte being solved like this. And when we put it next to each other, yeah, we have these some differences also in the way React and Svelte declare the user interface. A last quiz I have for you. Now tell me, is the left or the right-hand side here the declarative way of describing user interface in Flutter? So both can be done in Flutter. And even if you don't know Flutter, just from looking at this code, what do you think is the left-hand side declarative approach or the right-hand side? Oh, okay. So we get some answers in. Right. The right-hand side. Ah, reactive. No, I meant, ah, wait. I meant declarative. Declarative or imperative? Um, which one is? And you said the right-hand side is the declarative one, yeah? And yes, that's the case, yeah? When you compare it to react, the right-hand side, it's really describing, yeah, declaring what's there.
15. Flutter, Declarative vs. Imperative
Short description:
In Flutter, the left-hand side is imperative, where you describe the actions and tell the child exactly what to do. On the right-hand side, you just show the view. Declarative and reactive code often come together in modern UI frameworks, making it easier to reason about the UI. Thanks for your attention and participation in the exercises. Let's stay in touch on LinkedIn, Twitter, and GitHub. Have a nice evening!
And in Flutter, yeah, you have like this view B and inside it, it has a color and a child. And on the left-hand side, that is very imperative, yeah? Because you are describing the actions, yeah? You set the color on something, you then clear the children, and then you create a new view and then you add something to it. So really like the child, like you tell the child exactly what to do, how to clean up the room, and on the right-hand side, you just show. Yeah, that's it, that's the view, and that's what it looks like when it's tidy.
So you already now learned how to see declarativeness also in other frameworks. So declarative and reactive code, yeah, they often now come together. The new frameworks are like modern UI frameworks are declarative and reactive. So as you saw, it's a bit magical because all of the intricate changes of the DOM, DOM multiplications are hidden from us, the frameworks takes care of it, but it's much easier to reason about, you just have, yeah, see what your UI will eventually look like.
Okay, yes. So thanks a lot for your attention and I really liked how you then did all the exercises joined and also shared screens and put up your cameras. So yeah, if you want to stay in touch, I'm on LinkedIn, also on Twitter and Andrej Kovac is also my GitHub handle. So yeah, thanks a lot, everyone. Who still wants to discuss a little bit? Stay in the call. The other ones, I wish a nice evening.
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up). Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too. Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step. (Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet? There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more. Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used. You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported. The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials. React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning? In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests. Table of contents - The different kinds of React application tests, and where component tests fit in - A mental model for thinking about the inputs and outputs of the components you test - Options for selecting DOM elements to verify and interact with them - The value of mocks and why they shouldn’t be avoided - The challenges with asynchrony in RTL tests and how to handle them Prerequisites - Familiarity with building applications with React - Basic experience writing automated tests with Jest or another unit testing framework - You do not need any experience with React Testing Library - Machine setup: Node LTS, Yarn
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
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!
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock. In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
Comments