React for the Angular Dev
Apples and Oranges
When writing about Angular and React a lot of people try to compare them to each other; that’s like comparing apples to oranges. When diving into React, I quickly realized that React is more of a component library whereas Angular is more of an application framework.
What exactly does that mean? Angular comes with all the tools to build an entire application. Things like the router, animations, forms, http, localization, opinions, etc. React is JUST a component library. When you install React you are only getting a component rendering system. Of course you can’t build a true web application with only a widget library.
This is kind of a double edged sword, when you provide all those tools out of the box it really discourages the community to innovate and come up with their own unique systems but if you provide them it makes a really nice developer experience where you can find all the docs in one spot, ensure all your dependencies stay in line with each other and make it easier to hire devs with experience using the same tools.
If I’m completely honest with myself, this was one of the major things I hinged my hesitation on using React to. My experience is building serious web applications, and having to hunt down all the tools to make them is not what I want to spend my time doing. The truth though, is this is not as big of deal as I thought it would be. There are a handful of front runners that have came out with some really innovative solutions to these problems. They are highly active due to the popularity of them and stay in sync with the major versions. A few notable ones I’m using include:
- Router — react-router — https://github.com/ReactTraining/react-router
- Animations — react-transition-group — https://github.com/reactjs/react-transition-group
- CSS Classname Conditionals — classnames — https://github.com/JedWatson/classnames
- Forms — formik — https://github.com/jaredpalmer/formik
- GraphQL — react-apollo — https://github.com/apollographql/react-apollo
- Testing — jest — https://jestjs.io/
- CLI — create-react-app — https://github.com/facebook/create-react-app
That handles all the major things you need to build a web application these days.
Opinions — Everyones got one
One thing I noticed when I was getting into React is that there is no real style guide for how to organize, structure and format your code. This was really bizarre to me in contrast to Angular, where it was pretty letter-for-letter how to write your code. I did a bit of research and found this tweet by Dan:
When you open the link, it reads:
move files around until it feels right
OK — thats an interesting thought. We could kind of start to see this divergence in the Angular community with the rise of tools like NX that segmented everything into a mono-repo. After doing some research, here are some observations I made:
- Name the file similar to what it exports. For example, if you have a class like
ToggleButtonyour filename would be:
- Make main components/fns that are exported the default export. Personally I hate this, it makes it ambiguous what to name the file. I stuck with named exports.
- Make index.js export those default exports for the ‘module’. I’m not a fan of this either, it makes searching for components via file system REALLY hard.
- The same file structure we use in Angular, actually works really well for large React apps too ( /app, /core, /shared ).
Everything is a component
In React, everything is a component. I mean EVERYTHING. If you look at tools like React-Router you will see you even define your routes as components.
When those items are composed in objects, it becomes tricky to determine what changed; we’ve side-stepped the problem by making everything immutable but that only solves the diff, how do we know when to check the diff?
If those configuration items are composed using components, we can use the same state tree we use for views to describe our configuration. This allows us to easily hook into the change detection system and participate in all the lifecycle and update processes.
Angular took a different approach to this problem by using Observables via RXJS. Under the hood in Angular almost everything is an observable and the system subscribes to those observables to know when/what to do. Observables are somewhat of a double edge sword too. They are really awesome in some cases and really suck in others. For instance, in order to get values out of an observable you have to subscribe to it. That makes perfect sense except when you get into complicated flows, then you suddenly need to be a RXJS operator expert. This becomes so complicated so quickly that there was a parody presented on it at ngconf 2018.
What do I miss?
When I tell people I’ve been working on React, one of the first questions I get is do you miss it? What do you miss? Here is my breakdown…
- Community — I’m still fairly involved in the Angular community and continue to be active in open-source and on podcasts like AngularAir but I’m not as involved as I used to be. The number one thing I miss not having as much, is the community. The friendships I’ve made in the Angular community are something that will last a lifetime and have helped me become the dev I am today.
- Directives — There is no concept of directives in React. Everything is a component. When you want to enhance a component you can use techniques like HOC (or higher-order-components) but this isn’t always as clean and can end up with some complicated code.
- Style guide — Above I touched on the opinions and how people do things. I do miss some of the opinions that came with Angular. Often it comes down to debates between the team and how to do what, and it’s just easier if there is a standard way of doing things.
- CLI — React has CRA (create-react-app) but I’ve found it to be a bit limited and until recently it didn’t support things like CSS modules, TypeScript, etc. I ended up ejecting from it. The Angular CLI has always been really strong and easy to use.
- CDK — The Angular CDK (component developer kit) is probably one of the best, least known tools in Angular. The CDK is a low-level framework for creating components. This framework powers the Angular Material component library. When building components of your own, it’s insanely easy to pick up this library and get all the ‘hard stuff’ like virtual scrolling, portals, a11y, drag and drop, etc.
What do I NOT miss?
The second question I’m asked after “what do I miss”, is “what do I not miss?” Here is my breakdown of that…
- ZoneJS — There is a chance you don’t even know what this is but if you do then you will probably agree with me here. ZoneJS is the way in which Angular detects changes. It basically monkey-patches many of the browser APIs to detect when something was interacted with and where to capture and run CD on those components. To be completely frank, it was a cool idea that turned out to be a nightmare. The good news is this is slated to go away but not soon enough!
- NgModules- Ever since these came in right before 2.0, I’ve never been a fan. I realize they are probably a necessary evil given complicated dependency relationships and they help enable better static code analysis, but I digress.
I know the Angular team recognizes all these issues and are actively working on improving them, so hold tight!
Both libraries are iterating and evolving at an incredible pace. People reading this article in 6 months will probably not even relate to some of these problems. It’s been a fun adventure getting to try something new and get out of my comfort zone, I hope this can encourage you to do the same!