Redash: React migration

[arikfr]

Status

Type | Description | Status | Comment
-|-|-|-
Page | Query View | #4429
Page | Query Editor | #4429
Component | AppView | #4525 | (layout component, contains logic of redirecting to login, rendering the header and some more)
lib | Routing | #4159 |
lib | State Management | | Not 100% sure we need this from the get go
lib | Model Classes | | Mostly the $http/$resource based objects

---

As announced in July, we started the migration of our frontend code to React:

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 react2angular library (and later the angular2react 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.

This is a gradual process where until finished, our codebase will use both Angular.js and React. Since version 4 we were shipping this hybrid codebase. The code editor, date parameters and edit in place component use React now.

[arikfr]

https://github.com/STRML/react-grid-layout - can be relevant for our dashboard grid.

[ice2038]

Libraries for React i18n for Add i18n support #933.

[brylie]

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)

I don't want to diminish the work that the Mozilla team are doing, nor discount their wisdom and experience. So, thanks to all the people who are updating the frontend framework.

My concern is that the overarching direction in the JavaScript ecosystem is somewhat dismissive of web standards, opting to re-invent CSS and HTML inside of JavaScript.

From a personal perspective, having followed a web development career over the past ten years, the trajectory of JSX and the churn in the JavaScript ecosystem feel like a net loss for productivity and the ability of new developers to get started on a project.

This is not about React vs. Vue. The point is that React has fairly strongly deviated from familiar territory and common web development practices, choosing not to build on the decades of work by W3C, WCAG and others, but to more-or-less replace crucial parts of the Web Platform.

Mozilla have actively been promoting web standards, like HTML, CSS, and JavaScript, with their School of Webcraft and other initiatives. I just really wish that Mozilla, of all organizations, would have chosen a framework that more closely aligned with web standards and traditional web development best practices (e.g. separation of semantic structure, declarative style, and imperative logic).

[brylie]

*WHATWG, not WCAG. Sorry for the alphabet soup 😛

[arikfr]

Thank you for sharing this, @brylie! It's a bit too late though -- we're 60%-70% into the React migration already.

While I understand the concern, I think we should be pragmatic as well. I'm not sure if at the time there was any choice that would be more inline with web standards while also being productive. I'm not sure if today there is one.

We're also trying to use common sense and adopt technologies that make sense to us and will serve us in the long term. So for now we're still using LESS for CSS and didn't switch to one of the CSS-in-JS libraries.

[brylie]

I recognize there has already been a significant investment of great and well-intentioned work in the React migration, and honestly don't intend to diminish that work.

In your introduction post, you mentioned Vue, while Angular and Aurelia were were available (possibly among other options). All of the aforementioned frameworks build on web standards, rather than partially reinventing them in JavaScript.

Web standards exist so that our technology can serve us for the long-term.

I am not sure how we can resolve this great divide, but firmly believe it is in the interest of the community that we keep HTML and CSS around for people who are not as comfortable working with JavaScript.

[arikfr]

In your introduction post, you mentioned Vue, while Angular and Aurelia were were available (possibly among other options). All of the aforementioned frameworks build on web standards, rather than partially reinventing them in JavaScript.

Angular is not an option and Aurelia is probably not either. But Vue was an option, but if I'm not mistaken it doesn't really use HTML -- it takes the template you define and converts it into a Virtual DOM.

So it might be more familiar for some people, but you can't say it's using web standards.

Anyway this discussion is pointless considering the stage of the React migration. We will keep this in mind for the 2025 rewrite 😄

[brylie]

Anyway this discussion is pointless considering the stage of the React migration.

Point duly noted, and great work with the migration. I understand it is non-trivial amount of work.

you can't say it's using web standards.

Since you mentioned it, I would like to clarify that Vue, among similar libraries like Aurelia, actually do(es) align strongly with web standards. Just because it pre-processes the HTML templates into render functions, does not mean it is not aligned with web standards.

All Vue.js templates are valid HTML that can be parsed by spec-compliant browsers and HTML parsers.
https://vuejs.org/v2/guide/syntax.html

It also bears mentioning that Vue has a native web component build target:
https://cli.vuejs.org/guide/build-targets.html#web-component

[codemaster08240328]

Hi @arikfr . Thank you for your good job.
By when do you think it is finished to migrate frontend into React?

[vbk2000]

I want to know this issue processing. Anyone know?

[ranbena]

@codemaster08240328 @vbk2000 It's hard to say how much longer it would be. It's a balancing act, migrating each component while still keeping the product in motion. This issue's description is kept up to date with our progress.

[arikfr]

Relevant discussion : https://discuss.redash.io/t/react-migration-what-should-we-replace-http-resource-with/5003.

[arikfr]

We're at the last stretch of the migration! What's left is (aside from merging open work):

• Query Editor page
• Results page
• Migrate all models/services to non Angular library (axios).
• AppView component & Router (I believe those two are related)

So we don't have to fiddle with Angular<->React interoperability more than we do now, it probably makes to implement in the order above. We can start already migrating models/services that aren't used on the Query/Results pages to a non Angular library already.

Once these are done we should do some housekeeping on our webpack/build setup. Maybe even consider create-react-app based setup.

I was hoping to do the routing myself, but I'm knee deep in the Python 3 migration testing. I might still do it, depends on how long the other tasks will take.

Query Editor/Results pages

I was hoping to use this opportunity to redesign them a bit, but I think we will need to settle for only splitting them and addressing some quick wins so we can move forward with the migration.

@kravets-levko you will take the query editor page and @gabrieldutra you the results page?

• For split panes, we should probably use react-split-pane (or similar) rather than keeping our own implementation.
• react-window might be useful for making sure the schema component is efficient with large schemas (I don't know if Ant handles this out of the box).

Services/models migration

Aside from one to one conversion from $http to Axios, we should consider that we write things in a way that is inline with React's data lifecycle (i.e. returning new objects when things change) so we can reduce workarounds/hacks we implemented because of lacking this.

(comments are welcome)

[gabrieldutra]

For the split panes I quickly tested react-split-pane and react-split, which seemed the most used for this purpose. The second one I actually couldn't make it work and the first went well, so I'm planning to create an abstraction over it tomorrow, copying the existing css.

[arikfr]

@gabrieldutra let's drop the split/resizable panes for the results view and rather implement this version:

We would probably need to tweak this, but let's iterate once we have the initial version implemented.

[arikfr]

@mobop I think we no longer need jQuery, but it will be removed when we remove the last Angular dependencies.

[srs231198]

Does this issue need any more assistance?

[arikfr]

The codebase is now 100% React. We're still cleaning up some things, but the migration is done. 🎉