This article is part of a blog series in which we look at back at five years of React usage at Instana. State management is one of the essential aspects of React application architectures. Over the years, we certainly learned a lot about it. This blog post will provide insights into our current state management approaches. Let’s begin with a controversial point first: We don’t use Redux! Redux did not yet exist when we started Instana.
This article is part of a blog series in which we look at back at five years of React usage at Instana. Most of the early Instana employees moved to Instana from a German software consultancy called codecentric. These first employees experimented, used and trained customers in various UI libraries and frameworks while working for this consultancy. This background allowed us to have a broad understanding of the web development space and Zeitgeist.
This article marks the start of an article series in which we would like to look back at one of our earliest technology choices: The selection of React. React is being used since day one as our core UI library to develop Instana’s user interface. Since Instana recently celebrated its fifth birthday, we believe that this is an excellent opportunity to reflect on this architecture decision.
As many of you already know, we created Grafana using AngularJS, but we have been migrating to React for about two years now. One of the big missing pieces in our migration puzzle was the templating system. This post starts in late 2019 when I first got my hands on this mysterious and complex area of the Grafana code base.
ReactJS combines the speed of JavaScript with unique rendering capabilities to make applications that are highly dynamic, performance oriented, and responsive to user input. State of JS report 2018 cites performance as the major reason ReactJS has gained so much popularity in such a short time. When it comes to options for building single-page applications (SPAs), React delivers performance advantages over Angular and other JavaScript frameworks and libraries.
In our last post, we explored the pros and cons of Recompose and why we decided to remove it from our codebase. This post includes the strategy we used to approach the large task of implementing that refactor. It’s important to note that this strategy was created to fit our specific situation and is not a one size fits all approach to removing Recompose. Specifically, it was intended to work with our large codebase that is modified by our devs daily.
Recompose is a React utility belt for function components and higher-order components that has been very useful to our frontend engineering team. After more than three years of working with it, we’ve identified a lot of pain points. In October 2018, the React team introduced Hooks which shipped with React v16.8 and provided an alternative to HOCs.
One thing I love about working at OpsRamp is how we always come together to figure out new ways to manage complexity or achieve difficult development goals. Take, for example, managing application states. It’s historically one of the biggest challenges in front-end development. We’re a lean team, so we needed to figure out a better way. In this article, I’ll address how we accomplish this with React at OpsRamp, and how you can apply some of these practices in your own workday.
Debugging is the art of removing bugs — hopefully quickly, and in this guide, I’ll show you multiple ways to debug React. In terms of React, we can have many different kinds of bugs, including: There are more categories than this, but it’s enough to get started debugging in React. Let’s open by talking about how to create a small application using React and how to debug it.
