 OK, so let's start. Good evening. So my name is Ming Pham, and I'm an engineer at Facebook. And thanks for inviting me today to share with you guys about a small library that I have used in one of my site projects. And this library has helped me a lot since then. So let's look at an example on what this library can do. So let's say you are trying to be a social network, and you need to implement a feature where user can go in and like a post. And you are the front-end engineer for this app, and you decided to use React plus Redux for this, a pretty popular choice nowadays. And so you might have come up with something like this for your Redux store. So you have something like a store with a post, at least a post. And the post is just a dictionary of the post IDs and match to some metadata. And in this case, your metadata contains some like, like by information, which is just the user IDs of users who have liked this post. So let's say the user clicked like on the post. What kind of changes we need to make to our data models so that it can be reflected? So you have been using Redux for a long time. So you might be comfortable with looking at this code, and you might understand what it's doing. So firstly, we're trying to clone the original store, and then you override the post by cloning the post itself and overriding the specific post, and then adding the new user IDs there. So this is a lot of code. And the reason we're trying to do this is because you don't want to change the original store directly, because then React will not know how to render, re-render your apps. So that's why Redux always requires you to clone the original objects instead of directly changing it. But with all the benefits of Redux, this still looks a bit clunky to me. Like you are doing something very simple, but like this logic is like 10 lines of code, which is not that great, and your data model is not that complicated actually. So introducing Emer, this is going to solve the problems of updating deeply nested values. So writes there is like the same exact logics written using this library. And it just relies on code. So it's like 66% productivity improvement writes there. And so what Emo is supposed to do is just want functions to produce. And it takes in an object. And the second parameter is just what type of changes you want to make to this object. So you can think of a draft, something like the clone objects of the store itself. And after this, the function returns. And it will not modify your store, but return a new object with your modifications. So I love productivity. So that's what makes me really like about this library. And this story is no surprise. It's so popular because of the friendliness. So it has like 14,000 stars on GitHub. And one of the React core teams had a very high place about this library. So what is immutability? Immutability means that you never change the object. And instead, when you want to make a change, just make a new object with the modifications. And it turns out that React really loves immutability. Because if you think about React, what it's trying to do is just bring out what has changed and then re-render the apps. So by returning a new object every time, React will know that it has to update itself. And immutability, it turns out, is also very great for optimizations. So, yeah, work long enough, you know that there are some React-react lifecycle like suit component updates that can greatly exploit the immutability aspect. So why email? Obviously, this is not the only library that is introducing immutabilities to React. There are a few others' library, three at least. But the things I like most about this library is its API, very simple. The API is so intuitive because all the things it's supposed to use is just plain JavaScript and just one half of functions. All the modifications, you know, is just how you do modification in old style JavaScript with your objects, with your arrays, how you add to a list, how you remove from a list. It's so simple. Comparing with another library like Immutable.js, the logics also looks like pretty short. But the abstractions and APIs are not exactly that nice. You have to learn a bunch of new syntax and some weird syntax, like you want to update something. You have to pass in the keypads. That is not really idiomatic JavaScript. So this might lead to a bit of very steep learning curves for you. Secondly, Immutable.js is 100% type safe. So if you are building a very large-scale JavaScript applications, then type is your friends. So in this case, all I need to do is just type the original object, which is the store, and then immerse smart enough to figure out what can be changed. And in this case, I'm using the editor hintings provided by the type safety fee. Comparing with Immutable.js, then it's not 100% type safe because you are using some dynamic features of the language, which is keypads here. And there's no way that either flow or TypeScript can know about it is type safe or not. And finally, email is pretty efficient. It is a pretty small library standing at like 6 kilobytes after compression. And surprisingly, it has some pretty advanced features, like structural sharing, which is when you try to clone the objects, it will not just do a freeze, like dumb clone. It will try to figure out which is the same part, which stays the same between two versions and keep that part, and only create a new modification based on that. So it is great for memory saving. So that's the reason I like the most about this library. And give it a try. I hope you can enjoy it as much as I am. Thank you very much.