React migration & an experiment with less DI


Two updates for those who follow our frontend development:

React Support/Migration

It’s long overdue that we migrate from Angular 1. Yet an actual migration was never prioritized, because it doesn’t directly benefit the end user so we preferred to focus on things that actually benefit the user.

But opportunity presented itself, when the good folks from Mozilla decided to experiment with migration Redash from Angular to React. While personally, for a new project, I wouldn’t necessarily pick React (but rather Vue), for an existing code base React presented the following advantages:

  • it had a clearer path to doing a gradual migration using the angular2react library (and later the react2angular one).
  • Both the team at Mozilla and other contributors have past experience with React.

Now that #2546 is merged we have a hybrid code base, where we can introduce React component into our code. We will start with gradually rewriting existing components and writing new code with React.

Experiment with removing dependency on Angular’s DI

The introduction of ES modules and import made the DI redundant, yet we kept using it because that’s how things work in Angular. Somewhat related to the React migration (and to improve the developer experience), I did a small experiment of reducing the use of Angular’s DI in our code.

The getTags function, which uses $http, imports it from @/services/http:

import { $http } from '@/services/http';

/* ... more code ...*/

export function getTags(url) {
  return $http.get(url).then(response => processTags(;

services/http.js is very simple:

// eslint-disable-next-line import/no-mutable-exports
export let $http = null;

export default function register(ngModule) {$injector) => {
    $http = $injector.get('$http');

It basically sets the value $http using Angular’s $injector during the application bootstrap process. I wouldn’t “abuse” this workaround, but we should use it for things like $http that we will later replace with a general library like axios (or whatever is standard these days).

(We should be a little careful here, because $http is only available post the bootstrap process.)


Wow. This is cool and brave at the same time. Do you think the project be moving toward plotly-react in the future to render charts?

If so, it looks like redash would assemble the props as JSON and feed them to the React component. That looks straightforward, though managing state for a dashboard would need work…

Thanks for Redash,


Wait! I am having galaxy brain right now - you guys were Redash before plotly created Dash…
Again it looks like moving to React could get you a lot more Plotly interop in your app, both the js and the python side. Exciting!


Some follow up about the React migration: