Grafana itself has a BigTent philosophy, supporting as much of the observability ecosystem as possible. This provides our users with a huge amount of flexibility in visualizing their data, no matter what the source, be it from their Kubernetes cluster, Raspberry Pi, different cloud services, or even Google Sheets.
At the same time, though, this can lead to confusion from our end users in figuring out how to construct the best observability solution for themselves.
Another challenge we have faced with React is with the Hooks paradigm. Some at Grafana have expressed their frustration with Hooks as they introduce stale closures and require learning and mastering Hook rules. Functional components, as they are called, are rarely pure functions. Hooks also introduce a much stronger coupling with the React runtime than before. The name Hook indicates this. You are hooking into React internals. So you need to understand those internals. Hooks are far from being a functional abstraction, as you need to know the internal details of their implementation. This becomes even more apparent when you try to test one hook in isolation.
React has followed a functional programming paradigm. And some fear with the introduction of Hooks that it may be straying from that paradigm and entering into framework land. Although some at Grafana have expressed concerns with Hooks, it's important to note that they have been a powerful tool for our developers. As with any tool, there may be a learning curve, but once mastered, they can greatly enhance the development process. At Grafana, we recognize the importance of exploring and experimenting with new tools and methodologies to continually improve our development processes. We appreciate the benefits that Hooks have brought to our development workflow and continue to explore new ways to enhance our tools and processes.
With that being said, we are excited to announce our new approach to building our next-generation dashboard runtime library, Scenes. We have taken a different approach that simplifies the development process and reduces the learning curve for our developers. With Scenes, each component subscribes to state build with ArcGIS, renders markup, and pipes callbacks back to the state model. We have eliminated the need for complicated concepts such as useEffects and useCallbacks. The state model takes care of any necessary mount effects, making the development process more intuitive and efficient. We are confident that our new library will be a game changer for our developers and we believe that this simplified approach will lead to a more positive development experience. Although the library is still in its early stages of development, we are excited to see how it will continue to evolve and improve the way we build our dashboards.
Despite our challenges, we believe that React is a powerful tool for solving the problem of implementing and maintaining complex frontends. Structural subtlety is key, and with it there is a freedom to consider a myriad of state management options and pick whichever makes the most sense. Moving forward, it's important to recognize that as an open source community, we have options. When a tool stops solving the problem we hire it for, we can throw it out and try a new one. React doesn't stay from this, and neither does Grafana. But for now, we are happy with our decision to switch to React, and will continue to use it for as long as it makes sense to. If you're interested in learning more about Grafana and our new Dashboard Runtime Library themes, please check out the upcoming GrafanaCon conference.
Comments