 Now all have a seat. So I hope you guys know each other much better. We'll be spending at least three hours with one another. So thank you so much for coming down once again this morning. So without any further ado, I'll pass and kick off this whole entire morning and this entire session by passing it over to our technical guru to start off this session. Thank you. Hello. Yep. Hey, everyone. Welcome to our workshop on N11UX with React2DUX. So before we start off, how many of you know React2DUX? Oh, quite a few number there. Yeah, that's good. OK, so I'll first introduce the speakers and co-facilitators here. Jonathan Alex, who is tech lead at Paloite. Jonathan is a software engineer and myself guru that will be today's speakers. Co-facilitators today would be Akilan and Shiva. They'll be helping you out with any problems that you have in setting up workspace or any blockers that you have. So please raise your hand whenever you have any issue. So they'll come to you and they'll help you out. Cool? So the agenda for today. So first we'll start off with introduction about ourselves and what we do. Next we'll straight away dive into setting up your workspace. Then we start off with the workshop. We have broken down into three small workshops. First would be on style components and themes. Why style components and themes would be first we'll look into what is a library that's available to set up a proper styling architecture. And next we dive into Optimistic UX, how to set up Optimistic UX app. So we'll be using a chat app for that. And finally, the final workshop would be on React performance. How you can make your applications buttery smooth. Yeah? Coming to the introduction. Paloity is a multinational company which specializes in human-centered design. And we also do agile and digital transformations to many forward-thinking companies. We take pride in telling that we are small enough to care but big enough to deliver. We are around 300 experts from different nationalities and cultures spread across the globe in multiple offices at Mexico, France, Hong Kong, Thailand, Singapore, and Australia. At Palo, we have a diverse talent pool which consists of agile coaches, scrum masters, architects, developers, UX designers, data scientists, et cetera. So we have everyone from the ideation phase to the production phase. Let's straight away dive into setup and preparation where facilitators will help you out. Let's get set first. Please check if you have the latest version of Node.js. Chrome browser, because for React performance, we'll be using Chrome developer tools. And you can have your preferred IDE. So if you don't have any one of these, please let us know. So we'll pause. If you have latest Node.js and Chrome, then we'll continue. Anyone? Everyone has Chrome on their system? OK, cool. So you can clone our GitHub repo, which is over here. Also, we'll be providing you T-shirts later on. So you can scan the QR code that's on the T-shirt and it'll straight away take you to the GitHub repository. So please clone this repository and CD into that workspace folder. It's over here on the screen if you can't see that. So there's an open Wi-Fi network, which you can connect to. Sorry about that. I didn't inform you beforehand. So Shangri-La Wi-Fi network. So you can connect to it. No password is required. And you can use that. Thank you. Once you have cloned the repo, just do a NPM install. And you can do a NPM start. So you should get a quick chat app with just a login page and a home screen for the chat app. All good? So next, we'll look into the boilerplate. Why we didn't use Create React app. Simple reason being for this workshop, we thought it's Create React tap as too many features and it would be OK. So we just kept it as simple as possible. We also put in a cache loader there so to make the builds faster. And we have converted all relative parts within the source folder into an absolute path using a specific configuration for Babel transform there. So that's about the bundling and the build tool. Coming to webpack statistics, we have also put in a script. I can quickly, for people who are familiar with webpack, you know that there's a statistics plug-in which you can use to analyze your bundles. So all that you need to do is NPM run stats. So when you do NPM run stats, it creates a bundle and it creates stats for your bundle. Give a quick explanation about that. So as you can see, you get a webpack visualizer which tells you what are the libraries that are taking up more space based on percentage and you have a more detailed view over here. So you can do NPM run stats and you automatically get this visualization on your systems. Yeah, and there's one more proper bundle analyzer which allows you to see what are all the libraries under node modules and what are the libraries that are in the source folder, et cetera. So which library is taking more space? So immutable.js is something that's consuming more space. This is how you can analyze your bundle and find libraries which are taking more space and find alternatives for those libraries to replace them with. So all that you need to do is NPM run stats. Oh, there. So for that, we have created a separate statistics.js. This is a webpack configuration again. So you can look into this and you can create your own stats pipeline for your projects. So we won't dig deep into this. It's just a quick explanation of why we have put up that statistics. Yes, when you do NPM run stats, there are three separate tabs that open up. Yeah, you can check there are three tabs that open up. Like they give different perspective. One would be on the bundle size. One would be showing percentages. One would show the other one is kind of a detailed analysis of your bundle, which provides you detailed analysis of your bundle. So there are three tabs that open up. Let's give two minutes, the guys who are having issues. Okay, we'll continue because there are a few more slides where we won't be doing any workshops. So I'll try to explain further. And by the time we'll try to resolve the issues that you guys are having. Yeah? Okay, sure, thanks. So we'll dive into the first workshop, style components. How many of you know style components here? Okay, very few. For people who know style components, it's just going to be introduction about style components. How do you do themes? How do you pass props, et cetera? So this would warm you up. This workshop is to warm you up for what's coming next on Optimistic UX and React performance. So let me straight away show you this. This was Google search engine when it was being demoed in 1990s. So as you can see, the CSS that was used was very basic. Today if you see we have such complex applications where multiple distributed teams are working on it, et cetera. So having a proper style architecture is very important in your apps, right? So let's look into CSS evolution. How we have reached style components today or CSS and JS. It's a library which represents CSS and JS. So we started off with CSS in 1993. CSS was just introduced to style scientific documents. Web was created for scientific documents. So CSS was just created for that and nobody knew that CSS would be what it is today. So CSS is still alive and it's doing great. But we ran into a lot of issues with CSS. First of all, we used to use inline CSS in the beginning. Then you couldn't extend it the way you wanted to. And then came in the important keyword there which made it even more difficult for us to understand how certain CSS is being read by the browser. So to solve that, we came up with preprocessors, CSS, less. What preprocessors did was they brought in mixins, variables, nesting of your CSS so that it's easy to understand and read. But what CSS less didn't solve was a style architecture which will allow you to predict or be confident about whatever styles that you're writing. So after that came in CSS patterns like BAM. Anyone over here know BAM? What's BAM? Yeah, can you tell what's BAM? Can you explain what's BAM? Yeah, exactly. So it's a pattern, block element modifier. If you take a menu, a menu is a block, a menu item is element and modifier can be the state like active or disabled state of your menu. So block element modifier convention was used to write your CSS and also fill up your markup with a lot of CSS class names. So disadvantages, BAM brought in a lot of semanticity into CSS, but at the same time it even made a markup unnecessarily semantic, it blotted the markup. So we had to find a way to automate BAM, okay? So that's why CSS modules came in and React started to use CSS modules from the beginning and a lot of our projects today are using CSS modules. What CSS modules brought in was true encapsulation. It automated BAM, so you could just forget about your component class names, having clashes with other components, class names. But CSS modules still didn't bring in the style, architecture, predictability and consistency. Then in 2017, style components was introduced. Style components is a library which implements CSS in JS. Initially there was a lot of friction because people thought CSS is going to come to an end if CSS in JS gets ahead and also people thought it's not performant, but over the year in 2017 we have seen that style components has been introduced in many large scale projects and it's been used successfully. What are style components? They're just pure visual primitives, so it's pure visual components. They use template little notation of ESX, so it means that they blend ESX and CSS in a good way. So they separate UI from the functional and stateful components. Also one more thing that's very important when you're working on large teams is the design and development was a handoff previously. Now it can be continuous collaboration. So you can build core components, not only for the browser based apps, but also for your native apps using style components. So let's get started and create a simple style component and after that we'll look into the teaming of style components and look into how passing props and how to reuse and extend. And finally, in the end I'll talk about what's the future of our style components. Okay, so please check out this branch and we'll get started from there. Also before we start over here, as you can see we have created for each step a feature branch which has the completed code. So if you're stuck and if you wanna quickly switch to that branch and get the final code, you can switch to that branch. So for style components it will be step one, step two, step three, step four, step five. So we start off with step one and we build. If you get stuck anywhere, when we are going through any of the features, you can just switch to that and you can yeah, start coding from there. Once you have checked out branch, I'll quickly explain. We have also put a style comms.txt in your main workspace. Here we have actually created, put in the code that which you can copy paste into your components whenever we are trying to do any exercise. But I'll go slow so you would still be able to code instead of just copy pasting. So if you're stuck, you can still copy paste either switch branch or you can copy paste from here. This one, we aren't able to zoom in, that's out there. You don't have to worry about the code. I'll be typing along with you guys. So you can see on my workspace and you can type along. If you want this code, it's already present in your workspace. As I told, if you go into style comms.txt, so you have all the code there. Yeah, cool. Let us know when you're ready. All of you, if you're ready, just let me know. Let's start off. So if you look into the code, we have app.jsx where we have created a rod to style comp. So basically all the screens or pages are in the roots folder, and the components folder contains a lot of style components. So if you want to see complex examples about style components, you can look into the components folder. We have created a few style components which we'll be using in the chat application later on. To keep the workshop simple on style components, we'll be just using one single file that would be style comp.jsx. Here as you can see, we have a basic React component which just renders a button. So you can do an NPM start after you switch branch, and you should be able to see HTML button. Let's build a first style component. So in style comp.jsx, to use style components, all that you need to do is in your packages, you can just add a dependency on style components. It's already been added, so you need not do NPM install again. So now we import style components. So you import style components, and we will create a style component as a custom button. So we use template notation. And as you can see, I'm just hooking into the native button element. So we need to use backticks. We'll just give a background for it. I won't be using hex notation here, I'll just use it as light blue. Once that is done, you can now render your custom button. I'm sorry, I made a spelling mistake there. It's almost, yeah, I'm good. Good morning everybody. I'm sorry to interrupt this important program for a moment. I just want to say hello and good morning, and I hope you're settled in quite nightly. I'm going to be next between 10 and 11. We have Nitro Coffee all day, when he allows you to leave, only then. You may join us at the Hackadeck for Nitro Coffee. It looks a little bit like a Guinness with a thick foam on top. And we have a cocktail robot there. And the robot reacts to QR codes. You find one of those already on our social media pages on twitter.com.flashjs.comfacia and facebook.com.flashjs.comfacia. For now only the non-alcoholic version. Later today you're going to get the alcoholic version there too. So make sure you follow us. You get that QR code. Just show it to the robots and make your cocktail. That's about it. I'll leave it to Guru to make your great morning from here and then enjoy. And I hope you all take something home from here. Oh, yeah. You want to join for a photo? Oh, yeah, sure. Just there? So I have you as a host as well. Oh, yeah, sure. OK, everybody, cheers. You want to lean a bit? No. Now I said it was the wrong picture. Thank you. So you must have your first style component. So we'll move ahead. So next we'll look into how can you pass custom props. It's not just custom props. You can even pass in attribute HTML attributes to your button. So I'll quickly show you that you can just make this button disabled. And the button would be disabled. So it means that the HTML attributes are being passed to the styled component. Now let's look into how we can pass custom props. So what we'll do is we'll create three buttons, a small, a medium, and a large button. And we'll see how we can use the same style component by passing props to it. So we'll create three buttons. We use a fragment tag. Just a minute. I'll tell you. I'm on step two. So we have created our custom props, small, medium, and large. Now we are going to read those props within our style component. So let's create a margin so that the buttons are spread out. Let's put in a margin. So now we use the template and literal notation to read properties or read JavaScript within the templating notation. So for that, props. And then once we read the props, we can set whatever styling you need. So it's CSS dynamically being modified during runtime. So if you look into your screen now, there are three buttons with variable sizes. This is how we can pass custom props. An interesting feature there with these factics. They're not evaluated until later. Could you show me how you might write? You could write that without the magic factics sort of in. If we had stars on a button with brackets, would it be possible to write it in a more traditional way? I'm just curious. So if I use brackets, it doesn't work because it's. But would there be a way? I mean, I tried doing this, but this didn't work. Would there be a way to do it? No. No, it uses ESX template literal notation. So that's what style components comes with. But if you look into other CSS and JS libraries, they use other notations like you can pass in a function. And yeah, then you can do a lot of things. Here everything would be passed as props. And then you can dynamically switch. So it's working. We'll move on to the next topic, themes. So style architecture, whenever you're doing any style architecture, you should always think about themes. Because you don't know how big your product is going to grow and how many clients would be buying your product. And you might have to build different themes for different clients, right? Traditionally, in a simple way, using just CSS, how we used to achieve this. So on the body tag, if you put up a class called theme light or theme dark, okay? And you can use any class within for all the elements within the body. And now using CSS cascading or I would say hierarchy, theme light has button.primary which says background light blue and theme dark has button.primary which says background blue. So what we used to do over here, if you have 10 themes in your application, we had to package all these 10 themes together and ship it to the browser for the browser to read them. Or you could do lazy loading on similar lines. But now with CSS and JS, you can dynamically change props, variables, et cetera. And you can achieve this. One thing that style components comes inbuilt with is theme provider. So you can have specific sections of your application running on a certain theme and other sections running on a different theme if you want, okay? So we'll quickly look into how we can create a theme for two custom buttons and having different backgrounds. So basically by reading props. So for that, we need to first import theme provider. And then I'll remove the props for padding and I'll just give a padding of. Once that is done, so you can define your themes by using objects. So we'll create two themes, theme one and theme two. So we'll set the primary color to light blue for theme one. And for theme two, we'll say hello. How do you use these props here? Would be that within your fragment, you can call the theme provider. And to this theme provider, you can pass in your theme object that you just now created. So for the first theme provider, we'll send it, we'll give it theme one as prop and for this second theme provider, we'll give theme two. Now you can copy paste the custom button within the theme provider. You can remove the small prop, et cetera. We are done with the JSX markup. Now we need to read the theme one and theme twos primary color within our style component. So for that, it's very simple. So you just read props.team.primary and automatically your buttons should be themed. So now you can use this theme provider at various levels. So you can use this theme provider at in your index.html at the global level and automatically switch teams between dark, light, et cetera based on whatever is stored in the database for user preference. So we'll move on to the next topic. So we looked into theme provider. Next topic would be reusability and extendability. Basically how you can use mixins. There is more advanced topic on extend, but if you wanna see examples of that, if you go into our components folder, we have style components which are using extend. For now we'll quickly see how we can use a mixin and use those CSS variables in two different style components. So for that, we'll still use theme one and theme two. What we can do is create a constant as base button which will take in, we'll have a custom button and we'll create a new button called super button. And now we can read base button props as mixin within our custom button and super button. So for, and for the super button, let's put in border radius. So all the code for this is in stylecom.txt. So you can just go in there and read about it or copy paste if you are stuck in, stuck anywhere. So once that's done, now you can use custom button and super button in your JSX. So as you can see, you have custom style component one, custom style component two. One is a custom, using custom button style component, and the one is using super custom button component which has a border radius added to it. So this is how you can reuse variables. You can define themes. You can have various properties defined and stored in your database and read in the runtime and applied to your CSS. If we had to achieve this in using CSS or even SCSS, then you should have used a lot of lazy loading techniques, et cetera, but now it's total dynamic behavior. If you're done, we'll move on. That's all about style components workshop. If you want to see more complex examples, you can go into the components folder. We have created an input which has a lot of complex style component dynamic passing props and enabling dynamic behavior. So you can look into it. So what's future of style components? Basically, version one had post CSS pipeline which was increasing the build pipeline, CSS pipeline for conversion from style comps to CSS and injected into your HTML document. The bundle size was big, like 21KB. So they switched in version two to stylus. But what they missed is post CSS was creating a AST. So you could tweak into the pipeline of post CSS and you could use it to do your own auto-prefixing, custom auto-prefixes for your CSS, et cetera, and also for left to right transformations. But now that's not possible. So what style components team is coming up with is something called as intro-perable style transfer format. This is the first CSS and JS format that they're coming up with. So you would be able to generate AST abstract syntax trees and customize how style components would work for your own need. One thing that we didn't look into was linting. So now style components team has come up with style lint processor for your style components. So it's production ready linting of your style components similar to how we could lint CSS with saslint and you're using CSS lint for CSS. So we'll quickly summarize. So we went through, we looked into CSS evolution. How, what are style components? What are their advantages, et cetera? We looked into a workshop, a quick workshop on creating style components, passing custom props, themes, reusability and extendability. And we had a short description about where style components is going in the future. Yeah, so that was the first session. It was a warm up session. So next sessions would be even more faster and we will deep dive into optimistic UX next after we have a quick five minute break. Yep, yep. Thank you. So you're ready for the next session? Yeah. Cool. Before we start, we'll have a quick quiz. We have small gift for you, webcam colors. So we'll go ahead with the quiz. I don't think we can wait for the others to come back because we're running out of time. Sorry for that. So it's easy, but you need to read in between lines. So it's gonna cover three concepts. I'll explain to you the concepts later on, but what do you think the answer would be? First was, yeah. Offside. Sorry, that's wrong. Undefined. Yeah, that's right. Undefined is the answer. Reason, yeah. Because people inject the semicolon after the midterm. Yeah, that's right. So a semicolon is injected and that's why this object is neglected and you get undefined. So this just shows that you should be very careful when you're not using semicolons. Yeah, how about this? Yeah. It's a never. No. Just take a guess, guys. I think it's a string. No, sorry for that. Undefined? Undefined? Yeah. Undefined? No. Ha ha ha. Ha ha ha. Ha ha ha. Who is it? I think the red, right? She was a... So you were saying? Number. Number, no. Okay, fine. It's a function. Reason for that. Can anyone explain the reason for that? Oh, hoisting. Yeah, function hoisting. What's happening here is it's written in foo. So the code below is never going to be reached. So foo is equal to 10 is never reached. But however function foo would be hoisted to top of this function, right? So that's why it's a function. Yeah. So now let's get serious. Let's see what this would be. Sorry, I will project it here. Oh, I didn't have the place, huh? Yeah. Yeah. Anyone? Yeah. Let's give other people a try. Ha ha ha. These are core concepts of JavaScript that we are looking into. First one was when you don't use semicolons, I agree. I'm old school, so I still use semicolons. So when you don't use semicolons, where you can go wrong, that was the first question about. Second one was function hoisting. And third one is a little bit more complex on JavaScript. Yes? Okay. E3 and 1. Yeah, perfect. Yeah, it's E3 and 1. So what we're looking at here is closures. So when you're doing foo-bas-bar, go equal to this, and if you're calling go, go is an closure, the global space there. So when you do go off, it's called a frame tree. And when you do foo-bas-bar, the closure would be within bar. But however, the x is read on top of that, so it's x equal to 1, so it's 3 comma 1. Okay? Thank you and we'll continue with our next workshop. Hello, hello. Can you guys hear me? Yep, okay. So we're going to do a chat app and we're going to apply some optimistic UI or updates on the chat app as well. So before I continue, can I have a show of hands who doesn't know what does it mean by optimistic UI? No? Okay. So, optimistic UI, here's the the decryption, but ultimately what it means that when you are sending something to the server and you are sure that maybe 90% it will not return you an error, right? You update the UI first without waiting for the server to get back to you if something pass or fail. So you give a psychological speed to the user that everything is fast. So maybe one example that we can know if you use WhatsApp, right? When you send, the chat come up first without saying that there's a loading or waiting for the server to get back to say have it been successfully delivered. So you will just show and then they go a step further with the ticks to show that if it's delivered or have the user read if you have those option on. So this is what optimistic UI is. And today, so we're going to build a chat app, right? And then we're going to see how can we apply this in our React Redux application. So, sorry. So the first thing is, maybe we can check out the branch. Very simple name. It's called starter. If you can't see, have it here as well. You can get stash and then you will get checkout. Yes, you have to commit or stash. Yeah, your previous branch, right? You either commit or you just stash and then you can check out starter. After that, run npm install just in case there's some dependency that's needed for this exercise as well. So if you're done, you can run npm start and you should see a chat app similar to what you guys would see when you first check out the Chrome repo. And if you guys doesn't have a Redux Dev tool installed on your Chrome, please do install it as well. Thank you. You might need it later if you face any problems when you want to debug issues. So is everyone done? Cool? Okay. So this is what you will see. Like on the left is the application and on the right is a Redux Dev tool. So if you could set up your browser in such a way, it would be good. So if you look at the application, what we can do is we can type in a user name. You can type in anything and you enter, you'll bring it to the chat room. And in the chat room, you can type anything, a chat, ha ha. But this is not connected to any backend yet. So what we're going to do is we already have a UI that has been built up for you guys using stock components. We are going to try and see how are we going to implement this with Socket and REST API. So we're using a mixture of Socket and REST to build this application. So before I continue, just to let you guys know that most of it, the code are already in the code base. We have some code commented out. So we will comment them one by one. Within Bean is the shortage of time. And we want to go through and make sure you guys understand some concepts like what we are doing in this project and what are the some practices that we find that is good and we are practicing and using it in our project as well. So before we continue, maybe we can just look in the folder structure and I'll explain certain things. So you can see that we have like, these look like a typical React application, right? Those have done React, Redux. We have similar folder structure. Things that I want to highlight is we have component and route. So components like what Guru went through is a style component components, right? So if you look what we are doing here, you'll notice that all these components, they are named very similar to your native API. So that's one thing to take note when you're building components, right? You try to have it at close to the HTML or CSS API. So for example, if you're building a flex component, just name it flex, right? For props that you can pass in into your components, you can name anything for your props, right? But here, you can see that we are using things like hide, justify content, align item, flex direction. All these are very familiar. These are from your CSS, right? You write your CSS in a tertiary way. So the advantage of this is any developer that come to your project, right? It's very familiar to them, right? They don't have to learn new APIs or how you are building a component. So this is one thing to take note when you're building your component. So in such a way, it will help people to understand and get up to speed. So these are all the components that we have built. You can take a look at them if you want to. And these are enough for you to build the chat app. And we have the routes. In our case, routes are like the pager. So we have the login page, the chat page. So you can see that there are two folders here. You log in at the chat, right? So these are just your routes. Next thing they want to go through is the actions, right? We have actions. So you can see we have a bunch of quotes commented out. So these are things that we're gonna uncomment them one by one. And we slowly will go through how this will link up our application together. So in our actions, you realize that we are not doing it in the normal way that React or Redux is doing. So what we are doing here is you're using this library called Redux X. Okay, if, who haven't heard, who have used Redux X before? No one? Okay, then I will explain what is this and why we are using it, right? So when you create a action in your React application, most of the time you'll create a constant that goes with your action type, right? Because you want to prevent bearing errors and things like that. But if you notice here, we didn't need to create any constant for our action type. So what Redux X is doing is you just create, just put a string here, which is your action type actually. And what they are doing in the back is they are helping you to enforce that your actions are unique as well. So they have like some kind of ID that's pre-panded before your action type. So if you were to see, okay, so you can see here the type, right? It's what we write as it is. But if you don't put a type, right? It would be an ID. So they're helping you to make sure that this is unique all the time, right? So what they are doing, if you look in our reducer, right, the way, so the way we are using our reducer, we are just importing the action variable that we created. So they are doing some, what is happening is they are overriding the to string method. So when you have an object, this is an object, and you have a computed key, right? What's happening is JavaScript will call the to string method. So this is how they are handling the type for catching the action. So this one thing is actually quite interesting. You guys can take a look because it reduces the boilerplate of writing your constant because every action you have all the time you have a constant, right? So you cut down a lot of boilerplate and it makes your code easier to read as well. One other thing that I want to highlight is the way we are writing our code in the reducer. We have this pipe, right? Think of pipe as a series of functions that we are piping through. It's just like your normal pipe in your Linux and everything. You're piping through an input through the various function, right? So now what we are doing is we are actually piping the state through this various function. So you can see over here, let's just say we have the action then chat message. What we are doing is we are actually having this function that taking a payload and a state as well. Later I'll show you how where the state comes in, right? So it's taking a state and returning a new state to the next function. So you're returning the next state to the next function and then ultimately when this finish, it will return the state to the reducer, okay? And then that's where the reducer will get the new state and then the whole app, React application will be rendered. So the concept of this, right? We have what we call these are mutated, right? We call these mutated because they mutate only one part of the state that constants them, right? So for example, if you were to look at our mutators, right? You can see what we are doing here is, let's say set input, I just want to care about this path, input the name and the value and I want to set the value to this path. So we are using immutable.js here. So you can see it's a bit weird. We do not have like object.assign and then we create a new object. So we're using immutable.js to help us to ensure the immutability of our state as well. One other reason why we use this is because it helps you to maintain a very clean reducer. Imagine if you have a very deep state, what you have is you have reducer composing reducer and reading reducer and when you want to traverse through your code, you need to go through this reducer and you say, oh, this is actually handed by another reducer. You go into that reducer and you realize that there's another reducer composing. So it will be very deep and very hard to traverse through the code. So which is why when if you use this because you can just put the path and you will just go to that value. So if it's hard to understand, just take it as if it's an object, you'll be object.input.name.value. So this is what we are doing and because the way we are doing it, we ensure that the mutators only handle one thing and one thing only. So it's very small, right? Which makes it very easy to test as well. So when you have a very big application, you can have all this, it's very easy to test and you can reuse them, right? Because you have, you probably have a bunch of inputs, right? You can have inputs and you have the dynamic path here because of the name of the input, right? So that is why we are using immutable jazz in this application as well. So that is just a short when walkthrough of the code and why we are using certain things. Any questions at this moment like anything is unsure or anyone is lost? Everybody okay? Okay. So we are going to start to try and build this chat application. Before I go on, just to let you guys know that this is how we are breaking down the React application. So all the different colors, actually the different components that we have taken out as a component by itself. So this is just a feature for you guys to see, just in case if you need it. So what are we going to do? So we're going to work on the logic only today. So we have the actions, the mutators, the reducers and lastly the middleware. So we're going to use the middleware to do the socket connection and the rest API call. Show of hand, anyone have, those who have done React with us, anyone have wrote their own middleware before? Anybody heard about middleware? Anybody know what middleware is? Okay, a few hands. Okay. So the rest, I assume you don't know what the middleware is. I will go through how the middleware is like but before that, here are the few events that we're going to send. So we have combination of socket and the rest. So for socket, we have this event at user and for the rest, we have this API endpoint not to worry these are actually in the code just giving you guys a visual and these are the socket events that we're going to listen to, login success, login fail. So we are going to implement this login part. So what we have to do is actually we need to key in a username. We send to the server. The server will tell us if this user exists. If it doesn't exist, login success. So we give in a login success event. If it fails, there will be a login fail because a user have already existed. So these are what we're going to build. So before we go on just talking about middleware. So this is the flow of our application, right? A normal React Redux application. You have a store, right? Normally, yeah, the view will listen to the store. You have any action, right? Normally the action goes straight to the reducer, right? But in this case, we have the middleware which will handle our socket or rest API, okay? Reason being why we want it to be the middleware because like if we want to do anything that is related to in your normal React and Redux application, normally we have action to describe something that has happened, right? Or something that you want to change. So you want to maintain the same way where you want to execute your socket middleware and rest as well. So that's why we are using a middleware because we want to use actions for any changes that we want to make to the application. So middleware, just think it of the actions. We will just pass through your middleware. You can have a few middlewares. So we will go through a series of middlewares actually if you have more than one. Middleware will intercept your actions, those actions that they need to intercept. And what will happen is it can do many things. It can either stop the action from going to the reducer or it can even dispatch new action as well. So which is why you can see sometimes middlewares you can dispatch new action and you'll go through again. So this is the concept of middleware and this is the core part that we're going to build today for this whole application, right? So without further ado, let's go to the code and let's go to our actions, right? So the first thing to do that we know that we want to add a user, right? Over here, we need to add a user to the socket. So we know that we need, like I said before, we need the action. So if you go to the action on line five, just uncomment line five the code, right? I have the add user to chat, right? And we are creating an action here and we know that these actions need to be handled, need to be intercepted by the middleware and we need a socket configuration as well, right? Because you need to tell them, okay, these actions, what are the events I'm going to emit? So here, can we open socket config.js? Okay, so you can see that in this, I have a function called socket setup socket, right? And in setup socket, I have two other functions that is being written by this setup socket function, right? We have a listener and a emitter. So if you're using a socket, right? You have a socket that actually wash on the event. So in this case, the first one you can see, we are actually watching on the socket logging success, right? So this is where in this function, we are putting all our socket events that we are listening to. So that's why it is in the function called listener. And then we have another one, right? Which is called the emitter. This is where we have, look at this, it's a very similar API in our reducer, right? Because we're using the Redux Act and we're looking on the action. So this action, right? When it intercept this action, I want the socket to emit at user event and then the payload username. So your actions will actually pass the username, right? So our action actually will pass the username and then this will pass to the socket backend. So the thing is, in order for this to happen, we need the socket object, which will be passed in from this setup socket, right? So now let's just try. We have two events here, one that we're emitting at user and if it's successful, you should receive login success, okay? And let's just also uncomment this on line seven, right? This is login fail. So if it's login fail, so you see you can see that here we are dispatching another action, right? So if you look over here, when we have the action, right? We come to the middleware. What happened is, if we emit at user, you go to the socket, login fail success, you come back to the middleware and you'll dispatch another action back, right? Because here we are dispatching action to change our state, okay? So when, okay, so if once we have uncommented that, we have the configuration for these two events, three events. So now the thing is we need to pass in the socket event, right? So where we are initializing the socket is in store.js. So if you can go to store.js, you can help us just see. We can from line nine or 13, sorry, line 13 all the way down, we can uncomment and we can remove line nine, sorry. Yeah, this, like this. So remove, okay, never mind. Okay, so you can see what I'm trying to show you here is we have this setup socket, right? We are importing it here, setup socket. And here is where we implement our socket connection. So we have a socket object and when we call, right, this setup socket, the socket object is being passed to this function here. So this function, which is the same function as this is having access to this socket connection, okay? So this is how you pass your socket object into this function so that they have access to the or have the scope to this socket object. So this is how we can pass it in. And then you notice that there's a socket middleware here. So what is this? This is where we have the middleware, which is part of Redux, right? That will handle all this, they will pass in things that you need. Like for example, you see you have get state, get stage and dispatch, right? So where does this come from? This actually come from the middleware stuff. So when you use the middleware in Redux, they are actually passing you a few other items, get state, dispatch and the action actually, right? So if you can see here, it's actually like that. If let's look at the socket middleware, right? So, right, it's in this, it's in the middleware folder and there's a file called socket.js. So if you look at this, example middleware, right? This is a signature of a middleware. So if you want to create a middleware, this is the signature you have to follow. So it's actually a carrying of three functions, right? You see that there's a store, there's a next and there's action, right? In next, it's actually calling your next middleware. So if you have a middleware in front of example middleware, like middleware one, middleware two, in middleware one, next will be calling middleware two, right? And in middleware two, your next actually calling the dispatch function, right? So your last middleware, next will be the dispatch function, else the first few middleware will always be calling, next will always be calling the next middleware, right? So this is the signature of a middleware. So if you want to build a middleware, just take note of the signature like this. So you see here when if I call next and I'm passing the action. So when you call next, you have to pass in the action because you are saying that, okay, I want this action, right? From here to go to the middleware to the next one, right? So if you don't want the action to go through, means you want to intercept the action, I say, and maybe I don't want to do anything, you don't pass, you don't, you don't call next. And that's how you can, in the sense, silence some action. But that might not be always the case that you want. So just depend on what are your use case and you just do it like this. So let's look at our socket middleware. Okay, it might be a bit hard to see, but what I'm trying to show you is that, remember we passed in our socket object, right? Okay, this is the socket middleware. I think, all right. So here on the right side, you can see that at the end, I'm returning the listener and emitter, these two functions, right? And if you look over here in the socket middleware, you can see that it actually comes through here, the listener and the emitter. So this is how your socket middleware get access to these two functions, which you have just created, right? And you can see the listener, so it's actually, so the middleware is actually three function call, right? It's carrying of three function. When you apply the middleware, it will actually activate the first function, which is calling this part. So they will actually pass, read up, we'll actually pass the store and call this. And that's why I have the listener. So that means upon applying the middleware, I'm already listening to the event from the socket, right? But it's a bit different for the emitter. So you can see the emitter is here because emitter is waiting for an action, right? You say, I want to emit something. I want to emit something to the pocket. You use the action to describe that change. So which is why it's over here and waiting for the actions to be passing. So when you dispatch an action over here, you go to the middleware, and this is where we intercept it and then we're putting the action, right? So if you look back again in the socket configuration, right? You can see that here, we are actually looking to add user to chat, right? So if the action come here, it will go this and then it will emit, right? Everybody's following so far, right? So if you have uncommented all this and you should have the socket uncommented as well, let's just see. This should work if we go to the application. Oh, sorry guys. We don't have the rest middleware yet. So can you just remove it from the middleware? So just have only this set up socket. And yeah. So if we were to try, let me just see. We need to go to the component, the login component. There's this code, the forms are made, you need to switch it because previously it was just, we are just doing a history push. So we're just only changing the route. But you can see here, uncommented off, we move the top one. So now this is actually dispatching the add user to chat. So we're actually dispatching the username over here, which we actually store in the state when they type. Right, so on every input, we are actually storing every single input in the Redux store. Yeah, so just remove it and we should be good to go. We go to the chat application. The function. Is anybody able to log in? No, right? Okay, give me a moment. What? You can? Oh, this weird. Okay, silly mistake. This action, if you haven't uncommented, please uncommented. All right, save username. You can see that over here, we have add the user and save username is actually dispatched by my middleware, right? In the socket configuration, right? See, here we are dispatching save username. So this is how you can implement the socket into this middleware. So everybody, you can see the, can everybody log in? Anybody can't log in? So if you can log in, the rest is pretty much the same, right? Because the rest of our actions over here, right? These are all pointing to all our socket actions. So just uncomment all this, right? And we can go to the action, the socket configuration as well. Uncomment all this, right? So two places, uncomment the code in, all the code in socket.config and your actions.js. So you can see that all of this here are listening to the different events and then dispatching the respective actions to your store. And then they will update the Redux store and your application will revender. Then later we can see how we can have the whole chat application. One more thing, this is for the socket events. We haven't done it for the rest API, right? So because the way we send our message, we're sending through rest. While the rest of the events, we are listening to the socket event. So if you have done this, we have in middleware folder, there is none of file called rest.js. Just uncomment the code in there. So this is a very simple fetch, right? We are just doing a post on this URL where we post the message that we're going to send later in the chat room, right? So this is also middleware if you take a look at it, right? We have the same signature, the dispatch, right? The next and the action. So you can see that the only difference is that I'm putting the configuration in this middleware. But normally you'll shift it out to somewhere if you have a series of API calls to make. But for simplicity, I'm just going to put it here. Okay? So once you have uncommented this code in rest.js, the next thing you need to do is to, you need to include it in the list of middleware that you have, right? In store.js. So if you go to store.js, remember the one that we removed just now, right? There's a set up socket, and then there's a rest middleware. So just uncomment at the rest middleware here. So if this is done, if you try to log into the chat room, right? And you type something or someone type something we should all be able to see it because this is all connected to our socket back-end server. So those who manage to finish it. Yeah, you need to uncomment the code in your reducer as well. Because the reducer have to change, watch the action and change the state, right? So you need to uncomment your reducers. All the actions in the reducer. Empty user name is the mutator. What? If you go to the mutator. Oh yeah, yeah, yeah. You have to uncomment. Yeah, yeah. And someone else who is sending an empty user name does the work. So we need to add something value, value.username, because sometimes it's an empty shell. Oh, okay, okay. Okay, okay, I get it. Can anybody say, oh yeah. Yep, so you should be able to see something like this where you can see a range of people joining the chat and leaving the chat. Whoever types, we should be able to see as well. Right? Usually, it's fine, right? He has a really short knowledge for the people. Maybe you can just say in case they have an error, we should use the name too low case in the mutator. Then to other checking before there is too low case. Yeah, it's an empty. Then what do we see from the server is empty. Oh, just ask them not to type empty here. Because just demo. Yeah, we did the last question. Yeah, yeah. Guys, don't type in empty username, okay? Just type in, if you have already typed in empty username, you can leave the chat, come in, go back, right? Then you type in something, right? Because we didn't check for empty shrinks in this case. Okay, so this is the chat app that we have just built. But how does it link to optimistic UI, right? So if you can see, if I have an error message, right? I type this is an error, right? So we will look up for the error name in the server. So, okay, this, let me just check for, okay? Someone has a too low case, right? Too low case. Too low case. There's a code here, something about too low case. Yeah. Right? So somebody is giving without any username. Yeah, yeah, yeah, yeah. So you can add some condition. Yeah. Some people are running into the error. So you can tell them that, don't check for if there is a username, then you can use too low case. Yeah, yeah. I already told them, don't put empty username. Because they already joined. Yeah, they can leave and join again. Yeah. They leave that it will be gone, right? What? Oh, they have the error? I mean, you just have to tell everyone to go under there. Only they have the error. We will check if value dot username is set. So just value dot. Okay, for those of you who have username error, right? You just add this in your mutators. The append order message, right, itself. Check if username is coming, right? If it's not coming, then it's not. We will not run this condition. Okay, now switch to the final branch. Yeah, yeah. So you can find the presentation. Just the error is not working, I don't know why. Okay, so we have, those who are not able to complete all, don't worry, we have a disk branch. No, sir. So, socket, can you just check out to this? Socket client done, right? Socket dash client done. Right, you have the full working application. So just check out to that. Then we will talk a bit on the optimistic UI before we end. Don't forget to git stash before. Please do a git stash and then you can check out socket client done. Git check out, socket client done. Yeah, git check out. You need to unit it. No, no, no. Right, yeah, git. Once you have checked out first. So, once you have checked out, you should have something similar, right? And I was saying that, right, if there's an error message, right, you can see that this turned red, right? It was green before, and now it turned red. So, this is actually a simulation of in any case if the message didn't get through, right? The server will tell our application that it didn't get through. And what we have to do is we just need to take different action because in your different application, you have different way of handling error messages that if it doesn't go through, let's say in this case, the check message, right? Sometimes you can ask them to, from them to we send or you could have a logic to say, okay, if this fails, I will try to send it again, right? And maybe for three times before it really time out and then I will show the error message to the user. So, where are we implementing this? If you look in our red client, right? You can see on this line, right? It's actually just very simple, right? We're just looking for some error message. If there's an error message, we dispatch an action, right? That describe, that change the state on, to show the error message, right? So, it's just a very simple idea, right? Don't need to have any complex framework or what to help you handle. I know there are some that, there are some optimistic UI framework or middleware as well to help you handle this, but it can just be as simple as dispatching an action to correct certain things. So, in this case where we have, we are just correcting, changing it to rate and then sending the resend button. So, if the user have to, they can click the resend and resend the message again. So, there's many different way you can use to handle your optimistic UI, right? So, just to close in summary, like one of the things that we have went through in this thing is that we use the API as close as possible to the native standard. So, like the HTML, CSS, which I mentioned in the components that you have, right? For any changes you need in the application, always use reduct action. So, for anything that you have, it always standard dispatch reduction. So, it's very easy. Change something, dispatch action. Change that, dispatch action, right? And of course, if you need to have any asynchronous or start effects, you will use the middleware. So, that is all. Thank you. Alex. So, we hope you had a good time looking into optimistic UI, which I have. Before we go into the next workshop on React performance, let's have a quick quiz on React. So, this time, you won't be questions. You will be having quiz in the code. Okay? So, all that you need to do is please check out, stop your server first, first call, because you need to do end payment store and then do end payment start. So, stop your server, hit stash, stop your server, do a git checkout quiz. Please don't log in. Once git checkout quiz is done, please do a end payment stall. Once you run end payment stall, you can start. Please don't log in into your chat app yet, because we get to know when you join and when you leave, so. Mind the clock. Yeah, he's been on the clock. He's been on the clock. Are you done? Everyone? Okay, now you can log in with your first name. Please give your first name there, because we need to get to know who was logged in. So, log in with your first name. Now, you can, there's a quiz button there. Please click on that quiz button and please take this quiz as soon as possible. And who gets all the answers right? And it's also based on time. We'll get, we'll be the winner. Yeah? Explain more in the concert. You can do that, then we'll explain. People are still trying to make it work, so you need to always do something. So, Ben has got a score of five. So, he's not the first one, sir, he's the first one, sir. Everything right, right? Mixed in seven. That's really cool. When I took the test, I thought who puts in like, submit scores, wins. So, I just got three. That's good. So, it just goes out way better. Three, three more minutes. So, Ramas goes seven. Alexis five, Emil six. Ricardo seven again. Oh, love. Who's love? Come on, anyone above seven. Eight. Eight, wow. That's cool. How many of you are done? How many of you are still taking the quiz? Okay, okay. Oh, another eight there. Last chance, last chance. Yeah, 30 seconds more. Because if you're googling. Yes, please check, nobody's googling, huh? He live, or live, huh? Ah, that's right. All right. Yeah. Oh, this is difficult. So, everyone is done, right? Yeah. Okay, so let's see who is the winner. So, it's gonna be eight. Yes. Who is the first eight? Joy, Joy. Sorry, sorry. Oh, wow, yeah. Well, you get two. You get two gifts today. Congratulations. Congrats. Thank you. Clap for the winner. Next, Alex, our tech leader, Paulo, I think we'll continue with the next workshop. It will be on React Performance. Set up, okay. Okay, everyone. So this is the last session. I think we are a little short on time. So I will try to go a little faster, okay? But don't worry here, the purpose of this workshop, exercising is good. But what we want to show you is some tooling that will help you to do some performance checkup and also some libraries that can be helpful if you want to optimize the way you code for taking in consideration performance, okay? Okay, it's going, cool. Thanks. So who has been working or has already tried to improve the performance of your React application? Is there anyone? No? Okay, so then maybe this one will be interesting. So during this session, as I told you, the purpose is to show you some tools, to show you some libraries, and also to try for you to understand what's behind how does the React component work, who did their render, to know how to optimize it, okay? So first you can commit and stash your previous work and check out the React Performance Workshop branch. There's two branches, React Performance Workshop and the React Performance solution, okay? So if you want to go directly to the solution, that's fine also. If you want to try to do it, you can also, but I will go a little faster. Then don't forget to NPM install and NPM start. Okay, if you NPM start, you will see again the chat. Please enter your name, okay, so that we don't have the same bug as previously. Don't forget to enter your name before entering the chat. Also, if you can, if you are ready, you need Chrome. And for those who didn't have, can you try to install the React Developer Tools? So you can search on Google, React Developer Tools. So this one. So previously John asked you to install the Redux Tools. Now we need another one, it's the React Developer Tools. Okay? Okay, everyone is set. Is there somebody not set yet? Okay, so then let's start it. So once you connect to the application, so you can just connect to the chat room, you will see in this chat room, what I did is I initialized a lot of messages, okay, repetitive message, just for the purpose of this demonstration. Also, I added here another component, which is a mention. It can't, how many times people have been writing JNsConf or PaloIT in their message, right? If I add PaloIT and JSConf again, the mention is increasing, okay? So nothing exceptional here, it seems to be working fine, right? Before starting the, looking at the tools, there's just one thing I will go very fast. For those who are using React already know, for those who are learning it, just know about this, that there's two way of building your app. One is a development build, and one is a production build. Right, the difference is that when you do production build, he will remove a lot of warning that you can see in the console log, so it will make your app much smaller, okay? So don't forget to do that. What you need is to add a nod-off in your application when you build it. So an example for Webpack, if you're using Webpack as we did, you can see in our Webpack that we have in the Webpack two Webpack files, one for development and one for production. If I make a search on the development, I will not find production. If I make the search on production, oops, sorry. Then you can see here, we are setting up the nod-off to production, okay? The other thing for optimization that is common is don't forget to ugly-fi or minify for your production record also. So the same on my production, here on my production Webpack, there's a plugin for ugly-fying that we set it here. On development, we don't need to do that because we want to have the whole code loaded in our browser. So we are not doing ugly-fying, okay? So how to check if the current app you are running is in production or in development mode. You can use the React Developer Tools. If you look at the, once you install it, you can see here there's two colors. If it's red, it means you are in development mode. If I click, it tells you you are in development mode. If you build it in production mode, production build, you will have a dark icon, okay? So this one is just a quick checkup on this build. This is the basic stuff, but if you never do React, just know about this, okay? This will improve the performance already of your production. Then let's try to go deeper. There's another tool, okay? Here, in your app, it seems to be fine, right? I tap is very fast and it show very fast here. But let's say your app is working very fine and now some people are deploying your app in the mobile app. Maybe the mobile app is not as strong as your computer and they will start to have some latency. The Chrome give us a tools. If you open, you develop and inspect the tools in the Chrome. You will see here there's a tabulation performance, okay? In performance, you have on the right here, setting. You can simulate a fraud link. So I can voluntarily tell Chrome, can you be four times slower than usual, okay? Everyone has that, okay? So I can, I repeat. Open your inspect tool in your Chrome browser. Go to the performance. Performance on the right, there's a small setting icon. If you open it, you have a CPU. Normally you are not fraud link, it's working as normal, but you can simulate a fraud link, okay? Everyone is set up. Once you do that, I go to the chat again. Now I start to type and start to be a little slow. I feel some latency. When I enter, you see there's a one second latency. It's a little slower than when I was not typing, when I was not the fraud link, okay? So then we are going to start to use a tool to find out if you can find out how to improve this latency, okay? So there's a tool in the same tab that we are able to show this graph. So this graph is called a Flam graph, okay? You can see that it shows when you are running the app how long each component is taking and which component is calling which component to be built in the React application. So to do that, you have on the left here, a small record button, okay? So when I click it, it will start recording my action. So just for this demo, please stop entering anything in the chat so that I will be able to record first and after I let you record. So I do a record, the proffer is initializing. I type one character is a little slow. I tap enter and I can stop the record. Don't record more than 20 seconds because if you record more than that, your browser may hang, okay? Because there will be too much data for the CPU to process. Okay, so I give you one minute each, five minutes to try to do your own recording. Make a simple record. Don't try to make something complex. One character and one enter. Then you can stop the profiling, right? Just try to do like Joey, one character. It will be easier for you to analyze the profiling. Okay, so a few people have done it. We can see in the chat, right? If you cannot find, don't forget the button is here. On the left, record, all right? So I will continue, okay? Don't worry if you didn't have time to do the recording. What's important is here to show what exactly you can do with this recording, okay? After you can try to play with your own recording if you want. So here you see, there's this bottom part which appear after I finish the recording. So it's a little hard to read because everything is a little stuck. So I'm going here on the right, the three dots to dock side the full screen, okay? Now I have everything. I have the same, my console log now appear as a full screen so that I can see more information. So what we see here, the first bar chart here, let me remove this. You can see when I go along the way, it's showing me the screen. How is it going? So we can see clearly that there was nothing at the beginning, right? The message is empty. So the message is empty, okay? Along here, something is happening. We enter the character A, nothing is happening. And then something again is happening. And at the end, we can see that the message has been entered in the chart, okay? How to read this chart? So the first information here, you can see is the CPU usage. And the color here is describing is how the CPU is being used. And you can see that most of the time here, the CPU usage is on scripting. Rendering and painting is when he tried to change the HTML in the browser, okay? So this is the two part that will interest us to try to find out what's how to improve the performance. So if you go a little below, so frame here I can see how long if I select this part here, I can select. Now we tell me when part how long it took to do this action, here interaction, you can see that there's a key character and the key up, which is when I type, when I enter the A character. And we can see in user timing here, this is why it's interesting, starting to be interesting. We can see the different react component of our app that when I enter A, he render, again he executes on rendering for each of the component, the chart. We can see the container, the chart container, and so on. So there's more information below here, okay? We are going to analyze that a little later. Another thing interesting here, if I go from here to here, I can see a small difference, right? Here when I enter the character, it's immediately starting to render the component. When here, when I start to enter the input enter, there was some latency here. He didn't start to render the component. So this is why maybe we can think of something is happening. Why is it so slow to start running a component? I just click enter, right? So how to try to find something? There's another thing here in the main, which is also some event app happening, the start of the event and the end of the event until what's happening under this event, the child call. If I click on it, and I go here to bottom up, I will see different function that has been called. You have two things interesting. One is bottom up, one is call tree. So the call tree show you, after I click this one, the different event call, the child of the event call. So sometimes it's not easy to read because there's a lot of stuff is coming from React, it's coming from Anenumis call and so on, okay? So you won't always find something, but it's still interesting to have a look first just in case. The bottom up will regroup together for the same function. If it had been called many times, it will put together the time that has been spent on a specific function. And here I can see clearly, I have a function here called update mention message. The aggregation of call took 68 millisecond, okay? Out of the 360 millisecond. But if you look in term of aggregation, he was the one taking the most time compared to all the other small function call. And here on the right, you can see mutator.js. So this one is possible. The Chrome can make the link to your code because on development mode, there's a source called, what's it called, a source mapping. So the source mapping is built when you are building your React code. The source mapping allow the force when we're debugging, when I click here, he will be able to go to the code. Okay? So how did I go here just to come back? I click here on the event press. If you cannot click, sometimes it's a little bug on the Chrome, do a right click, it just appear this, and then you should be able to click it. Okay? Everyone has this? So I go back again to update, I go back here to the bottom up. I can see update mention message is taking a long time when we aggregate the time span. And if I go to the code itself, I can see, okay, here are very something very easy. I have a writing, we are doing a loop for nothing. Okay? This is what make our app a little slow, a little slower. So now just to show you that we can improve it. So then I managed to find a specific piece of code that should not be there. So I'm going to remove it. So you can find it inside the mutator. Okay? Everyone can go to the mutator. And the piece of code is here. Right? We have the line. Mutator.js line 28. So I can see here, mutator.js line 15. Maybe there's some compilation. I think yes. Okay, there was some compilation from Webpack. So there's a difference offline. I forgot this one. But that's fine. That's easy to find because anyway, we have the name of the function and we didn't aglify or minify. Okay? So now I'm just going to comment this code. The code is going to be recompiled. Okay? And I'm going to initialize it just to make sure I start from scratch. I log in again. And I'm going to do another recording. So here is a still a little slower because I'm still throttling. Okay? If you want to stop throttling, you can change back the sitting here. So I'm going to keep the throttling just to compare. So just let's have a comparison here to see that the time taken is one second. And the time, and to remember here, we have a small gap of a few 300 milliseconds about 300 milliseconds. So I record again. So the compiler is initializing. Okay? I do the same. The same action. A, enter. I stop the profiling. And now if I come back here, the second part. Oh, I think someone, yeah, someone joined the chat. So let me redo it again, okay? So just for the sake of the exercise, just hold a little on your chat. So I do it again. I enter A and I stop the profiling. Now we can see the second part here. Once I enter the key, there's no more this latency, okay? If I click on the event key press, we can see that the update mention message is no longer the aggregated time that takes the most time during the initialization. Okay? So this one, it was very easy to find because I even voluntarily put inside the function. So but don't forget that if you have a lot of callback function and only cause, it won't be that easy to find. But it's still a first indication that can be useful to try to find something happening. Maybe if you have a service file or this kind of stuff, you will find out something is happening in your service file, okay? So the next tool I want to show you, before going to the next tool, let's try to analyze a little more, okay? Because I'm still struggling. And you can see when I enter a character, it's still very slow, right? Maybe that's something we can do about this. So let's go to the part where I enter the character. It was this part here. Now if you look at again at this part here, we can see this flame graph. When you see this kind of stuff behind the flame graph, is that maybe something wrong is happening? Because you don't want to have a flame graph that has a lot of pit, a lot of spike like this. If you look at it, we can see clearly what is happening in the React when I type enter. He render again the chat. Here is our different style div component being re-render. He render the chat container. And inside the chat container, we can see all this chat bubble. All this chat bubble here, you see? All of them are being rendered, which means there's something wrong in our logic is every time I type, he's rendering this whole stuff here. But we don't need to render it, right? Because I'm just changing the input here. So this is a waste of time. Another tool that will help you to find this easily, if you go now to the React. So this is the next slide. If you go to the React, the React tool you have this highlight update. So before I activate it, I know I will remove the throat link because I don't need it anymore. So I activate here the highlight. Let me put this back on the bottom of my application. And what's the difference now is every time I type, he highlight me the change of your component. The change, what this highlight means, it means he has been launching a rendering of the component. The color that you see here, blue, green, sometimes it will become yellow or red. It's how often this component is being re-rendered. So if you see something that is red, maybe it's normal. If you are doing scrolling or this kind of stuff, maybe you wonder why is it rendering so many times. So maybe something is happening. And here we can see clearly every time I type, he's running the whole application. So this is something that we can try to do about it. But to do something about it, we need to understand exactly how the React is working. Okay? So if I just go back to this chart here. In fact, when you see here, when I click this for a tree, or when I was clicking outside, we can remember most of the time during this React component re-rendering, we can see that most of the time is spent on JavaScript, on scripting, not on changing the browser UI, the HTML and the interface, the CSS. Because the part that is rendering and painting, almost nothing. So what is taking that much time? Who knows what is taking that much time? No? Okay. So in React, I don't know if you already heard about this. There are each component of React is building a virtual DOM. Meaning that each component, before going to the DOM of the browser, will keep a virtual DOM, his own abstract DOM. Okay? And every time we render, he will execute the code to render the DOM. Okay? The render of the DOM is on a component, if I go to chat, is when I do this render. This is what will be changed as a React element that will be the abstract, representing the abstract DOM. Once he has his abstract DOM, what he's going to do, he's going to compare with the real DOM, and he's going to replace it if the real DOM is different. Okay? But what takes time here? So what we see, this scripting here, is not the fact that I'm doing a call to the socket, that I'm doing a dispatch, that I'm doing some mutation. What takes time is the building of this virtual DOM. So this is what we want to avoid, because here we can see, we are building hundreds of chat bubble, each of this is a component, and we are rebuilding it 100 times. And we can see the cumulation make the rendering much more slow, the major rendering of the whole app slower before we get this character being displayed, okay? So this is what we try to do. So how does it, how do you do that? So in fact, there's another tools that React provide for each component. We have a function called shul component update. So shul component update is part of the lifecycle of a component, okay? So each component before rendering will execute some lifecycle function. One of them is shul component update. One of them is component demand, component update, this kind of stuff, okay? But the one we're interested in is this one. Because you can see in this, so in this tree, each node is a React component, okay? So let's say for example, our node C1 is our chat. Then our node C3 maybe is the chat container. And the node C6, C7 or C8 is will be all our chat bubble, okay? So when it's red, it means that he has been changing the DOM in the HTML. When it's green, it means he didn't change the DOM in the HTML, okay? But to do this decision of changing the DOM or not in the HTML, he will execute two functionality. One is the shul component update. By default, it's always returning true. So for all the component, we'll always say, yes, I want you to update it when something changed in the tree of the component. And then the second function that he'll execute is what we just say. He's going to build a virtual DOM and then make a comparison. Is the virtual DOM different or not, okay? So if you look at this tree, what happened in our chat app is C1, when I enter something, the state is changing. And the view dispatch the store changes the state and it will be connected to our chat apps component that will start the rendering. So he will say, true component update is true by default. And then he will compare the virtual DOM if it has changed or not. If there's a change, yes, he will change it. For each of this chart, he will do the same. The chat container will compare it. And the true component by default is true and the virtual DOM comparison will say, also there's some difference because the input is different. So he will render it. Now, in fact, he will not render it because I'm on the chat container. So he will say all the message is the same. So I don't need to render it but he still executed the virtual DOM equivalent, okay? And for each of them, he will also execute the, since the true component update has been under, he will execute also for each of the bubble here. What we want to do is to avoid this rendering. So we want to play with the true component update to come from this node C3 to the node C2 for the part of the chat container, okay? So how to do that? If you go back to the code, so here you have the chat, right? Which is below in your root, chat.js. This chat reminder is the whole chat here, right? The schema that John showed you at the beginning, it was the whole component. Inside the chat, you can see I have a chat container, okay? This chat container is here. If I open the index file, I can see my component here, okay? And to be able to create this function true component update, you have to make a class component as a class, okay? So here is already the case and I put here, I put you here the function, you can just uncomment it. So what happened as I told you? This function exists, but by default is doing that. He's always returning true. So every time we want to render, we just say yes, you try to render it. So what we want to do now is to stop to render in case the chat list didn't change. How do we do that? This function take as the first parameter the next prop, okay? If you are working in the state, it will also take as the second parameter the next state, okay? In our case, we don't care about the state, we're working out with the props, okay? And what I do is I look if my current props, the chat props, which is our list of message, is different from the next one. If it's different from the next one, then it means yes, I need to render it. But if it's not different, then no, I don't want to render it, okay? So let's see this in action. No, my chat app should have been rebuilt. Okay, I will connect again. I open again the inspector, okay? Let me put it back at the bottom. So I highlight again the updates. And now, I click, you can see here. This is not, each bubble is not from there anymore. If I do now the profiling, so I put it back, I do the same configuration, oops, sorry, with the throttling for X. I do another recording, okay? So just to be in the same situation is empty. I do a recording, enter one character, I enter, oh, in fact, I don't care about the enter, so I do another recording. Because what we want now, what we optimize, it was the fact that when I input a character, all the bubbles should not be updating. So let's do it again. I enter the character multiple time, okay? So I have my profiling, wait. Okay, let me do it again because people are entering the chat. One second, okay? Just don't enter the chat for one second. So I do a, a, a, and let's see this in full screen. Now you can see here, there's a big difference, right? If I look at this part here, before it was taking a few hundred, oh, is it this part? Yeah, now it's very small because there's not much, no, it's here. So we can see, before it was taking like one second, now it's taking only 50 seconds. And you can see also, if I zoom again a little more, the graph is much more nicer. No more all this chat bubble rendering. He just executed the tree, when he arrived to the container, he doesn't render the, the chat container, okay? He just rendered the message input at the end, which is where we enter the A, okay? So this is possible because we are comparing here the chats, which means we are, what we do here is, be careful, is a shallow comparison. It means we are not comparing the content of the chat, we are comparing the reference of the chat, okay? Which is where immutability is very important because if you chat, the content didn't change, you want to send back the same, the same object, the same reference. But if you chat change, you want to send a new reference. So that's why you make it immutable, so that is a new object that is created with a new list. Because we are not going to compare the list, we are just going to compare the reference. Is that clear? Okay, so I repeat. Immutability means every time you, you change something in the object, you are not modifying the object itself. You are creating a new object and changing, copy everything in the new object and changing something inside this new object, which means you will have two different reference. And this is what is being compared here, the reference, not the content, which is very important to understand why is it working. Okay? Because if you have to compare everything inside, it will be much more complex and also it will take much more time. So maybe we are going to lose time instead of getting time. Okay? That said, this is something very common, right? But it will be a little annoying if I have a mini props and I have to compare all of them one by one. So what React has done, he has provided you another component called pure component. Okay? So this pure component, you can import it directly from the React. So instead of doing extending a component, I will extend the pure component. Okay? So, okay, I'm going to go a little faster because we have only 20 minutes left and the other thing I would like to show you, okay? So if I replace here pure component, now I don't need anymore this should update component because he will do exactly the same thing. He will take all the props of the chat and he will compare it to see if there's a change. If there's no change, he will return false. If there's one change, he will return true. So if I do that, I expect the same thing happening now in my apps. Sorry. So let me remove the short link because I don't need to record anymore. We just show the change in the highlight. So does it work? I know it's not working. Why? Can someone try to, I give you one minute because it's interesting exercise to do. Can you try to find out what the pure component does not work as expected? Because we expect the pure component to do the same comparison on a shallow comparison on each props. But in this case, even though I'm sending the same data, I'm doing the same action, he's still rendering the bubble. It means he's written true if one of the props is different. Otherwise, he's written false. And in this case, he's written in true, but it should not be written in true. It should be written in false because my bubble here is not changing. So why? If nobody has find it, I will show you why. It's because if you look at the chat here, when I pass my chat container, I'm passing two props. I'm passing a chat. This is the one we were comparing manually and we are passing a container ref, which is another props. And the way we pass a container ref, if you see, here is a function. And this function, every time the chat is re-rendering, he will create a new reference of the function. Every time there will be a new instantiation of a function object. That's why even though we are doing pure components, he's comparing both of them and the container ref will always be a new reference to a new function. So to avoid that, what you need to do is to have a constant. So either, if it's not a function, it's just a constant like a constant value, you can create a constant here. So that it will always send back the same variable. So that the reference will never change every time you render against this component. If it's a function, what you can do is you create it here in the ref as part of your component. You apply the same code. So a chat container, sorry, chat container here. Oops, is the attribute. And don't forget in React, when you want to do this, use this inside the function, inside the function inside the component, you need to bind it, okay? So I will have to bind. This is part of React. If you want to learn more about this, you can look at the, you can check on the React documentation why you need to bind, okay? There's another library that can help you to bind automatically, but I didn't install it. So just for this exercise, I will just directly bind. So I want to bind the current disk of this component to the disk of this function so that the disk disk will be the same, okay? By doing that now, I can tell him every time you render, what you pass in the props, I don't want you to instantiate a new function. I want you to use the same function. So now let's try to have a look at the chat. Oops. Alex four. I highlight the updates and we can see it's working, right? So be careful about this. This is one trick that can happen often. You think you are using a pure component and is doing the correct comparison, but if you are not passing a constant, if you are not passing the same reference, it will change it again. So again, immutability is a very important concept for this to work as a pure component, okay? But in that is true also, don't forget that the shallow comparison is only on the reference. So if you are not doing immutability correctly, it will not do the comparison correctly and you can have some in-expective behavior, okay? The next thing I want to show you is another library called recompose because here what we did to do this should component update, we had to make a component as a class, okay? Because for those who knows, or for those who doesn't know, React has many ways of creating this component class. One way is to create a class. The other way is to create a component as a function. When you create a class, we had, sometimes we had a constructor, we had many lines of codes, which could be creating more bugs. So some people doesn't like to do that, especially if you do a presentational component, there's no need to have a complex class. So what there's a library called recompose. It's already installed. If you did the in-payment install, it's already in the package.json. If you go to mention, so mention is an example of here, of a component that is just a function. There's no class here. But since there's no class, I cannot add this should component update. So this recompose, allow me to, is the principle of higher-order component, okay, is another principle in Redux. In JavaScript, you have the principle of higher-order function. So you do the same with a higher-order component, is taking something in parameter and will return you a component, okay? So here, I can do import. Oh, before I do that, just to show you, we can see here that every time I type, here you see this part here. If you look at the mention, every time I type, we can see a square around mention. It means it's being rerundered, right? But it's the same, we don't want to render it. We render it because there's no point to changing the mention when I'm typing. So I will use pure from, from recompose slash pure. And only thing, one thing I need to do is just pure. I encapsulate, I encapsulate the component so that you, so that you send back a new component that will execute also a should component update like pure component. And now, if I log in, okay, I need to highlight the update. So I can see mention is not being rendered anymore. Okay? So this recompose for people who is interested, there are many other high-order component, like a should update to allow you also to personalize your should component update and other high-order component that you can have a look, okay? The next library, the next thing to know is about Redux, right? We use Redux in our application. In fact, if you use Redux, you don't need to do this should component update or this pure component because Redux is doing it for you. Well, inside this function, when you do the connect for Redux, when you're connecting your component to your store, there's a multiple parameter. Map state to props, map dispatch to props, merge props, and the last one is option. And by default, the option has a pure attribute that will be true and that will do this comparison. He will, when you finish to map the state to prop, he will compare the previous props to your new props and he will do the same. He will return should component update to true or false depending if there's a change in the props. So quickly, here in the check container, I can show you. You can see here, this object is not linked to the store. This is just exporting it, so I'm going to link it to a score. Just here there's a file, index, Redux, or taste. I'm just going to do some copy pass, okay? So I'm taking this code. I change the export. So what I did here is I connected my chat to the store and I say every time the state, what I do is I send the chat props from the state. So every time the chat will change, he will, this component will be run there. Every time the chat list will change, this component will be run there, okay? And here, since we are using immutability, when I do state.getin, the chat list will not change because the action that we are doing when inputting a character will not change the chat list. So he will do a comparison and the same he will see that the chat reference didn't change and he will not update the component, okay? So quickly, do I still have time? Okay, I still have 15 minutes. So I can see here, oh, let's remove pure component to make sure we are really not applying any true component by default now is true because I didn't, I commented dysfunction and I'm not doing a pure component anymore, okay? So now, okay, just I reload everything to make sure just to show you that we are really having the latest code. So every time I type, I like the dates, the same. Now this chat container that I connected to the store, he's comparing, when I connect to the store, he's comparing the reference. He see that the reference doesn't change. So he's not rendering it again, okay? So this is why some people say you need to split, you need to split your application when you are using Redux. This is why splitting your application into multiple linking the correct component to the correct state will also do optimization behind, okay? But behind is still shallow comparison. So you have to understand that this will work the same as the pure component, the true component update that you created manually, only comparing reference, okay? And this is why I saw this one, this part here, doing export, default, connect, and send. Say I want to link my apps to the whole global state, means you are not optimizing anymore because every time there will be a change on the state, even if it's not linked to your component, he will render this component again, okay? So this should be avoided. Or if you do it, it's really one component that really need to have everything in the state, which may be the case for small application. But if you have a big state with a lot of information inside your store, then normally you should link the correct component to the correct part of the state, okay? So comparison is still shallow, okay? But there's the last tool that I will present you for this workshop is a reselect, okay? So if you look at why does it matter that he's doing a shallow comparison is that here, when you do map state to props, sometimes the props that you want to return, maybe it's not exactly the state inside it. You want to do some re-computation, calculation, filtering, reduce, or whatever. And since you are doing maybe a new array, he will always send you back a new reference of this array. So it means it doesn't matter that he compare the to-dos. Even if the state to-do and the state visible filter doesn't change, because of this function, you are going to return a new reference. So the previous to-do reference and the new reference calculated by this function will be different. So even though the content can be the same because we didn't change the to-do or the visible filter, it will, or maybe we change it, but the calculation return the same content, it will still re-render everything. So there's another tool called reselect that allow you to improve this a little. So what does reselect do? The difference you can see here. Now my get visible to-do, instead of simply sending back a new reference, we are going to use a create selector from reselect, okay? So this create selector, what he's going to do? He's going to take in parameters on selectors, which are these two functions. And if these selectors see that the state inside that we are using didn't change, he will return the previous result. So kind of the create selector cache the previous props, the reference to the previous props, and we return it if you see that what you are trying to use as for your calculation here, didn't change. So the same is a shallow comparison, but at another level, okay? If a behind below you change it, what is comparing is just the visible filter, okay, the reference. But this allow you to improve also this solve the first problem that now you will know every time he's going to return the different reference. Now in case the content of the state didn't change, he's going to send, he's not going to do this calculation. He's going to send you back the previous reference, okay? So if you really need to optimize your app, then you can think about this one as a part of your reduced way of building the application. Let's say you don't need to think it from the start because maybe there's no optimization to do and this could be heavy to implement. So but once you have some issue, then you can start to think about if this can help you instead of having to do some manual trick to make sure we return the same reference. This could be useful, okay? So in summary for this session, what I show you is the production build. Don't forget that there's two builds in React. Second thing we show is we look at some tools using Chrome and the React developer extension in Chrome, okay? To show this Flamm graph and to also have this highlight of your component live. Then we speak about how does your component update with the virtual DOM recalculation and comparison. The pure component that is doing kind of an easy way for you to compare the props and the redux that is doing it for you that you don't need to care about pure component and pure component update if you are linking the correct state with your component, the correct slice of the state with your component. Don't forget that it's shallow comparison. So immutability is very important for this to work, okay? And I presented some library like recompose reselect. You have other library that could help you from optimization. I didn't speak about this one. Why should you update? For example, it's also linked to redux and it will console log a lot of things to suggest you. You are re-rendering something but the props didn't change, okay? So you can play with this tool as well if you want by yourself, okay? So I think that's all for this session. I hope it was interesting. So I think the team, all the team, thank you for coming here. Before you leave, we have some t-shirt, okay? But maybe we can take some questions. I think we have some time, right? Yeah. So we still have 10 minutes. Anyone has any question about one of the three workshops about the... Oh, one question. Yes, I get two. Yes. Yeah, I mean, you're using redux as your state management. Have you used MobEx or some other state management? Or do you prefer redux? So far, so far in our own project, we are using a lot of redux, okay? Because it allows us to do all this optimization and we are... It's quite mature. We didn't play with MobEx or other state management, so I will not say which one is the best, but the redux is quite famous and also is using the concept of flux. So that's why it becomes a very streamlined and it's really doing the job that we need. But I cannot tell you about the other framework because we didn't play it to tell you what are the pros and cons. Thank you. Thank you. Anything else? It was very interesting how you put this socket in the middle where I was wondering how we should do that. I was thinking we would have to keep the socket in redux, but that seems... That seems in the redux store, but that seems wrong. So I like your way. The problem we have is our login doesn't create... We don't have the socket when we set up the store and it's not created until they do the login. So in that case, I was thinking I could just pass an empty object to the middleware and later put the socket in the middleware. That sounds reasonable. Can you repeat the part when you say that when redux have no store, something like that? Yeah, so we don't have the socket when we first set up the store and we haven't created it yet. It's only when they hit the login button that we create the socket. No, actually, when we apply the middleware, so when the application loads, the JavaScript actually runs the part where we initialize the socket object. That's how it works for you. I'm talking about our app. Oh, okay. We haven't created the socket yet. We don't create it until later. But can I just pass an empty object to the middleware and then put the socket into that object later? I think it depends on how you want to do it because the thing on the socket is that you want to listen to the event. So if you're passing an empty object, when the application loads, the socket is not initialized yet at all. So if any event is coming in, you can't execute anything because the socket is an empty object that you're passing in. So the way to do it is to find somewhere when your application loads or before, prior to when you need your socket connection, you have to initialize the socket object and, of course, listen to the various events that you're listening to. Yeah, okay. Yeah. Thanks. Thank you. Yeah, that's right. The question is, say, if there's a state that will trigger multiple actions, how would you, like, trigger the actions? Because I tried it in the loop, and it was just infinite loop. And my Googling tells me I have to use a batch action. I'm not sure, like, if. And why can't we use it in the loop? Okay, so when you want to dispatch multiple actions, so there's, in Redux Act, the one that we use, we actually have a, if you look at the documentation, there's actually one function that allows you to dispatch, which you mentioned, batch, right? To dispatch multiple actions. We are not doing that, but what we are doing is, instead of dispatching multiple actions, because normally when you dispatch multiple actions, it could be, you want to clear this, you want to stop this loader, you want to do that thing. So what we are doing, if you look at our Redux, which we have, we have a pipe function, right? So we are actually piping through a different set of mutators. So we are actually only using one action that is like doing a series of things in there. So the good thing is that if you dispatch like multiple actions, your application might render a few times, right? So that might be some trade-off with performance. So what we are doing is, one action that's dispatched, every mutator changed the state, but the state that we are changing, we are not returning it to the reducer yet. So it doesn't render the app. So the state from one mutator to the next, right? For example here, you can see we add new message. It changes the state. The current state passed to the next state. Carl mentioned it does something to it and passed to the one until it ends. So now we have a new state that's been modified by all these mutators and then we return it to the reducer. And so there's a few changes there, but the app only re-rendered one time. Yeah. Okay, any questions? Great. Thank you very much for coming. Hope you enjoyed. We have t-shirts. I think we have enough t-shirts, but I don't know about sizes. So please come over and collect your t-shirts. Or you can... Yeah, we'll distribute it to you guys. If you have a different size, any kind of these better that they come. You can decide your name.