Angular 12 goes all-in on Ivy
Enterprise apps clinging to whatever innovation they can get
There’s a lot to unpack from last week’s Angular 12 release, the biggest being the framework’s new “Ivy-everywhere” approach — a phrase which conjures some unpleasant (and very itchy) memories of hikes at Boy Scout camp that went terribly wrong.
Wtf is Ivy? It’s Angular’s default rendering & compilation pipeline that has slowly been replacing View Engine (the legacy pipeline) over the last year.
Ivy has better code completions, error reporting, hints, and notifications inside Angular templates. Deprecating View Engine should make Angular simpler, faster, and easier to use & maintain.
What else is new in v12:
There’s also new Webpack 5 support, inline Sass, and inline critical CSS.
The Bottom Line
It’s easy for
But then they come out with this big v12 release, they brag about their npm downloads growing from 1.6m in 2019 to 2.4m in 2020, RxJS releases a big update, and it seems like Angular’s back on the come-up.
A (probably too long for this Newsletter) Introduction to Recoil
Created from a team at Facebook, Recoil is an “experimental set of utilities for state management in React”.
Per usual, before we dive into the code let’s look at why Recoil was created and what problems it attempts to solve.
There’s an internal tool at Facebook called “Comparison View”. It’s a “data analysis app for performance data”. That’s a fancy way of saying it’s an app that lets you analyze performance data across Facebook. As you can imagine, it’s rather complex. What they found was that for their use cases, both React component state and Redux didn’t work well. They kept hitting performance and flexibility limits. I think it’s safe to assume this wasn’t just a “they don’t know what they’re doing” thing.
Recoil was created to solve these problems. Specifically, flexible shared state and derived data and queries.
Flexible shared state
Performant, synchronized, shared state across any React component that needs it in your component tree.
Derived data and queries
The ability to (re)compute values (performantly and efficiently) whenever any of the state in your application changes.
What I like about Recoil is its simplicity. Whenever I’d work with Redux, the mental model always felt completely different than React’s. Almost like there was context switching costs moving between “React code” and “Redux code”. With Recoil, though not completely aligned, it’s much closer.
atoms are changeable, subscribable, units of state. Any React component that subscribes to an atom will receive the new, updated value whenever the atom changes. Whenever an atom changes, only the React components that subscribe to that atom will be updated.
You create a new atom by invoking
Now, any component that needs access to the
Like most React libraries, we need to wrap our app with a provider component so Recoil can use context to pass state anywhere in our component tree. For Recoil, this provider component is named
At this point we know the syntax for the absolute basics of Recoil – creating an atom and then subscribing and updating it from inside of a component.
If you’ll remember back to the goals of Recoil, they were “flexible shared state and derived data and queries.” We now know how to add “flexible shared state” to our application using
One of the core foundations of functional programming is the concept of pure functions. Pure functions maximize the predictability of your program. A function is “pure” if it meets the following criteria:
When you call a function that is “pure”, you can predict exactly what’s going to happen based on its input.
The way Recoil solves “derived data and queries” is by leveraging pure functions which can derive a new value from existing atoms’ state. The term for how they do this is called a “selector”.
Again, to get a soft introduction to the syntax, we’ll use a contrived example. Let’s say we wanted to, using our previous
Notice that we pass
Instead of using the
What I love about selectors is you get rid of the ceremony around syncing state. Instead, you can, in a very predictable manner, abstract that complexity to its own selector. Even better, the selector will only recompute whenever one of the values it depends on changes. This also means that any React components that depend on a particular selector will only re-render if one of the values the selector depends on changes as well.
Our counter example has proven effective in giving us a solid understanding of the Recoil syntax, however, it comes up short when it comes to practicality.
One fundamental aspect of building any application is the ability to fetch asynchronous data. Here’s another thing that’s rad about selectors – they can be asynchronous. The mental model still works the same. Instead of deriving values locally, you have the ability to derive values asynchronously from a server. Under the hood, Recoil still models this as a pure function. If the selector has the same inputs, it will always give you the same outputs (by utilizing cache).
To do this, you just return a
Should you use Recoil?
Naturally, it depends. Here’s the mental checklist I’ll go through from now on when deciding between component state, context, Redux, and Recoil.
What I never liked about Redux is it felt like it was all or nothing, Redux vs React. There’s so much ceremony in setting up the store, actions, reducers, etc. that by the time you were done, you might as well just put everything in Redux regardless of best practices. With Recoil, it’s the opposite. You can simply abstract shared state amongst different atoms/selectors and then sprinkle them in while your React code stays almost exactly the same.
As someone who has always been a Redux sympathizer (“it’s great if you use it for the right problem” was my mantra), I didn’t expect to love Recoil as much as I do. I also didn’t expect to throw out Redux completely, but here we are.
Delivered to 114,267 developers every Monday
This is the first ever newsletter that I open a music playlist for and maximize my browser window just to read it in peace. Kudos to @uidotdev for great weekly content.
The Bytes newsletter is a work of art! It’s the only dev newsletter I’m subscribed too. They somehow take semi boring stuff and infuse it with just the right amount of comedy to make you chuckle.
Bytes has been my favorite newsletter since its inception. It’s my favorite thing I look forward to on Mondays. Goes great with a hot cup of coffee!
I subscribe to A LOT of dev (especially JS/TS/Node) newsletters and Bytes by @uidotdev is always such a welcomed, enjoyable change of pace to most (funny, lighthearted, etc) but still comprehensive/useful.
Literally the only newsletter I’m waiting for every week.
Bytes is the developer newsletter I most look forward to each week. Great balance of content and context! Thanks @uidotdev.
The sense of humor and structure of the Bytes Newsletter is first class and the information that comes with it is enough to make a mini course.
Very few newsletters manage to be useful and not very boring. @uidotdev manages to achieve these pretty effortlessly. You can almost see Tyler chuckle as he writes them.