Some thoughts to start the discussion:

We already have some dynamic functionality around adding custom pages, visualizations and components by auto loading any file in client/app/{components,pages,visualizations,services} and executing the exported function (while passing the app module to it).

webpack's require.context function can't take a variable for a path, but we can use webpack's alias configuration to be able to specify additional folder to load code from in a similar way. This folder path can be defined using an environment variable, so we no longer have to put it in the existing folder structure (which gets overridden when deploying a new version).

The above will allow for adding new functionality to Redash (like new pages/components/visualizations), but we also need extension points in the code, to be able to modify and extend existing functionality.

This is what we did in the Policy pull request. There are two types of extensions there:

The Policy object which you can replace with a different implementation, that allows you to set custom logic around whether certain operations are permitted.
References to non existing components (like <users-list-exta> here) which you can implement to show additional information in various places in the application. We can add similar "extension points" to implement some of the custom UI Mozilla has (like data source version or documentation link).

This is what I have so far, some additional half baked thoughts I have:

It might be interesting to have the ability to load extensions at "runtime" (specially visualizations), but I'm not sure how useful that can be.
It can be useful to be able to replace components with a different implementation. Not sure how to achieve this though.

Also we need to keep in mind that any solution we implement, needs to keep working when we migrate to React...

Uh oh!

Add front-end extension capability #2565

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions