 See my screen? Yes. Recoil. Let's see. OK. All right, so hi, everyone. Yeah, my name is Eric. I'm a front-end engineer, Rakuten Biki. And I'm really into React ecosystem as well. So today, I'm going to talk about, I'm going to share with you guys my first look into Recoil. This is a new management library for React. So the context for this is, well, React Europe happened last week, last Friday. And as many of you already know, React Europe is a place for a lot of open source projects to be introduced. Like, five years ago, Redux was there. GraphQL was introduced there. And among a lot of open source projects that introduced this year, we have Recoil. It's done, it's created by a team in Facebook, not React team, but another team in Facebook that use React. It's created for React. And I was super excited. And I decided to try it myself. And I want to share with you guys about what I found within the last few days. So please excuse me if the talk is not very well prepared and it's very spontaneous. Hope you guys find something interesting in it. So first of all, I just want to emphasize that this point, which is I quote some of the well-known engineers here. We have Dan Barmove, Ken Seedolls. And they only say React is a state management library by itself. And why is that so? Well, a client app always, we think of client app in two parts, the data management and rendering flow. And React is always known for its strong rendering engine. But also with the recent development, it's getting better data management as well. So just back to the basic first, we have this thing called lifting state app. So well, data need to be shared among components We basically lift it, lift them up to the common ancestor so that they can be accessed and mutated in that common ancestor and then update to the sharing components. But then with lifting state apps, we go to the problem of prog dealings. I'm sure a lot of people have faced this. Like we passed the same props across a lot of levels of in the component tree without using them. But React also have a solution for that, which is React context and even get better with React hooks because now you don't need to have like a huge tree of React consumer and well, basically it's just nicer to use React context with hooks. But there are problems that React context doesn't, it's not very good at. And recoil was created for some of them. And here I take the slides from recoil co-author himself, Dave. This is a slide in React neural. So if you guys are interested after this, you can go and watch the talk. It's very awesome. Every idea is very well explained. And I take a lot of inspiration and even my example will be very similar to his example, but a simpler version. So he talked about recoil is trying to fix like simple share state, derive data and queries, and up wide state observation. Those are all like very broad and very hard to explain. So I'm going to go down slowly. So to try this out, I created a demo project. Basically, this is a photo grid editor. I think something like a grid on Instagram where people put in multiple images. So just take a quick look at the final one. Oh, yeah. I wanted to introduce my company more, but I forgot about it. OK, so this is the demo project. We have the editor here. We have the settings on the left side, the preview panel on the right side. You can add multiple images to it. So these are some random images, a square image for the demo. And you can play around with the border and to make it cool because the same border doesn't look very cool. And you can even have a different color for it, things like. It's 20 hours. So yeah, basically you can play around with it. And my plan was to use the upwire observation and state positions to make it even exportable. But I haven't done that part yet. And also you can edit the color from here. So as you can see when you click on the image, I'm not sure if you see my mouse, but clicking on the image here, let me see. So when I change the background, the border color here, both of the setting panel and the preview panel change. So basically that's the idea. And a very important point I can add as many as I want. So that's the final goal. So let's do some brainstorming, just like exactly what mean just now in the demo as well. We break down into components. We have a great editor here. We have a setting component on the left, the preview panel on the right. And to go down into the setting component, we have the add button here to add more images. We have multiple settings for each individual image. And then in preview, we have a grid corner and the image preview components. So after we break that down, we get something like a React component tree like this. I'm sure a lot of you have familiar with this. So we have a grid editor on top and then on the assurance. And each of the image here are corresponding to the one, each of the image in preview is corresponding to the one in the list of settings. So with the features of this demo, when I change anything here, it's going to be updated. The views are going to be updated from both the panel. So basically, when I mutate data in image one in both preview and setting, I need to find a way to share a state and tell the guy, hey, I'm changing the color of this image. I'm going to try to render the new color. So with the React way, again, we leave state up. And the common ancestor of those is actually the grid editor, which we can assume that this is the parent of own. And the problem with this is not just a prop during. We're assuming that we use context for this. We don't need to pass state throughout this on the branches. But the problem with this is because we store unlimited number of image, and we store the state in the grid editor here. So whenever we change one image here, the whole sheet will be rendered. So re-rendering is not necessarily the very heavy part because React does a great job in a re-rendering engine with a reconciliation process. So actually, the VDOM is updated. It's re-render, but the DOM 3 is actually not. So React is very smart at that. But there will be some cases in huge app that most of us won't face. But in some cases, we might reach the performance budget for this. If you have 1,000 image, or if you have a lot of image, the whole sheet will be re-rendered. And that's where we need to improve. And that's where recoil come in to help. So next out, again, I'll take a deep slide here because he draw an amazing graph. So imagine that this is the whole component tree that is updated after the state of one individual image is changed. How he explained this idea is he bring this whole tree down into a two dimension and bring a new dimension to it, which is called a state dimension. So this will help with a widely shared state. So basically, you don't need to bring the state up to the common assessor anymore, but you have an extra dimension to store the state for you. And each of these is called an item, which store a unit of data. And imagine each image here, we only subscribe to one item. So changes for one image won't affect any other images and won't affect the whole component tree anymore. So with that, let's look at some of the recoil core concepts. We have number one item. So item is a unit of state. It's updatable and it's subscriberable across by a component. And it is unique key to keep the state persistence. So the right-hand side is one of the example. You create an item by using item function. You pass in a unique key and a default value. And down here is how you use it in a component. So how you use it in the API is very close to React Codes, which make it amazing to use and very easy to pick up. And the next thing is we have selectors. So selectors is basically what conceptually is a pure function that takes in an item or another piece of state, which actually can be an item or a selector, and then render a state from there. So in this example, we have a phone-side label state. For some reason, this guy need to store it as a state. So he use selector to get a derived state from the item phone-side state. So the get method here is like a helper method from recoil to have you get other items or other selector. So basically, you can pass anything here, as long as it's a recoil state, which is either an item or a selector. And then you can use recoil value here, which is for the read-only state, because most of the time for the derived state, you don't need to read it. You don't need to write it, but only read. So with items and selectors, we create a kind of a directed graph that attach to the React tree. And in any of those, for selectors, any update on the items or any upstream items or selectors update will trigger the downstream items. And it's very useful for deriving state and data query. It also works with async queries and stuff. But I haven't gone into React part yet. So back to this graph. We know that this is a piece of data. And it gives the state to the component tree. And now let's think about our demo again. And let's translate it into the code. So I have done the demo, so I'm not going to code it now here. But I'm going to show you some of the part that need to be done and basic API that recoil give us to achieve this. So first of all, you need a recoil root. I think I put it. So a recoil root is like a parent. Yeah, basically is a wrapper of your app or the highest level component. So Eric, could you zoom in a little bit? I'm sorry? Oh, zoom in? Yes, please. Is that good? Yeah, that's better. Thank you. Cool. Yeah, so we need to wrap recoil root around our highest level component so that all the cheering components will be able to use recoil, basically. So just to map this to the app, we have a app that render a recoil root wrap around an editor. And in editor editor, we keep a list of image IDs as a state. And then we have a combat function to add image to it. And then we pass it out to a setting. And then in setting, basically, we just render the button and the list of image from the image ID. So the reason why is what I'm going to explain after this is the same with preview. So we have a preview and we render the list of image preview with the ID. So now it comes to the interesting part. So I have created the whole component tree to be updated when we change the style of one single item here. If you use context, there's no way we can achieve that because we are keeping track of unlimited number here. To explain it more, if you use context, we need to separate each of the image settings to its own context. So if there is an image, there will be an react context. And there will be a lot of unlimited provider and unlimited consumer, which is not idea. Image on list, then it will, and once the context is updated, the whole list is updated. So I'm going to open the react depth tool here and try to highlight the react update. So as you can see here, if I change the color, only these two components are updated. And same to the border. So it's very granular and it's very efficient. And imagine that you have something like a design tool or a graphical editor like this. It will be super, super efficient to have that. So to achieve that, I create items on the fly using the image ID. So this is to create unique ID for each of the image. And then this is a default value with the size, the color, and the source of it. So now with that, the good thing about Recoil is that it memoizes all the data for us. So I mean, I'm not sure how they do it. I haven't looked at the source code yet. But basically, this function is memoized. And whenever you call the function with one ID, it will return the same thing. And it won't run again if you already call it. So it's very efficient and it's very cost effective. So with that, we have a cool Recoil state here. So imagine if we don't have to change the color from the image review, we just need to render it. And we can just use Recoil value, which read the image itself and then render it. But now we want to mutate the image data in two places. So we use this here. And as you can see, it's very similar to React host API. You can just, instead of use state, you can use Recoil state. And it takes almost no time to get used to and to get to the, to grab the mental model of the library. So the red is very simple. I just render the image. And I have input that mutate the border color of the image. And the same thing happened in image setting. I also have use Recoil state from Recoil. I get this from the items here. And then I update the state. So every time I change the border or change the image, only the item of that unique key will be updated. So I can add as many images as I want. And then if I update any one of them, it's not going to render the whole component tree so that is very cool things that Recoil bring and is very efficient. So that's about the demo. I don't have the example for select yet because I can't think of a use case for it in this app. That is simple enough to implement in a short time. So yeah, I didn't do it. So what is the benefits that Recoil bring after on the talking and on the demo? First of all, a very strong point, Recoil is minimal and reactive from what the co-authors say. So what does it mean by that? As you've already seen the use Recoil state, and the Recoil API in general is very close to React semantics and React Elemental model. So it's very easy to pick up if you're already familiar with React and it's way easier to add to existing project when you really need it. So only when you reach the point that you exceed the performance budget or you find the problem that React context cannot help, then you can reach out to Recoil and then try it and use it. The next thing is present an explicit data flow graph. So what does it mean by that? On the subscription now explicit. So as you can see, for example, in this demo, but in the previous example, you can see clearly here that full-size label state is dependent on the full-size state piece of data. And with all the unique key and all the pure function Recoil kind of introduced the data flow graph clearly for us. So it's easier to understand and debug as well. And as you can see in the demo, it's very efficient in updating the deep componentry because of the direct manipulation, for example, your graphical editor tools, design tools, like TICMA or maybe graph editor tools, stuff like that. And another benefit is that because it's built for React specifically and it depends on the React batch to do all the optimization, it is also compatible with concurrent mode, which, again, I haven't got time to look into. But very interesting point because a lot of state management library out there is not ready for this one yet. And there are more benefits listed and mentioned by the authors, for example, code splitting, lazy loading, and stuff. So I'll leave it for you guys to explore. So to conclude, I think Recoil is a very interesting library to explore. It's still in experimental state. So it's going to take a while to be mature and to be adopted by the community and by industry. But it's definitely something to look out for and something to explore. And what I like the most about this is the emphasize on using React first for data management and only reach out to the external library when you get to the point that the React can't solve. And that is a strong statement and that benefits a lot for the industry. So that's it. And again, some show me this part. Rakuten Viki is hiring. You can reach out to this email. I will paste it in the chat later. And yeah, that's it. Thanks for and see you again.