React Finland Mini-Conference #2: State Management (full stream)

So [Music] you. Ah. [Applause]. [Music] ugh. So do. [Music] bye. [Applause]. so. [Music] foreign do so. [Music] [Laughter]. so. [Music] this. [Applause]. so. [Music] huh. Do so. [Music].

Play from 0:00

[Applause]. Hey there. React Finland. I'm Holly Gibson, a developer at smart IO. Perhaps you've heard of us. We automate every step in social advertising to unlock greater performance and creativity. We work with some of the most advanced digital customers, such as Uber and Zolando. We were founded in 2013 by two Alto students and now have over 400 employees in 17 offices across five continents. Our whole engineering team is located in Helsinki, we have multiple full stack teams that support different business functions. We are fully autonomous, and most of us develop our own micro services and work closely with DeVops, which provides lots of opportunity for learning. We are huge fans of using React with TypeScript and have over a million lines of React across our repos. We Smartly's are proud to sponsor React Finland. We hope you enjoy the sessions from your sofa. Stay safe. Hi everybody, I'm Yuis from Futurist and I would like to warmly welcome you all to this year's React of England.

We're super happy to partner up with Director Notican to bring this great community together to learn and improve ourselves. As software developers and futurists, we build digital services and products together with our clients. We combine software development, design, and data science to build great products and user experiences for the end users. I hope you all have a great night today and if you want to learn more about us, let's get in touch. Enjoy, hello everyone. My name is Shahrukh Yakubuf, and today we're gonna talk about the state management in React. So a couple of words about me I'm a mobile application developer, front-end developer, and the scrum master currently working at Go4. The agenda for the presentation is we're going to talk about approaches to state management. We're going to speak about the considerations when choosing the state management library, and couple of words about the future of state management.

So there are three main approaches that I would like to outline is the first is the first and low cost approach, second is the optimal solution, and the third is the special case related solutions, so fast and low cost approach are the. Libraries that are easy to learn, they are perfect for personal use for the startups, for MVP products and stuff like that. And at the same time, they have potential to grow from MVP into the full product as well. So one of the biggest example of this is the context API, which is a part of the React library, and we have a lot of libraries built on top of the context API. For example, React hooks the Dust and React easy state, which use view and store wrappers to handle the data. Second approach is the optimal solutions, so they are fairly easy to learn, they are easy to get started as well.

They are good to consider for the majority of the projects, which are medium and big size as well. And they have a very good potential to scale due to the logical they use. And also they provide very, very good developer experience when you're working with them. So biggest example is React, query and SWR libraries. They use the similar logic behind which is caching, fetching the data. And with the server side. So basically you get the latest state from cache first and then from request, and you have a great performance due to this logic. Another example is the MOBX is a classic state management library based on observables. I'm pretty sure you heard about it a lot. And the third approach is the special case related solutions, so they are perfect fit for the special cases. And you have a high control over the code, which leads to high scalability and more adjustments that you can do with these libraries. And the biggest example is Redux, this is the most popular state management library.

And if you want to start with Redux, I would suggest you checking out the Redux query, which has the server and network level abstraction to Redux. And check out the Redux toolkit, which is the set of tools and libraries to work better with Redux? Another example is GraphQL. GraphQL is a query based state management library that uses a polar or relay service in between the back end and front end. Which leads to extra work to do so. That's why, if you consider using GraphQL, keep in mind that there is extra work to do with the setting up. The Apollo. Server. The last example is Recoil. Recoil is a new state management library from Facebook. So the main logic behind it that it's made to control a huge amount of state between independent components. So you don't have to re-render the whole app, you can re-render the only parts, all the app, depending on their state.

So it's related to the new library and there is not so much knowing about it yet. So be careful when shooting this one. So let's talk about some consideration when choosing a solution. So, first of all, planning the app is important before planning the stack. So you should keep in mind that the majority of libraries they made for specific cases. And you should know the app very well before choosing the state management library that you want to use with it. Another point is do research and initiate discussions. Even though you know the app well, I still recommend you do some research. Look for alternatives of your chosen state management library. You will find something better, something more suitable, and also discuss it with team members because their opinion matters. And as well, don't forget about their clients goals and clients budget as well. And the last consideration is the app's growth and future opportunities, so always keep in mind that the any app will scale sooner or later.

And you should keep in mind that when you're doing development and the last point is the future of the state management. So, first of all, the first point is Redux might die, but not Flux. So basically, Redux is a library that is made on top of the flux idea, with actions, reducers and stuff like that. And there are many, many libraries now which are Redux but better. So that's why, even though Redux going away, we still use the flux logic behind many state management libraries. So another big change in the state management is introducing of hooks and context API. These two core Redux React changes completely changed the game. Nowadays we have a lot of libraries based on this, they are working great and they have a huge potential for the future as well. Then we have now tendency of creating more solution for complex state management. So Recoil was a big example of it, which Facebook used with their analytics tool to handle.

Big amount of data. And the last point is now we're shifting focus from local state management to server state management. Meaning that caching, fetching the data asynchronously becoming more important to keep the app performant and scenes. Nowadays, the network speed provides us more options to do it, so we should utilize it. And thank you very much for listening and have a nice coding. Hi React Helsinki. I'm here with Columbia Road and my name is Rory and I'm here to talk to you about state management. So I work as a managed services lead at Columbia Road. And what does that mean in practice? Well, actually, that's a really good question because I haven't quite yet figured that one out myself, but I do know that. It means working with React applications, and I've also worked with many React applications in my past projects during my time. So we all know that state management in the front end is not a particularly easy task.

It's there's so many different ways to manage it, there's so many, complexities there. And if you're having your data coming from all over the place, it can be a really, really difficult one to sort of get and not have. It look like total spaghetti. So let's say you turn to using some kind of state management library or tool or framework, and then you are suddenly thrown with loads of different options. Maybe you want to go with something more legacy, like Redux or Mobx, which has been tried and tested, maybe you want to go with something a bit more new, like Recoil. Or maybe you're using GraphQL and you want to use Apollo. You could even decide to use a different language entirely and go to closure or to reason, which I know have been popular in certain applications. Or maybe you could use Kotlin or even Scala. I haven't seen these used in the wild, but maybe there are people out there using that. So it's one thing that's important to consider is that actually React itself is just a state management library.

The fundamental purpose of React is being able to pass around data to different parts of your application, where you can then render this data. And React has its own ways of being able to pass around. State, of course, it uses state and. Props? And there's other tools as well which might be useful without you needing to even resort to using a state management library at all. So those of you who have been working in more, let's say legacy React applications. You remember the times where you had to pass down every single piece of state through all of your components? For it to be able to reach the leaf node without having any other option. And in these kind of situations, you would then turn to Redux or Mobx. Because that gave you a centralized way of being able to manage your data and pass it around to all of your different components. But this is now 2020 and we have different ways of doing this, so maybe we could consider doing things like keeping it simple.

Just using hooks, I mean, hooks are such a fantastically boring way to manage your data, and that's brilliant. You can look at this code and you immediately are unable to understand exactly what's going on here. And it's just a couple of lines to be able to declare your state and then immediately render that. So this is one really simple way of just managing data, and then, if you want to, then compose different components to be able to pass your data around, you don't have to drill that through all your components. You can do simple things just like composition here with this button grip component, where I'm then composing different components inside which don't. And the button group doesn't need to know about the data that's being rendered in the children. And then let's say, for example, you want to pass data down far down your component tree. Well, then in that case, you can then turn to something like context, which allows you to define a context.

And then you can create a consumer of your provider further down the tree, and then you can just render your data there. Of course, you should use context sparingly, because every time you use context, you're sort of like sprinkling in a little bit of magic. And if you're using that in too many places, then it can be difficult to understand. But everything else beyond this is kind of just as a design pattern. I mean, okay, maybe there's a little bit more to it than that, but. Generally, state management libraries are just bringing you into a framework of thinking, as opposed to bringing out too much in terms of code. Of course, there is certain benefits there and certain things that are really, really nice to have, but a lot of it is just bringing you into a way of organizing your data. And it's also important to remember that every time you npm install something.

That's an additional piece of mental baggage for you and your team to have to consider in the future. And it's also not just your team now, but it's also the people that come in. That's a new series, that's a new point that you have to onboard someone on to, and it's a new point of maintenance, and it's a new point. A new library that might be updated in a way that's breaking to your existing version of your app. So it's important to know that if you can keep things simple, then, of course you should. The best code is always the most boring. And I mean, of course, it can be fun or sexy to be able to install the newest and shiniest libraries. But keeping things boring means it's most maintainable long into the future. So the message from this talk really is just the one line that many of us have heard before is keep it simple, stupid.

And you can manage your data in your React applications in the best.

Play from 44:00

[Music] so [Applause] foreign [Music] from Hey huh? [Music] me hello. They supposed to draw what the hell is happening? So now my headphones are here, and if they tell me to stop, they can't tell me to stop because my headphones up here. So right now, we're gonna go on a fireside chat and we're all just basically gonna chat. So it's gonna be a mostly informal thing, not super technical, and basically we're just gonna chat. And David's is, David is back. And I'm not sure if I should stand like this and only have my face is visible because it looks kind of cool, or if I should actually move, I'm gonna move which side? This side? Okay, cool, okay. So we are missing Christian is on a birthday party. So I do think that is a very valid excuse, though. I feel like, yeah, that is. A very valid excuse.

So most, most thing about this is just asking you, how are you feeling? Like, how is life going? Do you have any projects that you're releasing? Do you have anything you want to talk about? Anything you want to chit chat? Something like that? Life's going fine, is it? I? I was dying. DAVID well, yeah, besides that and everything. And the fact that we can't help be in person in sauna together. Yeah, did you have to, like, go straight to the creepy one? Yeah, it's not like I wish we could have dinner. It was like I wish it could all be an astonish again. No, yeah, well, I live in Florida, so that's already a sauna. So, I can imagine it was really hot in Berlin last week, and I just, I just can't. I just my brain just doesn't survive with hot weather. One of the main reasons I moved away from Portugal turns out I up real bad because of global warming.

Berlin is also super hot now, like 40 degrees Celsius, which is, I don't just a lot of Fahrenheit. I don't know how much I can shed, 40 a hundred, I don't know, probably 40 Celsius. Oh, I'm not typing. Wait, 40s. Oh, that keyboard isn't working. Okay, that makes sense. I actually have a, 104, uh-huh, I have a, I have a Fahrenheit's, a Celsius example that I made with XState, so that's why I use that all the time. Yeah, I think the main issue is that, like, if you live in Europe, it's most, not all of them. I know that Poland does have the AC, but most countries don't have AC. Because it never gets too hot and then it does. Cry can be seen as can be seen as an unforeseen state, right? It is literally no, it was very foreseen. People just didn't do anything about it. We've known about this problem for a couple of decades now, we've just tried to ignore it.

[Music] sounds like how U.S. developers work. It's like that'll probably be a problem, but we'll, we'll just wait for the user to report that.

Play from 1:01:00

There was a Windows version that was skipped, Windows 9, right? I think it was Windows 9. It was skipped because of something really random that was. Kind of like that, yeah. So it's because there were a lot of programs when they were detecting, which version of Windows that they were on, they used. Does it start with a 9 to detect Windows 95? And obviously, if you call it Windows 9, that would break because it would think that it was Windows 95. So at least it wasn't Microsoft's fault. So I was like, that, I mean, sort of was still we have to blame thing. I, I work at Microsoft, so I blame everything on Microsoft. So I mean, yeah, exactly. I feel like I feel like that's our, our thing is like when you work somewhere and something goes wrong. You're like, it's my fault. It's all our fault and I apologize, but you did do anything.

It's all our fault. We up and I'm sorry. Okay, yeah, I don't. You haven't spoken. How are you feeling? Are you? Are you excited for your talk? I don't think excited is the right word, but are you looking forward to your talk? Oh, I think you're muted. Sorry. Yeah. I'm looking forward to his talk. No, I'm looking forward to his talk too, but I don't think he knows that he's muted, or maybe he can't hear me. Maybe I'm muted. I'm. I was muted. Okay, there we go. Sorry about that. Are you looking forward to your talk, or are you looking forward to having done the talk? Those are two different things which are both valid. Was that question to me? Yes, that was just, really, Ah, I, I, I was I. I guess I'm so sorry. I was saying, yes. I am really looking forward to my talk since I really prepared a speech.

I have never done this before in Russian, so that would be even nicer that the Russian ones. Is this your first talk in English? No, not first one, but the last one was in November. I just changed, let's say slides a bit or not a bit. Yeah, I don't, I don't think anyone. I think I've heard someone say that they do a different talk every time, like there was one person that said that. But in general, I don't think that's the thing that everyone does. So that's completely fine, as long as you don't like. I mean, I, I evolved. My talk, so the team is pretty the same. But as a speaker, I should really understand how the interaction with the viewers is working. So I just was trying to deliver one message, but the audience received a bit another one, so that's like a point for me.

Okay, you should work, work it out bit more, and maybe try to take a look from another side of you. So, yeah, I think this, this is how the team has been evolved over time. So, and now I'm really confident about my speech and the explanation itself. So, and the funny thing, I will just check out, during this final test, am I okay in terms of timing or not? And if I have extra couple minutes, I'll make a re reference slide for the debits. Since his team and about an actors is pretty related to my talk and, hopefully I'll prepare a small surprise. Nice, Oh, that's awesome. Oh yeah, yeah, Ivan is doing his talk live, that makes more sense. I, I, I'm not that strong in a computer science theory, but I at least tried to read the papers. So since I'm not an author like you, I'm just one of the most active users. Yeah, I, I mean, I, I didn't graduate the computer science degree or anything.

And yeah, admittedly, a lot of the research papers that are written are just hard to understand. And so that's why I really enjoy reading ones that, you know, are more approachable. But yeah, actor model, yeah, I'm sure you've researched it, that's been around for a long, long, long time and it's really useful. Yeah, but this kind of extra slide will be just the conclusion, to my speech. So, like, it's not the first class message I want to deliver to the audience. Since, actor of model of computation, whoa, it's pretty difficult to understand from the first step, you know? And, showing it up will just frighten an audience extra. That's true. Okay, everyone, we're sorry both of you, we're out of time. We have to jump back into the conference, that is for the pre-conference, the one for everyone. It was really nice talking to you two and I'll talk to you at the end of.

The at the panel at the end, all right, okay, everyone welcome to React. Finland. This is our second not hours, but let's call it ours. This is our second mini conference and this one is about state management. So I'm pretty excited to hear about the different ways of doing this. Yeah, so I gotta do this in a very weird fashion to change the slide, there we go. So my name is Sarah and I will be your MC today. You call me Cerro, you can call me Sana. Anything works. I'm a front-end developer at good Sandbox. And I live in weirdly sunny Berlin. Today, as you can see from one side of my face. Because it was raining yesterday, so that's kind of weird, okay? So our first talk will be David, who is going to talk about, everything as an actor. So, yeah, I mean, I don't want to get too much into the talk because you can see this, this part online.

And I'm really excited to have David speak and I'm really excited to hear his talk. After that, we're gonna have Ian. And as you can see, I'm now pronouncing their last names. Because it's probably gonna be like, terrible, and I don't wanna try and pronounce their last names. And he's going to try and talk about, not try, he's going to talk about, I don't know why I said, try, he's going to talk about. Effectors, which honestly, I have not a very big idea of what they are. And that's my friend's way of saying, I have no idea what that is and I'm excited to learn about it. Actually, it's going to be pretty cool and the last talk of the day is going to be from Christian Alfone. Which is the only one I can pronounce the last name, which is pretty cool, I can pronounce one person's last name also.

I work with him, so even if I couldn't pronounce the last like, I would have to learn how to pronounce his last name. He's been working with me for like seven months, so Christian works with me at code Sandbox. Great guy, 10 out of 10 out of Norway, straight to your house. And he's gonna is going to talk about stitches, which is a CSS in JS tool that he has. Been working on, it's pretty good, I've used it, it's really, really good and it's a really good way of looking at things. And I think you guys are really going to like the not like amping up, hemping him up in any way. But I think he is really going to like this and he's a really good speaker. 10 out of 10.. This is so he can review my pull request so they don't get stuck. And I'm like, remember when I said good things about you in the conference, Christian? And he's like, Okay, fine, okay, so, so, the thing is, there are two types of streams in this case, and you have a free stream and a premium stream.

So if you're in the free stream on YouTube. You may wonder why you have ads, and, that's mostly because that's the that's the free one, so the free one will add some ads. Mostly because, you know, you need to pay people, the AV people, and we need to just, you know, pay people. And you can also watch it in a premium state, and which means you will have the access to the Q and A's and the panels and everything. And yeah, no, that's about the main difference. So the next one, you'll know. And the tickets are not very expensive, it's just mostly to help out with all the creation of this. There's a lot of work that comes into making a really good online conference and we greatly appreciate your support. So we also have a Slack that I would ask you to join. Because that is where you can ask the speakers questions, where I'll be looking out for questions that I can ask the speakers.

And that's important because otherwise I have to make up questions and that's painful. Please don't make me make up questions on the spot because it's very terrifying. I don't want to be the speaker. Okay, yeah, and the next thing is that, please run a slack. It's nice you can talk to all of us and it's gonna be really good. Also, even though this is online. We have a code of conduct and we abide by the Berlin code of contact, which is used pretty much everywhere. The Berlin code of Conduct basically says in a very simple way. Please be nice, just please be nice, like, don't don't attack other people, please be nice, treat everyone with respect. Don't ask questions that may be offensive to the person that's speaking. And that's about it, just let's just be nice on slack and everyone's okay, that's about it, okay, and I have. I want to really thank ours, our sponsors as well.

I want to take our sponsors for being able to actually allow us to do this kind of things. Like I said it, it takes a lot of effort to make a conference like this. So first in gold sponsors, we have GO4, who is an expert, in experts in knowledge, in digitalization, we have Futurist and Smartly..io. So thank you so much for your help. And our silver sponsors, we have Digia, Digia, Elisa, Alma and Columbia Road, and our brand sponsors we have Quentik, Vinci, wonder, Neteron and Cybercom group. So thank you so much for your help, and yeah, thank you so much. Okay, so I want to let you know that there is going to be a conference next year. If the pandemic allows us to have a conference next year, which I am not sure it will happen. But we'll never know, maybe we'll get her back soon, maybe we won't, we'll never know. And I know this sounds kind of weird right now, let's just think like I was.

I was looking at pictures from a while ago and I saw a picture while I was in a concert. And I was like, so much Garunda virus in this place, I could not get into this concert right now, like so many droplets of coronavirus everywhere. Like I was touching everything and it wasn't good. And I feel like we all have this. But I'm really excited to go back to conferences, like to actually be able to talk to people and do this in person, like, there's way more energy and it's really, really good. So next year, assuming that things get better and assuming that it's completely safe to do so, there will be a React. Finland 2021, this time corona free. I wish that would be great. Okay, so we'll have the workshops on the 24th to 26th, so okay, wait, I gotta count tonight. Monster with. My may yeah, I'm Portuguese, so that was Portuguese. Sorry, I. And like, I can't do the like zero five. I have to like, count with my fingers like a baby.

So it's like generic red marshmallow. 24 to 26 in may. I also switch the right and the left, sometimes I don't know which one the right is. And then I get married and I know that this is the left one. So that's how I like, I look at my hand, then I'm like, married, left. There we go and from 27 to 28 we will have the conference. So yeah, that's about it for the intro slides, and let's go up to David. So Debbie is going to talk. Everything is an actor and I know that he can't hear you, but it's very early where he is. So please give out for David. Hey everyone, my name is David Coreshead, also known as David K. Piano. Pretty much everywhere online. So today we're going to be talking about how everything is an actor. It's sort of a strange title for a presentation, but we're going to see, hopefully in the next half hour, how this philosophy makes sense in terms of programming any sort of reactive application, uh?

Play from 1:08:00

Furthermore, we're going to be exploring how viewing our applications as complex systems of actors, all communicating with each other, can even simplify and improve the way that we organize our logic. But when I say everything is nectar, I do really mean everything. So let's consider a real life example from better times, when there wasn't a pandemic that was completely interrupting our way of living. I suppose that you wanted to go to your favorite cafe and sit down and get some work done, which is something I love to do instead of being stuck at home. So we're going to use this dotted line to represent sort of a timeline of the events that happen. When we're going to this hypothetical, magical cafe that we could all socialize in, and, you know, live our normal lives. So you walk up to the cashier, right? And you ask for a coffee, and the cashier then has to tell the barista what the coffee order is. So that they can start making it. And so in the meantime, the cashier tells you that it will be. Three euro and you're okay with that, so you get your credit card out and you pay the three euro.

So now that the payments, is made, you probably have to go through a payment processor. Like, maybe you have a square thing or a little terminal on the on the counter. And so that itself might be a series of events where we're sending payment information to a payment gateway and we're getting credit card information. And maybe you're also leaving a tip, or you're registering your phone number for reward points. If they have any sort of frequent customer like appreciation sort of thing, and you know, whatever else. The payment platform may do so. When you've made your payment, the cashier then gives you a receipt, and then you wait a few minutes. While the barista prepares the coffee. When the coffee is ready, the barista gives the coffee to the cashier, who then delivers it to you. So getting a cup of coffee from a cafe in the morning involves a lot more communication than you may think. In fact, there might be more employers, there might be more coordination going on, and this isn't always the way that things work, too.

I mean, the espresso machine might be broken, or we might be out of supplies, or we might be in the middle of serving more than one customer at the same time. So there's this idea called eventual consistency that states that in a distributed system. Everything that's observing some sort of value will eventually get the latest value, as long as that value doesn't have any new updates. So in software, you know where you typically want to know the value as soon as possible. This can be a little bit frustrating, but in real life, it makes sense. If something happens somewhere in the world, which, you know, has happened far too many times in 2020. Not everyone's going to know about it immediately, you know? Some people might post about it on Twitter, or it might show up on the news, and eventually everyone who cares will know about it. But the key point is that it doesn't happen immediately, and it happens due to communication.

So let's let's take a little bit of a nicer example. When you went to the cafe, you own coffee, right? So the barista doesn't know that, you know? Although they could probably guess they're coming in here. They probably want a coffee, but they can't read your mind, uh? But they'll eventually know that you would like a coffee if they care to ask, what would you like? And so the fact that you want a coffee is part of your internal, private state. Again, no one can read your mind if you're tired or you're hungry, nobody knows that unless they ask you or you tell them. So you can choose to share that internal state by replying, I would like a coffee, please. And so when you say that statement, in effect, it's immutable, it has been said, you've said it, you can't go back in time and you can't change that statement. And so if you wanted T instead, you could say afterwards, actually, I, I want some tea.

But that doesn't change the fact that you said you wanted coffee first, and the barista knows for the cashier knows that you asked for a coffee first. So, of course, asking for a coffee isn't a guarantee that you're going to get a coffee. Just like making an API request to a server, whether you're using REST or GraphQL, or whatever, it's not any guarantee that the server is actually going to come back with a response. I mean, they could sign out, you could get a server error, which I guess it is sort of a response, but you know what I mean? But anyway, if all goes well, you'll eventually get your coffee. And so all this is done through message passing. And so we could consider each individual in this scenario to be what's called an actor, and these actors communicate with each other to achieve a certain outcome.

And so this is a. It's an interesting way of viewing how things work in real life, because it is actually how things work in real life. And this is also how things work in the actor model. All right, so what is an actor? In short, an actor you could think of as an abstraction that describes pretty much everything an actor can be thought of. As any entity that can send or receive messages so an actor can react to messages, meaning that when they get a message, and only when they. Get a message, they can do something, and so we're going to talk about what that something is soon. So in terms of programming, an actor can send a message, or an event, or a signal. I use all those terms interchangeably. So an actor can send a message to another actor that it has reference to sending a message. In programming is, you know, basically a function call. It's exactly the same thing. So just like you can talk to people that you know or you are in contact with, actors can only talk to known actors.

But just like email or phone calls, you can include a reference to yourself so that the recipient actor can say, Okay, there's your email, I can reply to you. And so when the actor receives a message, it can decide what to do with that message. In this case, when an actor is greeted, then it could decide to send back a message. Although, you know, in this case, it is finished, so it doesn't have much to say back. So the actor model, just like you know everything I talk about St. Machine statecharts, whatever it is nothing new. In fact, the actor model is even older than statecharts, which I don't, you know, talking about for a while. The actor model was first formulated in the early 1970s by Carl Hewitt, along with Peter Bishop and Richard Steiger, in the paper, titled A Universal Modular actor. Formalism for artificial intelligence. So, yeah, they were talking about artificial intelligence way back then, and even further back from that.

And so, this paper was interesting because it, it took views from physics on just this idea of there being actors communicating with each other. And it was also influenced by the small talk language, which was created by Allen key. And you might know, Ellen, he as the computer scientist who coined the term object-oriented programming. But what's interesting is that Algae envisioned object-oriented programming, which is commonly viewed as everything is an object. With more of a message passing approach, and that's something that the small talk language actually emphasized, Allen key himself said that the original vision of object-oriented programming was basically the actor model. And, if you, if you go to this link, you will see a discussion where. Allen key says that there is almost virtually no difference between, his original vision for object oriented programming and the actor model that Carl Hewitt and others have created.

So now, while many computer science models are based on mathematical models, the actor model itself is based on physics, like general relativity and quantum mechanics. So, how it relates exactly is beyond the scope of this dog. So I'd like to think of the actor model as relating to real life instead, because it makes things a little bit simpler. Okay, so let's define actors concretely. They have a few basic rules, and these rules have remained unchanged for basically the last 50 years. Just like we have rules and React about render purity and immutability. These rules are what make the actor model work so well in distributed and concurrent systems, so the first rule is about locality. All competition is performed within an actor only, and so, as per the title of this presentation, everything is an actor, because the actor is a fundamental unit of computation. In fact, you could model pretty much everything in programming as actors, even individual values.

You could consider them to be little actors. Where you ask it what its value is, and it immediately gives you a response back, but that quickly becomes unpragmatic. We don't want to model absolutely everything as actors, and since all computation can be, can be performed within an actor. It can also contain its own behavior and state. Which is something that, you know, we could sort of think about both of those as the same thing. We'll talk about that a little bit later. Basically, actors can be stateful or stateless, and they can have their own private states. And if an actor wants to do any sort of external communication, it spawns another actor to take care of that again, just like in real life. So then how can one actor read another actor's states? Well, so that's where the second rule comes in actors can communicate only through messages, nothing else.

Like, what's this thing? Isaac Newton said. For every accident, there's an equal and opposite reaction, but you can't have a reaction without an action. I mean, something has to cause something to happen, and so that something is messages, messages are immutable, which? Provides a guarantee of no shared state between actors. And so this itself just defeats a whole host of concurrency problems, like, deadlocks and race conditions and things like that. And so if one actor wanted to read another actor's date, it needs to ask it via a message or need to be told via message, uh? The receiving actor can then decide whether or not to send back a message containing the desired piece of states that the other actor wants. And so, if you think about actors. The same way as communicating between clients and server via HTTP, that's basically the same idea. When you ask for something from an API, you're not going to get a result back immediately. And you have to send what's called a request, you're sending a gets or a post request, or, you know, put, deletes, whatever else you might send.

And you might or might not get packs of information, which itself is a message, so that's basically the same idea. So actors are reactive and that they react to incoming messages, and there are three things that an actor can do when it receives a message. First of all, it can change its local state or its behavior. Remember that an actor can have local isolated state, which includes the data and the logic that determines what an actor should do in response to any given message. For example, if you send an increment message to some sort of counteractor, it can change its internal states to its currents. Count. Plus one, it can also determine that the counter has reached its max. And so that you could consider its behavior, and given that it could change its behavior so that nothing happens if another increments message comes, so that's what we mean by behavior, and we'll go about that a little bit more later.

So an actor can also send messages to other actors that, of course, it knows about, and so this makes sense in real life, too. You can only talk to people that you have contact with if you want to email someone, you need their email address in where to email them. You can't just randomly put in someone's name and hope that you know it reaches the right person. So, just like you can send someone's Twitter handle or email address to. Someone you can send a reference of another actor to some actor, so that the actor you send the message to can communicate with that actor. An actor can also create or spawn a finite number of child actors, and these child actors are just like every other actor. They follow the exact same rules, they have their own isolated state, and they have their own behavior. So remember that an actor can only know of some external state if it receives it via a message, or if it's born with that information.

Sort of like genetics, that is, the parents can create a child actor that already has some relevant data from its inception, you know, just like real life. So even though actors all follow the same rules, they can behave a little bit differently in reaction to a message that they receive. And this is what's called the actor's behavior, and this is what determines what immediately happens next due to some sort of incoming message. A finite state machine is a really great way. Before says, that you could describe a behavior of an actor, since it's an events driven approach to modeling logic. And, by the way, like I mentioned, I use messaging event interchangeably, so you could consider them the same thing whenever I switch up those terms, uh. With the state machine, the finite state represents the qualitative state, and in different finite states, events can do different things or transition to another states.

State machines can also have extended state, which represents the quantitative data associated with that machine. So in this example, we could have orders, inventory or sales, and all of those pieces of data are extended state. Which don't really have anything to do with the behavior. And behavior can include things like being idle, you know, waiting for someone to make an order, making coffee or delivering coffee. So, both of these combined make up an actor's overall state, which is why an actress behavior can be expressed. You know, as it states, and we could use those both together. And, of course, if you're not using a state machine, you might have his loading booleans floating around, or his error is success. Whatever. And so hopefully you have some logic that does the right thing, depending on if is loading or is, is. True or false? And so that's the same thing around behavior. We're basically determining what should happen next, given the current state and the event that just happened, or the message that was just received.

So, whereas an actor's behavior represents its internal logic, an actor system represents the connections between all of the actors. And so this is where we sort of deviate from, from typical state management solutions. Because the truth is, there is no single source of truth, there is no single atomic state store. In fact, state can come from many, many different places. And so, instead of fighting against that, the actor system embraces that. And so an actor system always has a single root actor, which is known as the guardian actor. In some implementations, like AKka, every single actor from the root actor has exactly one parent. So enactor system forms a hierarchy, or sort of a tree structure. And remember that any actor can spawn any number of child actors, and these child actors can themselves spawn child actors. And on and on, and so that's how it forms a tree.

And so each actor has a unique address that identifies it. For simplicity. In some actor model implementations, this actor address represents the hierarchical path to the actor, for example, in in over here, uh. Cafe manager one is a childhood cafe and cafe manager, one, employee one is a child of that manager, one parent's. Actor addresses can't be used to access the actor instance directly. So, just like if you have my email address, you can't access my email inbox. Or at least I. I really, really, really hope not. You can only send me a message using my email address. Just like an actor can only send messages to other actors via their address, and just like an email inbox, those messages arrive in the actor's mailbox, you see, so we're making the analogy there, and that's how an actor can process one message at a time. So let's talk about mailboxes for a bit.

An actor needs this. This idea called a mailbox to guarantee that only one message is sent at a time. And here's why when an actor receives a message, it needs to process that message to determine what happens next, how its state is going to change. What? The next behavior is if it needs to spawn new actors or send messages to other actors, etc. etc. When it's done processing that message, it can then process another message and return the next state. But what happens if an actor is processing a message and then it receives another message, you know, immediately during the processing of that current message? So this can lead to race conditions or impossible states, or worse. It could actually make the actor crash. So how can we prevent this from happening? Well, we could use mailbox, and by using a mailbox, we can hold all of the messages in some sort of queue.

The actor can then DQ these messages one at a time, so this guarantees that we only get one message at a time. The actor takes the DQ'd message, determines the next state, performs any side effects, and only then does it DQ the next message. So, even if a message arrives as the actor is processing the previous message, the mailbox will hold on to the message until it's ready for processing. And that's, that's basically the role of a mailbox. It's also interesting to note that the mailbox itself can be represented as an actor. Now remember that an actor instance can't be accessed directly, we can only communicate with that actor using some sort of address, or, in other words, some sort of reference to that actor. And this gives actors what is called location transparency, and that allows the actors to act sort of like a black box. Because we don't really need to care where the actor is, we just need to access, something that references the actor and the actor.

Wrap itself will take care of forwarding the message to the actual location of the actor. Whether it's in outer space or on some local box somewhere doesn't matter, and we're not really supposed to know anyway. And if you think about it, this also means that we could hot swap an actor while the program is running, and it will still work exactly the same. And this is why, this is why actors work so well in, in concurrence and distributed systems. And so this location. Transparency also enables another really powerful feature, which is false tolerance if an actor fails for whatever reason, whether it's a shaking. Network or some other fatal error. Some after model implementations can choose some sort of strategy for reviving that actor, or even letting it fail gracefully. That means that if one actor fails, it's not going to take down the entire system because it shouldn't right. If you have some sort of runtime error in your application, like in a very small part, that doesn't mean that your entire application should fail necessarily.

So, one such strategy that some implementations use is to, just, restart the actor if it fails, or replace that behavior with some sort of fallback behavior. So this provides a lot of resiliency to, to actors, so, like I said from the very first slide, everything is an actor. And hopefully now, if you squint, you'll begin to see how various parts of our code can really be modeled with this message passing paradigm. I. I was recently working on the post message API. And I realized that. The way that Windows communicate with each other, whether it's an iframe or a pop-up window, or a DevTools panel, is with message passing. I mean, it's even in the name, post message. So, let's say that we spawn a window actor by calling window.open see, sort of pretty much the same thing. And then the parent window actor can send a message to the spawn child window by calling post message.

And so the child window actor has a reference to the parents window actor in the source property of the message, which is something I recently learned about. It's really useful and it can use that to send the message back to the parent. So now you have this parent's child communication going on. So, the reason I'm talking about how everything is because this is true for X data as well, now XState, library that I created is mainly a state machine and statecharts library. I've given a few presentations on them, especially at React Finland. So I really encourage you to go back and watch those presentations if you want to learn more about XState. And so, from those presentations, you'll recall that. State machines and statecharts describe the behavior, and in this case, they describe the behavior of a single instance of an actor. But XD can also invoke and spawn child. Actors, and so invoking an actor is done using the invoke property inside of the state. the behavior of an actor is specified in the source property.

So in this case, we're invoking a new actor with the behavior defined in espresso machine, and when this actor is done, we transition to the deriving, coughing or, sorry, delivering coffee states. By the way, invoking and spawning are pretty much the same thing. I know it's a little bit confusing. But the only difference is that an invoked actor lives for only as long as the machine is in that state where that actor is defined. So once we exit, that states, the actor is automatically stopped. Pretty much the only difference. And if you spawn actors, you have to man manually stop them. So, there's no special way for X8, or any sort of actor and any actor model implementation to know whether an actor is done or not. Done is just a message, and so that's why the invoked actor has to spend. Send that special done message back to the cafe machine.

So when we invoke the espresso machine, we're creating a new actor with, with espresso machine behavior, and that actor should eventually send that special done.invoke.espresso machine back to the parents. If you're wondering about why it's named that way, this syntax for that in that done invoke message is defined in the SCXML spec itself. Which exited. Tears, too. So now, because the caffeine machine has a reference to the invoked actor, because, you know, because it invoked it. It can send events to it. Uh. For example, if the cafe machine gets a change order event, it can send that event, or pretty much any other event directly to the invoked espresso actor. Referencing it by its ID in the machine, and so internally, XD keeps a reference to all of those actors, and it matches those IDs with those references. So, the idea is just an ex abstraction. If this seems a bit verbose, there's a helper function in X8 called forward two.

And so all that means is take the exact same message you received and forwarded to that actor. So in the Evo, in the invo, ah, in the invoked espresso machine, the actor already has a reference to its parents, so. We can send the parents cafe machine events such as machine broken, if the machine breaks, then the parents can decide that it needs to handle that event. And decide. You know what to do next now? Sometimes we need to spawn actors dynamically, such as whenever an order comes in, so, you know, instead of being constrained to a state, and that's what spawn is for. For instance, whenever an order is placed, we can spawn order actors, which each have their own behavior specific to handling orders, since these actors are fundamental units. Like Carl, he would describe, they can be treated as values themselves and assigned to context, just like any other data, like an array or an object, or a number, or a string, or whatever.

Also, note the second arguments to spawn, which is a unique identifier for that actor that events.order ID that's how the parent's machine can send messages to the spawned actors later. So, for example, if we need to cancel an order, we can send the cancel events to that specific order. And that will pick up the events. And do whatever logic it needs to do, you know, to cancel that order. The upcoming XD version five is taking this. Everything is an actor approach to the next level by simplifying how it creates and works with actors. In version 4, it treated promises, observables, callbacks and other machines very special by internally adapting them to be actors. And so this made general use case is easy because it automatically did that for you, but it made other use cases harder. And so in version 5, this will need to be explicit. You will only be able to create and communicate with actors.

So, helper functions are going to make it easy to invoke actors such as promises, and also to spawn them. And so this is going to enable XD to be truly universal. Because, it will now be able to spawn and communicate with pretty much anything. That has an actor interface. And like I said, everything is an actor, so in general, an actor can send and receive pretty much any kind of event. So how can we consider other constructs, like promises and observables, to be actors themselves, so a promise can be considered an actor that can only ever send back? At most, one message, it resolved or rejected value. So at first, I didn't think that promises can receive anything. But in the browser, you can send in the board controller abort signal to a promise to abort it. There's, you know, that's about the only thing that a promise can receive, there's no other type of communication that you could have with promises. You can't send anything in flight. You know that's what things like websockets and other streams are for.

So, observables are like promises, but they can emit multiple values over time instead of just a single value over time. And so, observables can also emit a completion signal or an error signal. And when it sends one of those signals, the observable is then terminated and it could send no more values. In the TC39 observable spec, which hasn't been, you know, accepted or finalized, but we're still going to use it. It isn't specified that observables can receive any events, so in essence, they're one-way streams of data. However, RxJS, which is a very popular observable library, has what are known as subjects for this, and subjects can receive values and then emit those values directly and internally. An observable has some sort of source where it generates values, and that source can also act as something that receives values. If you, if you look at it that way, in short, observables, can you know? They still have that same message passing, idea, so they can be considered actors as well.

Now, React is a whole different story. If you have a parent's components that creates a child component, then it's pretty trivial to send in events from the child to the parents. We do this all the time. We just register an event handler as a function prop for the child, but sending in events from appearance to child is a whole different story. And of course, you could use context and do some sort of Redux sort of thing to achieve this, or if you don't want to use context. You could use hooks like use imperative handle, which is probably that hook that you never thought that you would touch in your life. And, you could also use rep to keep a reference to that imperative handle. That you pass the child and it could. Sort of be used that way. But, long story short, it's, um. There's no direct way to send some sort of transient, time based events from appearance to a child component.

Mainly because React wasn't really built this way, React propagates changes via props, and as props are its main method of communication. When the parent component is communicating with a child, it's doing so by changing its props. And the child component then has to interpret the fact that its props changed. And so it needs to act accordingly. And this is made even more difficult by reacts not being able to tell you which one of those props changed. Or, you know, maybe the local components they changed instead, and that's what caused a re-render, so maybe no props even changed at all. And so neither of those things are as explicit as a single time-based event. Now, since X data embraces the actor model, you can use the hooks and XState reacts in order to achieve this. The main idea is that you will create some sort of parents actor using used machine.

And that itself can create its own child actors, like we've seen with invoking spawn, that child actor, since it's just a value, it's just an object that you could pass anywhere. That actor is passed as a prop to the child component, now that the child component has the child actor, and the parent component has the parents actor. Both both components can communicate with each other via message passing between those actors in XState and so in X8 reacts. There's this useMachine hook that is used to reference, to uh. To actually create that actor from that machine, and that actor in that machine. We're going to, we could create child actors, and that might live in an array of actors that, you know. In this case, we call state.context.orders, and so we could pass each of those order actors to the order component. And again, this is just a value, just another, prop that you're passing to a component.

And so that gives us the actors current states, and it also gives us a function to send messages to that actor. So, for example, when we, send cancel events, that might in turn send cancel over. To the parents actor, and then the parent actor would know what to do. Long story short, using the useMachine and you service hooks is what allows you to do that. Parent child communication in React, or it doesn't even have to be necessarily parent's child. If you pass that child actor anywhere to any component, it will have a reference to that actor and still be able to communicate in exactly the same way. So there's a few, programming languages which, really evolved and embraced, this actor model that was originally created by Carl Hewitt and, you know, Allen key. And the most popular one, or the most well-known one, I would say, is probably Erlang, created by Joe Armstrong.

And so this is a language that's heavily used in telecommunications, which is where the actor model really shines, because it's this distributed computing environment. Now. Elixir is also built on the Erlang virtual machine, it's another popular language, and it's basically Ruby for Erlang. Akka is built on Scala, which is on the JVM, not the Earling virtual machine. And it's probably the most popular actor model implementation or framework out there in the wild, there's even Akka..js and Akka..net, and Pony is another lesser known object oriented actor model based languages or language. Now there's a lot of vector model implementations in JavaScript too, but I'm excited to introduce X-Actor, which is a new actor model implementation in JavaScript. That works seamlessly. With or without XState, it's not different than XState, it directly integrates with it, so please stay tuned for more information. And with that said, I hope you can take your newfound knowledge of the actor model and apply it to, to you. All of your applications, with or without any libraries.

Thank you, React Finland.

Play from 1:22:00

[Music] we are here today at the rise of Footlong in Tampere, 2019. That's where societal impact, learning and personal growth come together. [Music] feel 2019. Catering is reporting that the beer chill-down procedure is proceeding nominally, and the coffee machines are [Music] [Applause] people. Every morning when I wake up, I think about the colleagues I get to work with every day. I'm really proud of the team that I'm in right now. Every day in Digger, I get to come in and face new, challenging programming issues that we have so. I really like that about the workplace. In the current project, I get to work with very hot topics which is on that market right now. There's for example microservices, they talk about a lot, and also cloud computing, etc. If you're still searching for your past in the technology space, or want to try new technologies or push your career, I think DJ is definitely the place to apply for [Music]. You are learning, many different ways that are gonna be are really useful in the future.

Not just technology, but also like how to build a company, how to build a team, how to manage all of that. You have a lot of flexibility to deciding what kind of projects you want to work. You can move from team to team and work more focusing in front-end stuff if you want. Or you can learn more about. I don't know. Like data science, for example, Smartly offers really great opportunity if you want also to see the customer perspective. You can travel and meet these customers that are using your product, also participate in the events that we are organizing with that kind of customers. Me myself, I have the opportunity to be also speaking in those conferences and talking about how we develop the producting smartly. What are going to be new things that we are bringing on? Usually, our customers are really, really advanced, so you always learn how to even bring the product forward.

And you get really good and good feedback about the things that you. [Music] so, right now we're gonna, we're gonna talk to Ian and he will talk about Effector. So, like, why? What is an effector even, and why? You might want to use this in your project, so take it away. [Music] Hello everybody. Today we'll talk about Effector, which is a reactive state manager. Dive into it and still stay alive. Oh, my presentation won't work, I guess I should make a few key points about it. Starting from stores must be as light as possible. Since conceptually up, any app could be divided by responsibility scopes like authorization, payment, form, routing, and etc. From my point of view, there is should be, there should be not less than one store per responsibility scope. Quick note these mini stores should be easily combined as well. The second point is declarativeness, because we just need to point out what is connected, not how is connected.

Because Effector provides really rich possibilities in terms how connecting units are, said units, last, but not the least effectiveness. I guess some of you might think, what are you talking about? But this point means a lot. For example, Effector does not need any extra libraries to provide memorization mechanisms like Reselect, since it notifies only stores, which should be updated as well. It relies on nothing except from functions and objects. I mean, no classes, no decorators, no proxies, because we just don't need it to build a state manager at all. And also worth mention that the library avoids any breaking changes. Even in measure releases, since keeping comfortable and predictable for the users is a kind of major priority. And worth to mention. On the top, that measure releases are scheduled once per year, and the this library has pretty predictable API, and I'll show it to you a bit later. Here, I built a small visualization for application business logic imagine, like our business logic is a 3D object, and then this is a view from the top.

This example demonstrates stimulus over the time for our entry points in app, and the idea is that any application could be represented as a descript event flow. I'm pretty sure that they're gently won't lie to us because everything is connected, for sure. And we saw the view from the top, like top, and now we see the view, the front one. I placed a metaphor for it. So lightning rays illustrate. UEX scenarios Effector just asks user to statically initialize all the scenarios across the application. So, going back to picture, our front end will wait only for external stimulus to run the lightning strike. Since the form is already here. To start our technical introduction, we'll need to acknowledge one thing. Effector has three basic units first, one is an event, not an action. I think this is important since our system, in terms of business logic, the whole system across the application receives stimulus. Or, I guess we should better call it messages and just react to them, not act by itself.

I placed here an imper from an effector on the following slides. I'll just drop any imports since every operator or constructions. They'll see in future that they are directly imported from a factor. The same as a create event, an even is just a function that represent an intention. It could either have payload or not, depends on declaration. I tried out to build as much visuals as I can. This is an event in our virtual space, is a map event. Let's just have an example we declared an event and created a mapped event based on that. Which just doubles the value it's needed when we just need to transform our even payload without leaving the context, I guess, or everybody could imagine. An input where we set an estimation for the feature delivery. The developer just set a value and the mapped event will work out like a manager, just double the estimation value.

No offense intended. This is just about covering the risks, and I just worth to mention, double. The event will be triggered just after going further. We would not survive without stores, since we need to store our values across the application lifespan, and Storm is the second unit. Here. We just declare the store with an initial value, which is an empty array. Declared. An event called Watched show that means I, I send a message, I watch the show, and the show store illustrates my watch list which I already, which I have already watched. So, and on the bottom, we see a reaction. The API in that example is pretty close to Redux act. Instead of strings, we have a link to an event, and store React on that. And the second argument is a reducer. And interesting to know that if store returns the same value as the previous one, the update won't be triggered. This one just helps out our performance, so I built a visualization for that as well.

Event accurate, and the store just reacts on that. And do you, do you remember I talked about predictability? The store has the map method as well, that means mapped store. I just have a store called my age. I'm 26 and I created an app store which tells me am illegal to buy any Alco or not. So this one will be updated, only then the original store will be triggered.

Play from 1:58:00

So here's a visualization for it being closer to the last of three units, the. Most important one in terms of understanding, in my opinion, I'll start with a philosophical mystery. Do we hear the sound of a fallen tree in the forest if no one is nearby? Is it possible to consider that the non-observed world functions in the same way as the observed world, in other words, being closer to our reality? Function pureness depends on observer position. For example, any function produces a side effect on overall performance of your processor. So that's why Effector offers a unit that explicitly identifies a function that has side effects. For the level of business logic, this is important. We just set the observer position. This unit is called effect. As for Quad example, I implemented them, I would say, the most common example for side effects network requests. I mean, timers, third-party, APIs, I mean, everything.

What could, throw? An exception should be wrapped into an effect. It's it's very important, since the business logic should not should have no, any exceptions at all. We need to catch every of them. And they build a scenario based on failed effect. Here's the visualization, it's an effect when it's called the store field, called painting is set to true. I made an animation that means it's running. As soon as effect is resolved, it emits couple of events. In the first case, it's done event, which means effect has been resolved successfully, and finally, even, which means effect just has been resolved. And the pending store, in that case, is set to false. Another case when a fact emits two events called fail, and finally, finally, it's the same one, and the fail means effect has been resolved with an error. Pending is still false. Being closer to code is the field done is an event which called with params and result fields.

Params means an arguments which effect has been called with, and result means the return value of a handler inside it. Finally, event will be called with any of that params, and the fail event will be called with params again, which is an argument and an error field. Which is like an our exception with what the effect has been thrown. Worth to mention that even if we have a synchronous exception, not only asynchronous one, we should drop it into effect as well. And now we finished. With the basic units and going to the forward. This is an operator which helps you to connect any type of units between themselves. The same way as event map did. But forward helps you to connect units from different semantic values, for example, travel and current in currency means sitting at home for two weeks, travel means traveling around all the city, all mountains and stuff. They really different by its semantic value.

But the now time has come, and as soon as we travel, we need to be set at the current team. So that's why we directly connect these two units, looking something like this, as soon as the front field has been triggered, the two field will be triggered as well. Let's move to more complicated things, the second operator, called guard need, is needed when we need to not directly connect a couple of events or a couple of units, but conditionally connect them. The key field here is filter one, as soon as the filter field is set to truthfully value the source unit, it just take the value from the source unit, put it into the target one and trigger it. So that means as soon as I am legal to buy an Alco, we just take the payload from the event called want to buy Alco and pass it to the target, one actually bought an alcohol.

Sorry for an example, I'm just sitting home, not leaving it for a while. So here's some examples, and, here's a visualization of how it works. We have a bold store or a function in a filter field as soon as it said, not as soon as the filter returns false value. We have, like something like this, no connection between source and target, no connection. And in terms of everything went good, we just connect them. Now. We reached out the most complicated part, the mechanism of linking two units and resulting them into the third one, called sample. A big, pretty common example for it. You found the previous example with the guard key field was the filter one. But now clock filled the King of the Mountain. Since the operator will work only if the unit in clock field was triggered. Event has been called. Store update has been triggered.

In terms of clock will be a store. One or effect has been called doesn't, doesn't matter. So as soon as the clock failed is triggered, it just takes the payload from the source and, in the simplest case, just pass it to the target one. But here we have not the simplest one. We still have an optional FN field, which is a combinator function which lets us to pick a payload from the source and pick the payload from the clock as well. Transform that into something new and return it, maybe just combine two payloads, whatever you want. And with the return value of an fan function, target unit will be triggered. I pointed out that the clock failed away a dotted line and the source and clock units are resulting the target one. Back in the day, sometimes, or I would say any time, I had to stick together. Business logic and view layer, as David mentioned before regarding the event listeners, for example, or component deep Mount.

But now these times are gone. Congratulations the audience and me with that. Even here, I provided some links.

Play from 2:16:00

First one to reach me out directly via Telegram. second one for reaching out the English speaking community of an effector still on Telegram. Third link. I prepared for advanced GS, I guess a week ago. A workshop video haven't still arrived yet, but here you can see a rip for the. For the live example of a code with an effector, it contains, divided by chapters, so any of you could just run through the pull requests and just see the difference. Fourth link is a an official site of an effector, which contains documentation. Then appear and so on, and the last one is the patreon of an after. If you just values what he has done, so you can just support him. And it's not the end. Since the David attended with the actor thematic. I decided to put two extra slides for you, so let's just sit through. I intentionally avoided the word called domain.

I used responsibility scopes, as you remember, because Effector provides you domain itself as a as a namespace for events, stores, and effects. Why do we need it? Just to have an ability to hook store creation, the domain creation we, we could create subdomains as well to hook event creation or to hook. Event creation in terms of effect, what could be it useful for? We just have the one place where we could, handle all effects across the application, all the failed scenarios. For example, if our app is pretty simple and we just need to show up the same toaster across a whole application. And I guess we have 10, let's say, network requests. In case of fail, we definitely need to show up the toaster with the same message. And instead of forwarding from the fail, fields from an effect to the event, which will show up a toaster. We could just make it into one place and reduce our code base a bit.

And the pretty important example as well. Here's an example of the test you could see into the repo. I did not prepared it really well since I added it half an hour ago, but I just wanted to share it with you. So we just prepared some payload. And fork the domain. That means that we created a virtual instance of that domain and right, write it down into the scope variable and we just run the this domain. Just receives a message called sign in Okay, an event, it's actually an event and runs all the competitions which are following the sign in event. I guess David could answer me, what scope is? It's an actor. Thank you so much for watching me, that's it. Thank you so much Jan. My name is Jose Vyastrom. I'm a senior specialist here in Futurist Tambora office. My main area of focus is mobile applications. I've been developing different mobile applications, different platforms for almost 15 years and three years in futures.

We kind of take our job seriously, but on the other hand, we are kind of not taking ourselves too seriously. Lately, I've been working in this like remote setup where we are doing a project for German car manufacturer in cooperation with our Berlin and Helsinki teams. So we've been doing a full stack web development with React and TypeScript, and back-end site with serverless ABS lumber functions. That's been really nice project. So we were actually in Berlin for one week, meeting the client and getting the know with other teams from Futurists. So what makes me proud is being around these really talented individuals and being part of the. Company that really helps our clients to build something new. Best thing for working for futurists, in my opinion, is the people. There's so much talent that every day, basically you learn something new here.

Play from 2:26:00

Do [Music] so? [Applause]. Hi, I'm Laurie from Arma media and I'm here to talk to you about a global stage management in React. So let's begin. So, we really can't talk about React without Relax. Because Redux was really big in 2016, and the reason Relax got so popular, in my opinion, was because of the ecosystem. We have. The library, React Reacts, which was a really brilliant library. Then we had a Redux Dev tools, which was mind-blowing. Back then, I still remember using VRX Dev tools for the first time. So I think, and the second reason why Relax got those got so popular is, because it had functional concepts. It was heavily borrowing from element programming language, which is a functional language. And I think it really implemented the ELM architecture well in the JavaScript world. So developers loved it. I loved it, everyone loved it, but I think we loved it a bit too much because, we started overusing it, in my opinion, in hindsight, because, we started using Redux as a manually managed case for API requests.

And everyone knows Casing is really hard in programming. And we loved Redux so much. We did everything in Relax, we did the API requests in Redux tanks and all that. But nowadays, we have a better solution for that. If we look at React, Jewelry and SWR, those are libraries that automatically case responses from API, and those really, really help us to make apps more easily. So I think these two libraries will grow in the future. They have been growing pretty fast until now, but I think the trend will continue in the future. And that's why I believe we will face a decrease in need for global stage management. Because in the past, I think we did really too much, you know, in the Redux and all that, and we were relying, like, right way too much in it. So, I think in future we won't use that, you know, that much, global space anymore.

So so, yeah, so we will see a decrease in my opinion, and. Of course, we always have need for global state. So I think Recoil will be the one. This is just my opinion, of course, but the Recoil is it's a really easy to use library. I think recoil developers are quite connected to React core team. Because once when I asked in Twitter something about Recoil, then Abramo answered me and I thought, Hey, that's that guy is at a React core team and he's answering me about recoil. So those are really tightly connected, I believe, and that's the reason we might even see Recoilless features implemented in React in the future. I really hope it would happen, it would take React more to the framework side, but I don't mind. But anyways, that's what I believe will happen at some point. But anyways, take this with a grain of salt. This is just a speculation and I think my time's up. Have a have a nice, nice, conference and see you maybe in the actual real life conference.

Play from 2:32:00

Okay, bye [Music]. The only one I could pronounce the last name. Christian actually works with me at Sandbox and he's gonna talk about stitches, which is a CSS in JS library? It's not really a library, it's kind of a different way of looking at CSS and JS. I really like it, I hope you like it too, so take it away, Christian and good luck. Okay, hello and welcome to this presentation on reinventing CSS in JS the story of Stitches. My name is Christian Alfoni, I work at code Sandbox. And typically, I concern myself with state management. And I was supposed to talk about state management today, but I felt I had a more important story to talk about. So please forgive me for giving me that. It's just that I have all these ideas all the time, and I'm, even though I work with, like state management, in overmind and cerebral, I'm like, concerned with everything.

Like, if I see something that annoys me or doesn't work, or I feel inspired, I kind of have to dive into it, dive into it. So what we're going to talk about today is not I'm, I'm not going to like, sell you stitches, or anything like that. I just want to talk about how ideas turns into. Concepts through iterations and what the inspirations you can have doing that, and also what collaborations ties into that. And basically give an example of a journey of how an idea can turn into a concept. So typically where I get kind of my ideas and inspirations from is on my Twitter feed, like, it's stuff pop up there all the time. Not too long ago, there was a lot about Tailwind CSS, and I'm I like, I had heard about Tailwind CSS, but I never looked into it. But since there was like an overflow on Twitter, I, I thought I would kind of give it a chance.

And at least look at the documentation. And the example you see here is from the front page. And what I instantly started thinking was, this is. This is interesting because you're not writing CSS properties, you're just writing class names, which kind of means that it's an abstraction over what you normally do in CSS. Just like we build libraries, we create abstractions over difficult parts of the browser APIs to make it better, more consistent, and more predictable. But they were just using class names for this, and what they're specifically doing is that they're creating atomic class names, meaning that each class name represents a single CSS rule. And so I found that really interesting. And and through experience, I've had a really hard time working with designers to talk about. How do we transfer the design into actual, like technical CSS properties? And we don't speak the same language at all.

But with this abstraction, you kind of get into this world where you start to talk, you can start talking about the same thing with designers. Kind of like they typically talk about tokens, and you could say that these are kind of like tokens anyways. 101 CSS is super successful and, there has to be like something to learn from this. But how would it kind of look like in, the world I come from, which is like, React and CSS and JS and stuff like that? And maybe we could find some ways to improve the approach. Now. When I get these inspirations and ideas, I never really go on the web and search for someone else, like, has anyone else done? This before, because if I do that, I get discouraged and I don't execute on that idea or inspiration. So I completely ignored that. I didn't even read all the documentation of Tailwind CSS, I just went straight ahead on an idea.

So the first iteration of Stitches was called Tailwind CSS class names. And what I wanted to do there was basically improve the intellisense because I didn't know that, stitches had, sorry, that Tailwind CSS had an, an extension for VS code that gave you intellisense. But no matter that, intellisense is limited to operating on the class name prop, like in React, because it has to understand that these strings represents class names. So that's the only way it can know that if you were to create a variable with some random Tailwind CSS class name, it wouldn't be able to help you. Also, because of this, there's like, no good way to do composition, you have to put everything into the class name property. Like telling. CSS has some separate system with configuration and compilation and stuff to do this and create new types of class names. But yeah, I wanted this to just work in JavaScript, so what I did is. I created this library called Tailwind CSS class names, and I took the the class names library.

If you're familiar with that, it's basically just a function that allows you to compose together class names. So I exported that as TW, but it's literally calling the class names function. The only thing I did was to type it, so now calling that function the intellisense will give you the class names of Tailwind CSS. What this also gives out of the box is composition. So, as you can see in this example, you might have a container and then you want a red container where you compose in the container and you add red. 500, for example. So, that kind of came out of the box, and this is actually a library that's maintained now by someone else and it's being used by some developers. So already here, like, there's some value here and I wanted to explain how the typing works. So basically, all, every single class name in Taylor and CSS is a type, and you can see this T classes, uh? Type that kind of composes them all together, and then we have this T tailwind string type, and that's basically.

Even though calling TW returns a string, we don't want to type it as a string. And the reason is that you can have one TW function and the return result of that you use in another TW function. But we want to give errors when you give a random string to the TW function, we only want you to pass in class names from table. In CSS or another composition, any random string gives an error. So by giving this specific string as a return type, we are able to put that in as one of the valid arguments to TW. Alongside all the other class names, null undefined the object syntax that comes from class names, the class names library itself. And then we just create that type, we export it, and the class name property of. React is happy because it, it just needs a string, it doesn't matter if it's, like, typed as a specific string, as we can see here.

So yeah, and this gives a really nice typing and intelligence experience. But there is a an issue with this approach, and that is with tail. In CSS, you have something called CSS purging, so when you insert your class names into the class name property of React, the purging is able to look at all these class name properties. Figure out what class names you're actually using and remove what you're not using from the CSS file, minimizing the bundle size. As far as I know, you can't really do that when you just put it into JavaScript like this. So there was no way to, like, handle that. So I woke up one morning, with another idea, and that became iteration two called Classy UI. And basically, that idea was to use a bubble plugin to just go through your files and produce a CSS file on the fly, based on, on the definition you had created.

But I wanted it to be a low level implementation, so that I didn't have to map all the class names into the CSS rules. They were supposed to produce. So rather like a low level API, where you could build, Tailwind CSS on top of that, also wanted to. Improve their intellisense a little bit instead of having like one giant list of class names. It could be improved and also some specificity issues, which we'll get back to. But to do this, I had to call my brother in arms. Fabrice, he is the go-to guy for me when I have to deal with stuff I don't understand. In this case, bubble plugins and ASDs abstract syntax trees. So, yeah, he joined the project at this point now to figure out how we wanted to express this. We kind of looked at the anatomy of a utility, as they call it in Intel and CSS, where they kind of prefix with an optional pseudo, which is hover disabled, or whatever.

And then they have like a custom CSS property P representing padding. And then they have like a value or a theme, as they call it, so the value kind of comes from the theme. And so what we did is that we explicitly called it an atom instead, and we said that. The CSS prop is first, then you have a token representing a value for that CSS prop, and then you could add the pseudo after that. So to make this work, we have to map these tokens to CSS properties. So, for example, we wanted to you to define some colors, and then these colors map to different CSS properties, being color, border color, background color, and so on. And there's someone who's actually done some work on this. There's a project called system UI, I believe it's system UI, which, is like an open project where people collaborate. To create these categories of tokens and what CSS properties they should map to.

So you would just go in and configure the project. You would insert the tokens representing a value, and then you will be able to use these tokens on the different CSS properties. So this is how it will be expressed with class UI, you import tokens and compose from the library, and then you would compose these tokens together. In terms of intellisense, you now have. You point to tokens, you dot, you get a list of CSS properties, you choose a CSS property, you dot, you get a list of, of tokens. Which is a really. Nice experience. And in this case, we're adding a background color of Grade 20 and a color of red 50.. What's kind of cool I guess about this is that it doesn't actually run this at runtime. The Bubble plugin goes in and converts this into actual class names, and then it uses the syntax to figure out how to write the rule. So in this case, you can see that it knows that it needs to write a background color with whatever value is behind grade 20, and the same for color.

So it's not actually running, anything, uh. In terms of pseudos, as we talked about, you were able to now put that behind the token. And this syntax looks a little bit weird, right? But since we're not actually going to run this, we had a lot of freedom, I would say in retrospect, too much freedom in the syntax. Because we just needed to read the syntax of from the bubble plugin and then convert it into something, that was actually run at runtime, what's, uh? What's kind of interesting was because we wanted to be able to build a Tailwind CSS. On top of this, we introduced custom utilities so that you could, for example, add like, a padding X thing that used the space tokens and then mapped that to like, padding left and padding, padding right. For example, what we also introduced here was taken from Tail and CSS, which was a concept called screens. And basically, you just define a media query, and we wanted to do it as dynamically as possible.

So you just create a function that returns a media query. And then you insert. At what position in this string do we insert the rules for that screen? So the way you would use these screens is that they would become imports, so in this case, you can import tablet. And it worked just like the compose, but now they would actually be inserted inside a media query. What we also realize here is that these tokens are really great for theming. So, typically, you think about theming as having a bunch of values that you consume inside your style definitions, but we think of theming as overriding tokens. And what's really cool about that is that we can look. At these tokens, and we can convert them into CSS variables. And then when you define a theme, you override some tokens, meaning you override some CSS variables. So when you trigger the theme, it's just a CSS operation.

There's no re-rendering or providing new props or anything like that, it's just a simple switch for the CSS engine. So that was really cool, but there was a specificity issue here, so this is a simple example of that. Imagine that in the style sheet, we have like P4 with padding 2 RAM, and P6 with padding 3 RAM. And then we insert the class names on an element here. And, as you would intuitively think, here is that. Since we have P for last, it should trigger padding to REM, but it doesn't do that because P6 is defined last in the style sheet. And then that, and then it wins. And I actually didn't know this going into this. And it's completely unintuitive and there's probably a good reason for it working like this. But it's really, really, annoying and very, very tricky to solve if you want to solve it inside the style sheet.

So we needed to find like a way to handle this, and the way we handled it is that. If you were to have a have a base button, as you can see here with a background color gray 20 and the color of red 50.. Then you wanted to create a button composition where you use the base button and you rather want to add the color blue 50.. Now the problem is that Blue 50 might have been used in a different composition and been injected into the style sheet before red 50. Which means that when we now we would now introduce both the class name for red 50 and Blue 50, we would end up with red 50, which is not what you want. But what we are able to do is actually look at the CSS properties and we know that. Okay, you have two colors here, Blue 50 is the last color, let's just remove the class name of Red50, and that's basically what Classy UI does.

It allows you to do these compositions, but it understands what you have composed, and then it removes the same group of CSS. Properties so that you always end up with the last one. But yeah, then we had a little chat with Max Deuber, who's the creator of style components. But there's lots of people working on that now. And we talked about classy UI, and we were very honest about it being like, experimental. And what didn't work very well, and what didn't work very well was that you had to install the Bubble plugin, set it up in your build tools. And sometimes that's a little bit tricky, for example, in like Next.js, and and like Gatsby and stuff like that. And we did some crazy stuff. Like, based on our configuration, we would produce the typing when the Bubble plug-in ran, meaning that VS code didn't always pick up the changes in your configuration when you restarted.

When you built the project, we actually built the CSS file from the Bubble plugin plugin, meaning that we wrote the CSS file when the bubble process exited. Which was at different points in time in different build solutions, which just caused a lot of headache. But then Max asked us, like, well, why don't you take this stuff and put it into CSS NGs, uh. And I think I was a little bit defensive, because we had put so much effort into this. I wanted to, like, explore some other things. But it didn't take long. And I was kind of like, yeah, why don't we put it into CSS in JS? And then Stitches was born, the core package of stitches, and what we wanted to do here was to move it into CSS in JS. We wanted to keep it atomic. So, instead of creating one class name per definition, we created the class name, Pert's unique CSS property value, Sudo, and so on.

But we wanted to keep all the cool stuff we have figured out, or like experienced, like tokens, screens, custom CSS properties and the way we did theming, we wanted to keep all of that. So the API of stitches, requires you to create an instance because you have to pass in like, what tokens are you going to use? What screens are you going to use? Are you going? Do you have some custom utilities? And, based on this, you're able to. Create a theme, and it works the same way. You override the tokens and you get the class name back where, which you can insert wherever you want. On any element, and the elements that are children of that element will then be themed by the CSS engine. There's no re-rendering or anything like that. Yes, so um. The initial API we created was heavily inspired by a classy UI, so with class UI, you had this compose and you had the tokens, so we kind of continued that.

But you rather imported the CSS instance where you composed by calling CSS properties as functions. Because now it's like, properly in JavaScript and it's actually running in the runtime. And you will pass in, the tokens, or, like, the value for that property, um. And if you were going to do like sudos and selectors and stuff, you would pass that as a second argument. And this was actually a pretty nice, it was a really nice experience. Especially related to intellisense, because you kind of dotted into everything, and whenever you like dotted or called the CSS property, you would always. The intellisense would always pop up at the right time. And it felt really nice. Yes, what? We also needed to, Oh, did I jump? Skip on? Yes, sorry. So to handle the screens, we introduced, as you can see on the last one here, a property, so, like, you could, point to the screen as a property.

So in this case, CSS.tablet.color, which kind of removed the grouping behavior. So, I'm not sure why we did that, but yeah, we'll get back to that. We had to test if our approach, made any sense in terms of performance, like, was this slower or faster, or like, the same? And so we did some initial benchmarking and we were happy to see that we were. Even. Like, in the first iteration, we were a little bit faster than even emotion, but like this doesn't matter, like emotion and all the others are perfectly fast enough. But it was more to see, are we slower? But we weren't slower, and that was really encouraging. But yeah, the functional API we had, even though it gave like a really nice intellisense experience, it wasn't like it wasn't. Familiar, and that's okay, I completely understand that. So we decided to turn it into object syntax, so basically it will feel more familiar for new people. And the nice thing is, now we have our screens back as a grouping type of API, where the property, in this case, is tablet.

And then you will be able to define, underneath there. But what's important here is that every single property here results in a unique class name. It's not like one single class. Cool. And then we got into a fourth iteration because we wanted to try this on, as a styled API, how would that look like? I am looking at the latest trends. We wanted it to be polymorphic, meaning we wanted to have the as prop. And I had also been looking into how the styled APIs allows you to consume props inside their definitions. And like, I don't like that, there's something fishy about it for me. One thing being that you have this function making it dynamic, so whenever the whenever the style component is touch, it needs to re-render to, like, re-evaluate that function. But more so, the thing with the props leaking into the underlying element in the DOM.

Like, there are ways to handle this, but there's no consensus on this is the way we should handle this. Which makes me think that maybe this isn't such a good idea. So I was thinking about a way to kind of replace props with something else. And then, I got contacted by Pedro from this startup called modules. Um. And he had some, thoughts on like variants and really wanted to see a variance. API. So I thought this, this is perfect because this kind of meets with or aligns with my thoughts. So, we wanted to replace props with variants. Okay, so the style API looks, as you would expect, you can, like, point to an element and then you pass in a definition, just like the core package we went through. But then you have this second argument, and this second argument are the variants. So in this case, we have two different variants, one of them called variant and the other one called size.

And then you can pass a value to. The variant like activate a variant, in this case a muted variant, or a small or large size, and then you have, like, the CSS definition behind it. Now, the really good thing is that this is completely static, meaning that there's no re-evaluation of this. It, it runs it once, and then it's ready to go. The way you would consume. This is that these variants are, of course, exposed as props, meaning that, in this case, we, we want, the variant muted if it's disabled, for example. What we also allow you to do is to pass in an object where you actually get the configured screens, and you can activate different variants on different screens, the really cool thing is that you can't get into any issues with, uh. Passing props, like the wrong props. Down to the underlying elements, because we know what are the variant props? Meaning we can remove them from the props before passing the rest of the props down to the underlying element.

And what I also like about this, arguably, is that you kind of you have the static parts in your styling, and then you have the dynamic parts where you consume, the component where you actually have your props. And your state and all this stuff. You, you, you do it in the component. You don't have to jump into the style definition to understand how these different props actually affects the styling. They are kind of been decoupled, which I think is a really good thing, not just performance wise, but and props leaking, but just as a concept. So we had to do some benchmarking on this as well. Again. Not to, like, say that we're faster than anyone, but see how our approach actually affects the performance. This is not to say that style components is slow in any way, like if it was too slow, people wouldn't use it. So that's not the point of this. The point is just when we define unique definitions or like style components, so every style component has, like a unique.

It needs to produce a new class name. Then it's like the same little bit faster, but if we are to define the same properties, on the style component definitions, then it suddenly gets insanely faster. And. That's the thing about the atomic approach is like the CSS properties of your application throughout all your style components. Are they usually the same, or are they different? And they are usually the same? Because that's what it means to do a great design, you want to constrain, the way things look into, like specific spacings, sizes, colors and stuff like that. So it makes a ton of sense. And that's like the definition, part of it, then it's like, how fast is it? When you consume like a static definition, meaning you don't have a function in your definition, it's about the same. And if you consume a dynamic, meaning that in style components, you would have a function in stitches, you would have a variant. It's like a little bit faster, but again, this is not about this was more to see if it's slower or faster, kind of to prove our point.

And then we're here at the last iteration, iteration five, and that iteration is basically, that. The repo has been transferred to modules. Which I mentioned is a startup that's building a really, really cool service. And they have some ideas on how to help their customers and users to build like epic, styling of projects. And I'm like, super excited to see where, where they take this, take, this project. So what my point of this talk is?

Play from 2:40:00

Whenever you get an idea or an inspiration, don't go on the web and see if anyone's done it before, just go straight ahead and do something with it. Like, the worst thing that can happen is that someone has done it before. But then you have actually learned something, which is always great. But sometimes you do something a little bit differently, or maybe very differently, like you have a completely novel idea and then that can become something really cool. And so I just want to say, keep reinventing and thanks for listening to my talk and have a great day. [Music] so she was the freedom across the heart of the world. [Music] is that butterflies? Um? [Music] across the house? [Applause], right? [Music] is there. Is because we are doing an audio, audio thing. But maybe your, your thing is the style guide, and your thing is, that's a good question I love. The fact, I definitely feel like the nine months or so that I've been here, then I, I've learned just so much.

Play from 3:10:00

The way that the hiring and the sort of culture is set up here means that there's just really great bunch of bright people. This this attitude of hiring to elevate is really like motivating, it's another great learning experience. I remember, like attending the first Friday demos before I was working here, and like, there was just some really like, great feedback, great questions. Like people are really picking into the details, not some high level, abstract thing. But you know, why did you call that button, that thing at first thing? Okay, why is this relevant to the whole company? We're all sat here. But you realize that it's just this kind of healthy feedback working in practice, and it doesn't even matter what the feedback was. It's just the fact that a developer should expect to hear feedback and learn to take it, and learn to present their ideas. And and sell t-minus 30 seconds that what we have here is an entire generation of young people.

We are here today at the rise of Footlong in Tampere, 2019. That's where societal impact, learning and personal growth come together. [Music] so catering is reporting that the beer children procedure is proceeding nominally, and the coffee machines are so [Music] is. Working out autonomously is something that many companies announce, but in fact is something that is really difficult to achieve from a company perspective. But I like how it smartly enforce that every team has the capacity to decide what technologies to use and how to solve their problems autonomously. And the leadership team believe on that and give us, like freedom. We decide company-wise what are going to be like the objectives for the next half and year. And then teams autonomously decide how they can contribute to those goals. Each team is trust to do the best. Usually when you start in a company you have to just move fast and break things. But at some point when the company grows, those early days code can start to be problematic when you need to scale some part of the product.

So now we have, taking that challenge, and with the help also from the leadership, like we have been. Like, bringing this forward like this can be a problem in the future. So they also have gave us like that kind of freedom to decide. Like, okay, if you think that this is, uh? Like? Fixing things is more important at this moment than just building like new features on top of broken things like, go ahead and fix it. So right now we are building a new product that is gonna take care of fixing the whole things that we felt that has been broken for a while. So that brings us together to the topic of how autonomous the team can be and how. What kind of decisions you can take, and smartly, I'm happy that you can take those decisions and prioritize over what maybe a leadership team could be considering at the moment.

[Applause] [Music] this is the ultimate IT brand film.

Play from 3:15:00

The visuals are chosen by an A.I. which analyzed dozens of other I.T brand films. Hello, I'm a deep male voice. Cybercom provides innovative I.T solutions on a global scale. That's why this globe shoots out data Pew. We hope that this beautiful forest makes you associate beautiful Nordic nature with our company, because we too are Nordic and beautiful. Here at Cybercom, we like to keep our employees happy. And that's why all the paid actors in this video will be smiling, no matter where they are or what they're doing. And what does running have to do with I.T? Well, not much, but it makes for some great emotional footage. We have offices in all sorts of places, including Helsinki, Copenhagen, Stockholm and Warsaw, but there's no skyscrapers. So this is Shanghai, we do not have an office in Shanghai. To us, coding is art, but, according to A.I, it doesn't look cool enough, so this is a painter. Instead, our coders get adequate compensation for their work, unlike many artists.

A. I suggest that we should show a person wearing virtual reality goggles. I think he should be wearing a helmet instead. And these don't exist out of sci-fi movies. Oh, dear, still so much data. We have to speed things up now. Charge my house, supercar, Cute kids, woodworking, what the what ballpark? What's what's going on? Well, that didn't work. Hey, maybe we should use the AI to actually do something useful. She was the freedom. [Music] her voice, oh, [Applause] [Music] there is. [Applause]. [Music]. Butterflies separate you because we are doing an audio thing, but maybe your thing is the style guide and your thing is [Music] foreign. So okay, and I, there was the voice in my head again, sorry about that.

Play from 3:23:00

And yeah, we're done, we're done. Today. I just have a couple more things that I want to tell you. This will be two minutes, so the first thing is that there is going to be. Our next event is going to be about design systems, and it's going to be on the 22nd of September. And we will have the exact S, the exact same model, we'll have the exact same model of free and premium. So please show up, let us know your thoughts and let's talk about design systems. And yeah, that's it, so thank you so much for coming. I'm not gonna try and pronounce, Finnish, because I can't even pronounce my own language sometimes. Please join us on Slack and continue this, this discussion, and let's talk about things like this, and please come and see the one about design systems. Thank you so much for reacting, for having me.

It has been a pleasure and goodbye. Thank you so much. [Music] do.

Play from 3:41:00