Observables, Reactive Programming, and Regret
Observable in RxJs is a very popular primitive to use in state-based JavaScript applications. The RxJS framework makes use of Observable as a mechanism to provide a structured cycle for state changes. The Observable pattern offers a standard structure for messages, resource clean-up, and a consistent API. Ben Lesh wrote an honest assessment of how the JavaScript community at large uses RxJS and Observable in incorrect ways. RxJS is a library of functions built around observables, not the other way around. Ben points out there are cases where merely using the Observable is the correct architecture choice.
At the same time, many JavaScript developers learned to use Observable while learning RxJS. JavaScript developers often conflate the two assuming Observable and RxJS are the same thing. Software developers overly complicate their software when they overengineer their code by using RxJS when a simple Observable would do.
Ben also points out that the RxJS framework has an extensive API surface area because the RxJS team has prioritized backward compatibility. This priority brings a duty to continue to support features from previous versions. Were RxJS to be built from scratch, the RxJS team could offer a more straightforward API. The large install and user base complicate that decision.
In this article, I can see a broader technological cycle at work.
- A developer finds an exciting and useful technology. (Let’s call it HammerJS)
- The developer uses the technology as intended (to hammer Nails)
- Then the developer sees nails everywhere and starts to mistake screws for nails.
- After the developer has pounded many screws with the HammerJS and realizes they’ve made a big mess, the developer does the only reasonable thing – blames HammerJS.
- In a fit of rage, the developer fires off a stream of social media messages and blog posts maligning HammerJS, the HammerJS maintainers, and all HammerJS users.
- The developer refactors their code to use the new and shiny Mallet JS framework and is happy once again.
Ben is pretty clear on how he could have done a better job clarifying the separation of Observable and RxJS, thereby influencing the community in the proper architectural choice. I admire Ben for taking responsibility for this misconception and making a public statement to help the JavaScript community better understand the correct architectural decisions and tradeoffs between Observable and RxJS. Ben has “”donated”” an incredible amount of time and energy to provide the JavaScript community with better tools and practices. He’s been a tireless advocate and helper for many. Ben is a very influential person in the JavaScript community and has the street-cred to make a difference in this case; the JavaScript community will be better off for it.
At the same time, I hope amidst the very generous backdrop of Ben’s article, the point does not get lost about the individual software developer’s responsibilities.
The software developer has a responsibility to learn their craft and make the best decisions. The software developer must seek an understanding of the tools, frameworks, and architectural patterns in use. All choices involve a tradeoff of something, be it time, materials, resources, flexibility, security, etcetera. The software developer who blindly follows patterns without understanding them is doing a disservice to their coworkers, employers, and users.
Use the React Profiler for Performance
Building React JavaScript applications that have appropriate performance requires paying attention to the consumption of resources. Inside a React-based application are many components, dependencies, and files that consume resources. Web browsers consume physical resources to turn source code into interactive applications. If the resources consumed are appropriate, the user will have a pleasant experience using the application. If the application consumes too many resources or floods a bottleneck, the user will have a poor application experience.
A frame rate of 60 frames per second is the accepted benchmark for a smooth user experience. At 60 frames per second, each frame is 16.7 milliseconds. For frames to process on time, the runtime needs to be free to switch contexts. If an application work unit consumes more than 16 milliseconds, the runtime will not be able to process a new frame on time. The quality of the user experience decreases as the frame rate decreases.
It isn’t easy to diagnose the causes of poor performance at runtime. Application complexity creates diagnostic complexity. Fortunately, good tooling exists for profiling React applications.
Ekwuno Obinna wrote an excellent guide to use the React Profiler for Performance. It’s been almost 2 years since the article was published, and developers continue to use this guide to get up to speed with profiling. This article is one you should bookmark, so it’ll be handy when you need it.
React-Redux Flow: Detailed Guide
Software developers need a foundational understanding of the relationship between state and components. A developer familiar with React and the software development principles behind effective React programming will understand the concept of state immutability. For developers more familiar with imperative programming, the nuances of state immutability will create friction and inefficiency.
Michgolden Ukeje wrote a detailed article with excellent code samples that walks you through the main ideas in state with React and Redux. Reading this article is a good idea even if you are comfortable with the concepts because there are nuances in the React and Redux flow that must be appreciated.
The main idea is to use a single, centralized store for state, have your application throw up events for the system to listen for, and use the reducer capabilities to return the new state. In the second half of the article, Michgolden walks you through each step of building an ideal representation of this flow. Bonus points to him for mentioning the Intelligent Investor as one of the examples.
Demystifying React Hooks: useReducer
React hooks help encapsulate business logic into functional components. The React library provides several hooks you can use in your application. Each hook is intended for a specific purpose. React developers often misunderstand the meaning of individual hooks, overusing some, and not using others.
Milu wrote a 4 part series covering useCallback, useMemo, useRef, useContext, and useReducer. Milu straightforwardly explains each hook. She also discusses helpful cases where you may or may not want to use one of the hooks. Her writing style is clear, and the descriptions have helped many React Developers become comfortable with each hook.
React At Scale, Monorepos, And How Etsy Gets It Done
Interviewing Salem Hilal was a lot of fun. He is a software developer at Etsy and works on the automation side of the house. Salem wrote an article a few months ago we liked enough to feature in the React Enterprise newsletter. We had an opportunity to bring him onto our React Wednesday show and discuss how Etsy uses React, monorepo strategies, and their open-source project Kevin – middleware for Webpack.
We had a tremendous response from the React community about this interview – our most popular subject to date.
I structured the article so that the concepts discussed in the interview are subheadings. To make it easy to hop around in the video, I added time codes to specific parts. You’ll find the information presented is and useful for your daily work. Etsy is doing a lot of things right, both on the technology and the human side. I gained a newfound respect for their organization and hope you do too.
9 Examples of building your own version of React
Iain Freestone collected nine different versions of “Build React From Scratch” tutorials. The tutorials are as concise as “”in 33 lines””. One would be correct by stating React is more than just what a software developer can build in 33 lines. That said, there’s value in simplicity.
Much of writing modern, complex applications with React spans beyond the capability of the React library. React itself claims to be a library leaving plenty of room for software developers to use other libraries for additional functionality. This confluence of libraries can confuse software developers. You will learn more about the React library and its purpose by following along with one of these tutorials.
Introducing React Spectrum
Adobe is a world leader in design, and design tooling. Recently Adobe have released React Spectrum to help companies build out their own design systems with modern functionality. A design system is necessary to guide the development, support, and use of a component library. As organizations build their design systems, they must invest in features like accessibility, internationalization, full keyboard navigation, and touch interactions. A goal of Adobe React Spectrum is to provide a footing encompassing these important features so React Spectrum users can build better quality apps for less investment.
React Spectrum is a newly released, end-to-end React component library formed around Adobe’s design system called Spectrum. React Spectrum contains a library of React Hooks that provides accessible UI primitives for your design system – called React Aria. React Spectrum contains a React Hooks library for cross-platform state management and core logic for your design system – called React Stately. React Aria and React Stately are combined with a component set containing 40 components spanning Layout, Navigation, Status, Content, Forms, and other categories.
Having a fully featured component set authored and supported by a world leader in design means you can use the best, most practical ideas to build applications your users will love.
