 This is the slot before lunch. So awesome lunch is waiting outside for everyone. But I hope that you will not react to those temptations and instead hear me about react. So I want Twitter. This is my Twitter handle. I work for Big Binary. We are a Ruby on Rails consulting shop. Recently we are also doing a lot of ReactJs work. So if you are interested in some work you can contact me later. This is my second time in Singapore. Last time I came for my first Red Dot RubyConf and I gave my first ever talk. So today I'm more excited because I'm giving my first ever JavaScript talk at a Ruby conference. So I want to thank you, the organizers. Okay, so what is React? React is a JavaScript UI library that was first developed at Facebook and Instagram. Right now it is open source so everybody can use it. It was designed to build large applications with change data over time. So that was the main purpose. Its scope is very limited. So it's not like a big framework where you do a lot of things. Its task is to only render the UI. So only building the UI. It only concerns with the user interface. And so we can't really compare it with a traditional MVC client framework like EmberJS or AngularJS. A lot of times people can use React as a V part in traditional MVC architecture. And that is because it doesn't care about rest of the stack. So whatever you're using in your existing app, you can easily drop in React for some feature, try it out, if it doesn't work you can still go ahead with your existing stack. React's aim is to be very simple. So it gives developer power to express how their UI will be rather than, so you're always talking about what you want rather than how you want. So it has a declarative API for doing that. And once you declare how your UI will look, React will take care of updating, rendering and whatever it wants to do with the UI. So you just specify how your UI looks like and React will worry about how to render it properly. So let's say if I have a video uploading job and video is uploaded to some background processing for encoding, in a traditional way, what I will do is I will pull like, if the encoding is completed, if it is not completed then I will be keep showing the loader message, otherwise I will remove the loader. So I'm doing something with the DOM, I'm removing something or I'm changing the header text that encoding is completed. In a declarative way, what I will do is I will just declare if encoding is completed, this is my UI. If encoding is not completed, this is my UI. So React will take care of showing this UI whenever the data changes or whenever the encoding gets completed. React also has a lot of unconventional ideas that go against the traditional way of web development. So we are doing things in a certain way till now. And React says that, okay, these things work but we want to do things in a different way. And it's worth discussing those ideas because that makes React what React is. So let's start. First we'll discuss the components. And component is just a bundle of HTML, CSS, JavaScript code put together for specifying a certain part of the UI. So UI is broken into separate units and each unit specifies a component. This is the primary building block of React apps. So in React, what we are doing is just build components, just build more and more components. So this is the simple example of hello world component and this is the create class API, top-level API of React, using which we can create a component. Every component must implement a render function so that render function specifies how your UI will look. And then there is a method react.render using which we can render the component, hello component, and we can mount it on element. Like I'm mounting it here on document.body. So component is really a simple function, that's it. It gets all the data that it wants and it returns the UI specification that we want to render ultimately. Now let's look at my Twitter timeline. So if you want to render it using React, what we'll do is we'll just break things into different parts. Like the profile information can go on its own component. All the tweets will go in their individual tweet component and we can break the other parts also. So for tweet counts, if you want to render the tweet counts, we send it the data that it needs, like tweets count is something, following count is something. We send all the tweets to individual tweets component. So we are sending all the data and that's why the components are becoming reusable. So a component has everything that it needs to render a particular piece of UI. And it, as it is just a small unit, it can be reused in other places. So like this, I'm composing everything that I built earlier into a big timeline. So timeline is the parent component and it is composing off my tweet counts, tweets and trends. By building these small modular components, we get same advantage that we get in our server side code. Like in Ruby, we always try to model code in functions or classes, which do a single thing. So similarly, we get the same advantage, but this time in our UI code. And this is the right separation of concerns that React provides for our user interface. So what we are actually doing is we are doing, we are building a component library for our domain. And there is nothing new in this concept. Like we are already doing this in our server side code, but React by default provides this. So as you have to build components in React, you are automatically doing the, automatically separating the concerns by default. So let's look at our component again. As the written statement says, it is just rendering the HTML, it is just rendering a div tag. And if you see closely, we are writing HTML in the JavaScript. So it's bad, right? We avoid this, right? We keep the HTML separate from the JavaScript. So HTML templates are at separate place and JavaScript that renders HTML is at separate place. So it's bad, I'm confused why we are doing it. Well, this is not really HTML. So what we are doing here is we are using something called a JSX, which doesn't get evaluated, so this doesn't get evaluated into a HTML string, but it actually builds a component tree similar to our DOM tree. So this is not HTML, it is JSX. And if we search what JSX is, so JSX is faster, easier, and statically-type programming language, but JSX is bad. It is not what we want. So JSX is so bad, it even trolls Google. So if we search for JSX, the first search is something different, faster, safer, and whatever, JavaScript, but we want the second search. So JSX is so bad that it even trolls Google. We want this. So JSX is actually a XML syntax extension for JavaScript. It allows us to write HTML tags so that we can specify our UI just like DOM. And it's not a separate language, so it is not something like CoffeeScript, which is built on top of JavaScript. It's just a preprocessor. So before our JavaScript gets deployed to production, we convert JSX code to a normal JavaScript, and it just acts as a preprocessor. It is also optional. So if you don't want to use JSX, you can skip it and just go with the pure JavaScript approach. But I'm not sure many React developers might be going with JSX approach. They will not go with pure JavaScript. So JSX is allowing us to write UI, just like we do in our normal HTML stuff. If you're still feeling a bit annoyed about JSX, it's actually healthy for you. It can feel bad, but you can feel guilty, but it's actually good for you. So this is the code from Eric Iliad. And I got inspired by this, and I decided, okay, I will also write something about JSX. So JSX is like durian. It smells bad, but it's actually good. You can tweet this if you want. And it's not just me. Our keynote speakers also believe this. So they're happy eating the durian. Okay, so I am happy. Our keynote speakers are happy. You should also be happy about JSX. And if you're still annoyed, just give it five minutes. I know that it is something that we try to avoid. So this is a great blog post about not reacting to anything without thinking much. So just give it five minutes to JSX, and you will feel good, you will feel easy. Okay, so the next topic is no templates. React also doesn't have any templating language associated with it. So templating language, the problem with them is they're conceptually similar. What we want to do is we want to have a loop which iterates over our collection and does something. We want to have some conditional statements, like if this, then do this, else do this. So these templating languages, they are conceptually similar, but they have different syntax. So whenever I'm trying a new framework, I have to learn, if there is new syntax, I have to learn that. And that's why React just goes the JavaScript way. So this is a code by Jasim, and he says that any templating language is a slow implementation, bug-ridden implementation of a complete programming language. So what he's trying to say here is that you have all those features present in the programming language, and in our case, for a web, that programming language is JavaScript. So React, instead of writing a new templating language, you just use JavaScript. So let's say I have a list of tweets, and I want to iterate over them and render each tweet individually, I will just use the map function, which is provided by JavaScript. So there is no need to use a different templating language. React just leverages the power of JavaScript. Yeah, so it is, everything finally is only JavaScript. And this means you can use your normal variables, control structures, all the programming abstractions that are present in JavaScript, and write beautiful organized UI code, view code. This is another problem in front-end development, like how you will manage the state, how you will manage when user interacts with your DOM or your UI, something will change, and then you have to manage the state in your view models or models, you have to pass the data around, and users should not feel that something has gone wrong. So managing state changes, DOM mutations, it's challenging. Pete Hunt, who was the original developer of React, he says that it's data changing over time is the root of all evil. So React comes with something called as props, shorter form of properties. So props are like attributes of your HTML elements. So let's say I want to render a tweet like this, I have the tweet content and the author name, then props come from above. So the tweet list component here, it's sending the author information and the content information. So I'm just sending tweet.author, tweet.content, and this curly braces means that this code will be evaluated as a JavaScript expression. So you just put any JavaScript expression in those curly braces and it will get evaluated. And then it comes up, comes below to the tweet component and we access those props as this.props, this.props.author and this.props.content. As you can see, this is one way data flow. So data is coming from parent component to the child component. It is not like child component can pass data. Yeah, it can pass, but right now just, let's remember that it's data is coming from the top. Props are also immutable. So the component that sends it owns the props. The child component doesn't own the prop. So the child component cannot change those props and reuse them. He has to depend on the whatever data that is sent by parent component. React also allows to validate props because sometimes what happens is you're using some library and you want to make sure that, okay, whatever data I'm passing, the types are correct. So react also allows to do this using prop types function where you specify that, okay, my author should be a string, my content should be a string, my count should be a number. So in your component, if you add this, then in development we get a warning that if you are not following this, like if you are not passing the data or if you are passing wrong type of data, you get a warning in development. Prop types also allow to specify like, is this field required or is this not required? Like you can pass it or even you can skip it. So it has a syntax for that. The second way of managing data in React is using state. So every component can have its own state and that state is internal. So we saw that a component cannot change its props which are passed by the parent component. But a component can change its state because the state is owned by that particular component. So to get started with state, what we have is we have a initial, get initial state function. So whenever every component renders, this is the first function that gets evaluated and you can set the initial state. Just like our initialized method that we use in our normal Ruby code, this is the initialized method for React. And then in the render, instead of props, we are using this dot state dot props. So we have the access to that state as this dot state dot something. React tries to avoid state as much as possible. And the issue with state is changing state, keeping it at different places and managing it is hard. So what React says is that you should avoid states as much as possible. So state is all, like most of the times, state is present in the topmost parent component and then you pass props below. So the child components, they are stateless. And stateless components are preferred in React. So if you can render a component using only props, that's better. Don't go for state, just use that props. Keep state at a minimum place. Don't use state if it is not required. It's actually a sort of anti-pattern to use too many stateful components in React. But we know, right, state will be there. We can't eliminate it completely. Like in my tweets example, if I'm pulling new tweets from the server, there has to be a component which will pull the data from the server and will pass it to the child components. So how we will respond to state changes? Now React provides some event, some lifecycle hooks. So whenever component gets mounted, we get this component did mount. And we can execute our code to fetch the data from server. So here I have written a simple load post function which loads the post. And then when the posts are fetched from the server, I change the state. So whatever the initial state was, it gets updated using this set state function. And then I pass a JavaScript object. Like whatever the fetch posts were, I just assign it to posts. Now, if we consider the web 1.0 era, whenever something used to change, the simplest solution was just refresh the page, you get the new data. So that worked for a while. But as we are writing more and more interactive apps, it's not possible. We can't refresh the whole page. We want to render, we want to change specific parts of the page. And React does that by re-rendering that particular component. So whenever a state of a particular component changes, React just re-renders it. So whenever the state changes here, render function will get called and posts will be rendered again. So that particular component will get rendered again. And it's not just that particular component because it can be a parent component. So it can have a child component below it. So it will re-render the whole component tree. Now you must be thinking, why we are doing this re-rendering? Will it not make my app slow? Why we are re-rendering every time a simple thing in state changes? So it turns out that they have thought about it and virtual DOM comes in the picture. So it's not actually slow because of virtual DOM. So in React, we never deal with the actual DOM. We are always working with the fake DOM, which React keeps track for us. So we saw the return value for this hello component. What it actually returns is something like this, react.createLm. So it is not returning actual HTML as I said earlier. It is returning a description of that div tag. It is returning a UI specification. So what happens is whenever state changes, what React does is it creates a virtual DOM for new state. It dips it with the current, whatever the description that is present in the memory, it dips with it so that it finds minimal changes. So if I'm rendering 10 tweets and nine of them are not changed, then it will only find the one tweet that needs to be rendered. So it finds only the minimal set of changes. The other thing React does is it does batch updates. So all the DOM changes that needs to be done, they are done in a single call. And that's why it is really fast. If you think of it, nothing is new here. We already know that DOM changes are expensive. We should limit the number of changes that we are doing to DOM. We already know that batch updates are fast and we already know that if we try to do something in our JavaScript code, it will make our interactive apps faster. But React sort of gives it for free. So even without you knowing it, it is doing it for you. So that was first part of the talk. I talked about a few concepts, a few ideas that React uses. Now let's see how React can be integrated with Rails. So there is a good news for everyone because it is far easier to integrate React in Rails rather than setting up a project with JavaScript tools like girl, current, what you find, everything. So there is an official gem React Rails and this gem allows to integrate Rails with React very easily. It provides a generator for installing React and then it creates, it adds React JavaScript, React unobtrusive JavaScript and it creates to this directive. All of your components should be in this app assets components directory and then a single file for managing the list of components in that directory. It also takes care of converting your JSX code to pure JavaScript code. So you just have to write .js.js files and the gem will take care of converting it before assets are actually pre-compiled. So this is a simple ERB snippet I'm iterating over the posts and rendering author and content and this is how it gets rendered. Now if you want to use React for this, then we will remove the code for rendering TR and TH and we'll replace it with call to react component. React component is a helper method which is provided by the gem. The first argument is what is the name of your component. So here I want to render post component. Then I can pass whatever props I want to pass. So as we are using Rails, it will take care of converting this active record object to JSON and pass it to React. By default, it renders everything into a due tag. So we can specify some HTML options. Like I want to render this in a TR tag because it is part of a table. And this is the output of that code. So we have data react class and we have data react props. All the JSON data of our props is there. Now next step is we write actually the component in JSX. So we write post.js.jsx and it gets that this.props.post we get the data because we passed it earlier. We passed it as a post. And then we render it normally like this.props.post.author and content. And we get the same output that we had earlier but this time using React. And this is how it actually looks if you check it in console that data react class and data react property is there. This is a, this was a simple example. If we want to pull new posts for after a certain amount of time instead of sending the post data directly we can send a URL. So here I'm sending which URL the client react can pull for new posts. And then we can set a time out that every five seconds fetch new post and render everything. I will go a little fast because I'm running out of time. So what it does is it pulls the post and renders the whole table again. This gem also syncs with asset pipeline. So it works beautifully with asset pipeline without coming into the way. You can specify certain variants like if you want to use development version or production version. I think it also allows to specify your own version. Your own version of reactors. This gem also allows server-side rendering. So you can pass option for pre-rendering, pre-render true. And it will evaluate the code on server-side and then send it back. So there are some issues with server-side rendering because you don't have access to the document, the document.body. So we can't use any JavaScript library like jQuery. We don't have access to that when the code is getting evaluated on server-side. Also, if you're using any dependencies like underscore.js or something, then you have to specify all the dependencies in your components.js file because React Rails uses these components.js file to load everything. And then your components must be in the global namespace. It also ships with the generator. So similar to how we generate models, controllers, we can generate a component. We just specify that I want content to be a string, count to be an integer. And it generates this tweet.js.js file. We get prop types for free. And we get like scaffolding. It is similar to scaffolding. Now, this is a new hot thing that came out recently, React Native. It is a framework for building native apps using React based on React. So you write similar components similar to this, but this time they will be specific for iOS or Android. Android is not there, but they're talking about releasing it soon. So the React philosophy is learn once and write two apps. So we are not going to write a single app which will work for iOS and Android. Instead, you learn React once and then you can write a separate iOS app and separate Android app. Now, if you think of a learning curve, whenever we are looking at a new technology, we have to also check how much time I have. Can I, is this really worth if I invest my time in it? And fortunately for React, just knowing JavaScript is enough because everything is JavaScript. There is no templating language. There is no extra thing that you have to know. And JavaScript plus JSX. But as I said, JSX is ultimately JavaScript. So if you know just JavaScript, it is enough. Other thing is, as it doesn't care about your existing stack, you can sneak into existing projects. Let's try React for some feature. Doesn't work out, then it's okay. We can go for something else. So try React. Let me know your experience, how you're using React. Or if you are already using React, let me know. That's it. We also have some React video series which you can check. We have a to-do app series, the second link. And the first link is for getting started with React. Thank you.