Recently I decided to migrate one of my side projects to React. I had several reasons for that, but the most important is that, obviously, Angular 1 is old, and nobody cares about it anymore. No community, no bugfixes, no improvements. It is basically dead.<\/p>\n
So I decided to give React a go. And you know what? I was blown away by how easy it was to rewrite my whole application from Angular 1 to React. It took just a couple of weekends, impressive given that my application is rather complex with several dozen related and interdependent components.<\/p>\n
In this article, I\u2019m going to share my impressions and will describe the transition I had to undergo to think in React.<\/p>\n
Here\u2019s the TL;DR:<\/p>\n
Usually, people say that React is simple because it\u2019s just a rendering library, which is true (one can easily walk through the entire documentation<\/a> in several hours), but that doesn\u2019t mean it\u2019s easy to create a new project with it. And that\u2019s because React itself is not sufficient for a complete application. You will need to learn things outside the React library but within the React ecosystem.<\/p>\n As soon as you start making React applications, your first questions will probably be:<\/p>\n There are of course multiple answers to all those questions. But you need to understand that React won\u2019t answer them. Those are the decisions you\u2019re going to have to make on your own.<\/p>\n After moving from Angular 1 to React, the next thing you\u2019ll notice is that you have to write more code. In my experience, it\u2019s around two times more typing. It\u2019s frustrating, but after some time you get used to it. In general, there\u2019s a tradeoff between verboseness and clarity \u2014 React is more verbose, but as an upside, the code is more readable.<\/p>\n In practice, however, I would say, it\u2019s perfectly possible to write readable and maintainable Angular 1 code just as, vice versa, it\u2019s possible to write terrible and convoluted React code. So I guess it boils down to your personal style.<\/p>\n React concepts that increase verboseness are JSX and one-way data flow, but we\u2019ll talk more on those later.<\/p>\n Every time you learn a new framework, there\u2019s an overhead of what you need to learn. Those are things that lie in your brain and make you productive within a particular framework but are useless when you switch to another thing. React is more down-to-earth than anything else I\u2019ve used before. Whatever you do, just write JavaScript, even when you write templates. But more on this in the next part.<\/p>\n When people encounter JSX<\/a>, they often complain about violation of separation concern. You write JavaScript code and HTML-like markup in the same file, and that scares people off. In reality, though, it\u2019s not a violation if you put them in one file. It\u2019s a violation when you mix up logic with a view, but that\u2019s totally avoidable.<\/p>\n Constructions like We do the same thing in Angular with This one was a game changer for me.<\/p>\n On the negative side of things, it\u2019s good to understand that JSX is not exactly HTML + JavaScript. There\u2019s still stuff that is React-specific; for example, you have to write all the properties in camel case, and you can\u2019t use Oh, and you also can\u2019t use strings for styles. Instead you write something like this: Okay, moving forward to one of React\u2019s key selling points: the data flow. In React, it always goes from the parent to children. What if a child component needs to update the state? In that case, it should communicate to its parent via a callback. The parent will update the state, and so the data will pass down to the child again, causing the rerender (the virtual one).<\/p>\n In practice, this does lead to a more understandable stream-lined data flow. As a downside, you again have to tolerate the mental overhead. Imagine you have a tree of components, and something changed at the very bottom of that tree. To propagate the change to the top components, you have to pass a callback all the way down through all the levels of the tree. It is cumbersome, but state managers like Mobx<\/a> or Redux<\/a> help to deal with that. However, they can add more overhead.<\/p>\n So I couldn\u2019t avoid this aspect. I still think that classes are weird out-of-the-place creatures that shouldn\u2019t have made it to JavaScript. I imagine they were introduced to make Java folks feel at home. Underneath, nothing changed \u2014 that\u2019s still a good old prototype-based inheritance. Class-based programming in JavaScript is complex, hard, and convoluted. As opposed to functional programming, that may be a bit wordy first, but in the end, it scales so much better. Even in React docs they warn against using inheritance<\/a> with classes.<\/p>\n But well, whatever I say, you can\u2019t change the fact that React API use classes. If you\u2019re using a stateless component, you should use a pure function. Whereas if you have state, you need to use classes instead. And as a React developer, your job is to try to localize the state, which means using pure stateless components (functions) as much as possible and use clauses as little as possible.<\/p>\n To dive deeper into that topic, read this writeup<\/a> by Dan Abramov.<\/p>\n Now on to the fun part. Let\u2019s see several examples of how you might migrate an Angular 1 component to React.<\/p>\n Let\u2019s assume we have a component that displays a single user\u2019s info. In Angular 1, it could look something like this:<\/p>\n Note that nasty Rewriting it in React turns out to be really easy; all you have to do is to create a pure function. That function accepts properties and returns a JSX markup that needs be rendered.<\/p>\n Note that:<\/p>\n Now let\u2019s see how would you implement an address book component (to display a single user, we\u2019ll reuse a component from the previous section).<\/p>\n Angular 1:<\/strong><\/p>\n We\u2019re not interested in how React:<\/strong><\/p>\n Note that:<\/p>\n Let\u2019s have some fun now. Suppose that for every contact we have an editable field, say, a phone number. In Angular, we will use Nothing else is changed. Since we have a 2-way binding, when we change the phone, it automatically propagates to the parent array of users, and that\u2019s it. With React though, we need to implement the propagation ourselves.<\/p>\n Note that:<\/p>\n What you have just read is a subjective opinion and more like my personal notes about the experience I had. Yours might be very different, so feel free to share it with me.<\/p>\n And let\u2019s draw a line here:<\/p>\n\n
Verboseness<\/h3>\n
React is more JavaScript-ish<\/h3>\n
JSX<\/h3>\n
if<\/code> and for<\/code> within your markup have nothing to do with separation of concerns.<\/p>\nng-if<\/code> and ng-each<\/code>. But in React, the code is not artificial \u2014 that\u2019s just markup + JavaScript. Since it\u2019s a superset of JavaScript, it\u2019s perfectly lintable, so you will know you\u2019re missing a method at the linting time. In the case of Angular, it will silently fail even at runtime (because templates in Angular are just strings).<\/p>\nclass<\/code>. Instead, you have to write className<\/code>.<\/p>\nstyle={{ marginTop: '5px' }}<\/code>. All this means you can\u2019t just take a piece of your HTML markup and use it as React template \u2014 you still need to adjust.<\/p>\nOne-way data flow<\/h3>\n
Classes<\/h3>\n
class<\/code> is just syntactic sugar that attempts to hide the nature of the JavaScript, and it fails to do that.<\/p>\nReal-world Examples<\/h2>\n
Stateless component<\/h3>\n
const TMPLT = `\r\n<div class=\"item clearfix\">\r\n <div class=\"ava\">\r\n <img ng-src=\"{{user.avatar}}\" \/>\r\n <\/div>\r\n <div>\r\n <div class=\"name\">\r\n <a href=\"\/users\/{{user.id}}\/\">{{ user.name }}<\/a>\r\n <\/div>\r\n <div class=\"phone\"> {{ user.phone }} <\/div>\r\n <\/div>\r\n<\/div>\r\n`;\r\nexport default function() {\r\n return {\r\n restrict: 'E',\r\n scope: {\r\n user: '='\r\n },\r\n template: TMPL\r\n }\r\n}<\/pre>\nuser: '='<\/code> thing. That\u2019s a two-way data-binding, meaning you can change it in the component and it will change in the parent as well, and vice versa. That\u2019s something you can\u2019t have in React.<\/p>\nexport default function({ user: { name, phone, avatar } }) {\r\n return (\r\n <div className=\"item clearfix\">\r\n <div className=\"ava pull-left\">\r\n <img src={avatar} \/>\r\n <\/div>\r\n <div className=\"name pull-right\">\r\n <div className=\"name\">\r\n <a href={`\/users\/${user.id}`}>{ name }<\/a>\r\n <\/div>\r\n <div className=\"phone\">{ phone } <\/div>\r\n <\/div>\r\n <\/div>\r\n )\r\n}<\/pre>\n\n
ng-src<\/code>) and added some React-specific ones (className<\/code>).<\/li>\n{}<\/code> is just a JavaScript code, not some artificial mini-language.<\/li>\nIntroducing state<\/h3>\n
const TMPL = `\r\n <div class=\"address-book\">\r\n <user user=\"u\" ng-for=\"u in users\"><\/user>\r\n <\/div>\r\n`\r\n\r\nexport default function() {\r\n return {\r\n restrict: 'E',\r\n scope: { },\r\n template: TMPL,\r\n link\r\n }\r\n\r\n function link($scope) {\r\n fetchUsers().then((users) => {\r\n $scope.users = users;\r\n })\r\n }\r\n}<\/pre>\nfetchUsers<\/code> might be implemented, but in the case of Angular, you\u2019d probably use a $http<\/code> service to send AJAX request, since it\u2019s part of the API.<\/p>\nclass AddressBook {\r\n constructor(props) {\r\n super(props) \/\/ always invoke super\r\n this.state = {\r\n users: [] \/\/ default state\r\n }\r\n }\r\n\r\n componentDidMount() {\r\n \/\/ gets invoked after component \r\n fetchUsers().then((users) => {\r\n this.setState({ users })\r\n })\r\n }\r\n\r\n render() {\r\n const { users } = this.state\r\n return (\r\n <div class=\"address-book\">\r\n {\r\n users.map(u => <user user={u}><\/user>)\r\n }\r\n <\/div>\r\n )\r\n }\r\n}<\/pre>\n\n
componentDidMount<\/code> method, which is a lifecycle hook<\/a>, and it\u2019s being invoked after component rendered into the DOM.<\/li>\nng-for<\/code>, we\u2019re now using a plain JavaScript to render a list, which is very nice.<\/li>\nsetState<\/code> method. Otherwise React will never know that the state has changed and it needs to rerender.<\/li>\n<\/ul>\nPropagating the state<\/h3>\n
ng-model<\/code> for that.<\/p>\nconst TMPLT = `\r\n<div class=\"item clearfix\">\r\n <div class=\"ava\">\r\n <img ng-src=\"{{user.avatar}}\" \/>\r\n <\/div>\r\n <div>\r\n <div class=\"name\">\r\n <a href=\"\/users\/{{user.id}}\/\">{{ user.name }}<\/a>\r\n <\/div>\r\n <div class=\"phone\">\r\n <input type=\"text\" ng-model=\"user.phone\" \/>\r\n <\/div>\r\n <\/div>\r\n<\/div><\/pre>\nexport default function({ user: { id, name, phone, avatar } }, onChange) {\r\n return (\r\n <div className=\"item clearfix\">\r\n <div className=\"ava pull-left\">\r\n <img src={avatar} \/>\r\n <\/div>\r\n <div className=\"pull-right\">\r\n <div className=\"name\">\r\n <a href={`\/users\/${id}`}>{ name }<\/a>\r\n <\/div>\r\n <div className=\"phone\">\r\n <input type=\"text\"\r\n value={phone}\r\n onChange={changed}\r\n \/>\r\n <\/div>\r\n <\/div>\r\n <\/div>\r\n )\r\n\r\n function changed({ target: { value } }) {\r\n onChange({ id, name, avatar, phone: value })\r\n }\r\n}<\/pre>\n\n
input<\/code> and the inner state of the application.<\/li>\nConclusion<\/h2>\n
\n