React Components Simplify Testing
In some ways, back end developers have it much easier. A single runtime, much more deterministic testing, less dependence on those pesky users clicking around randomly, and so on. Testing the front end requires a bit more coverage. One needs unit tests, functional tests, and all these tests need to run across all viable platforms and possibly platform versions.
The architecture of React leads one to build components that are encapsulated from outside side effects. Each component only knows what it knows. Thus, setting up a test requires only these things, not a great deal of overhead, ceremony, or other required dependencies each in turn could cause a side effect.
Swizec Teller wrote up his thoughts on how React makes testing easier than with other frameworks. His post should help those who are more familiar with front-end testing in other ecosystems see how much more straightforward it is in the React ecosystem. He also covers both Karma and Jest.
Main Thread Scheduling Magic
Running the entire front-end on a single thread means you don’t have to deal with the super-fun realm of multithreaded environments. This also means it is very easy to shoot yourself in the foot by blocking the main thread with some work. 60 frames per second is generally considered smooth, jank-free animation. This rate allows each frame to be about 16 milliseconds. Not a lot of time in today’s dynamic interfaces, is it?
The Chrome team has been working on a Main Thread Scheduler API that will help improve utilization of the main thread and avoid blocking. The idea is you’ll break up with using a scheduler like React Scheduler, and then it’ll talk with the Chrome Main Thread APIs to manage the interactions. All the fun of multi-threading, none of the pain.
The Main Scheduler API is in experimental status. Learn about the Chrome Main Scheduler API and how to enable it in this blog post by Matan Borenkraout.
React Native for macOS?
What if you could use React Native to write MacOS apps? What about using React Native for Windows desktop apps? You’d be able to stick with React Native, and React, for really any significant platform around. Plus, you could dump Electron and save on both computing resources and additional developer skill types.
The team at Microsoft have been working on enabling both MacOS and Windows desktop platforms. Windows is in preview status now. MacOS is coming soon.
Video playback in React
There is more to playing video on the web than just using the generic YouTube Embed code. You might need a different player for content you want to control access to, or even control the user experience for. There are several main ways to handle video playback in JavaScript. Common methods are Microsoft Smooth Streaming (MSS), HTTP Live Streaming (HLS), and DASH. Here at Digital Primates we are partial to DASH and have been involved with both DASH.js and Video.js for many years.
Recently, on the LogRocket blog, Jaime Maison wrote a post explaining video playback options with React. He discusses video playback basics, common open source libraries, and also players you can use in React. If you are curious about how to go beyond the YouTube embed, this one is for you.
Sync Your React App with the System Color Scheme
Light and Dark themes are all the rage. Those with a preferred theme style really like it when an app automatically detects their preference and adjusts. It turns out it isn’t so hard to make your React app detect the user preference. Glad Chinda wrote up how to detect and use the System Color Theme in your React app.
React Rendering Behavior
Rendering is such an important part of the React app cycle that you really need to make sure you deeply understand it. You can find lots of information about React rendering across the web. It can be hard to get an overall picture of how it works because of this informational fragmentation. Thankfully, Mark Erikson took the time to collate this information and organize it in an easy to digest manner understatedly titled A (Mostly) Complete Guide to React Rendering Behavior.
Should you build or buy a UI library?
Build versus buy is a common decision one must make. Too much “we must build” and you never get anything built. Too much “we must buy” and you have a hard time handling the specific requirements and complexity of the problem you are solving. User interface components are one of those areas where it may make more sense to buy versus build.
The browser vendors haven’t added a major control to the browser in 20 years. The selectbox has been basically static. There still isn’t an in-built date picker, nor a searchable grid. The browsers aren’t going to save you.
One approach is to grab controls from npm or other sources. While this can result in you having exactly what you need, it also can look like a patchwork quilt of visual controls. Are we helping our users by having controls that don’t act the same or behave the same?
Not to mention, there is a danger of having a patchwork quilt of intellectual property. Some companies are more sensitive to intellectual property rights than others.
There are several component vendors on the market that offer a full catalog of user interface components. We at Digital Primates use KendoReact for one of our Enterprise clients. This app has thousands of screens and would be much harder to work with if there was no consistency in user interface controls. The right answer for your project depends on the specific elements. But successfully implementing a component library like KendoReact solves a whole swath of problems for you and lets you focus more on what makes your app special, and less on trying to integrate disparate controls from disparate sources, all with their own conventions, release cycles, and standards. Using full-featured and supported Grids, Charts, Schedulers, and other components can make the difference between an OK app, and an amazing app your users thank you for.
The makers of KendoReact, Telerik wrote up 8 Key Factors When Deciding Between Building In-House and Buying a UI Component Library. Give it a read and see what you think.
