AIP-68 | Develop new React plugins

[bbovenzi]

In an Airflow plugin appbuilder_views will be deprecated. They need to be replaced with react_views.

Fields to include when registering react_views

name: string, // plugin name

title: string, // display name to show on buttons

icon: string, // (optional) path to an icon file to display next to the title

url_route: string, (optional) what to display in the url route, defaults to the plugin name

src: string, // path to the javascript bundle file where the react component lives

location: enum[] // where in the UI the component can live, it can live in multiple places

• "nav" add as a top-level nav button
• "dag" add as a tab in the DAG details view
• "dag_run" add as a tab in the DAG details view but only for dag runs
• "task" add as a tab in the DAG details view but only for that task across runs
• "task_instance" for a specific task instance
• "dashboard" add a panel on the dashboard homepage
• "asset" add to Asset details page
• "dag_overview" add to dag overview page
• "task_overview" add to task overview page
• "task_logs" add to task logs page
• "base" add to the BaseLayout component so that it can appear on any/all pages

The plugins manager then needs to add the icon and component static files to be hosted by FastAPI.
We can dynamically lazy load the components with lazy(() => import(/* @vite-ignore */ plugin.src)

Other issues:

• Rename appbuilder_menu_items to menu_items and send the array to the UI to render in the main nav page AIP-68 | Migrate plugin menu_items to FastAPI and new UI #42706
• Add support for plugins that are simply urls to render inside of an iframe, saving developers the hassle of building a custom react component just to render a 3rd part website anyway AIP-68 Add iframe_views plugin #42708
• Add a CLI command to build all the boilerplate code for a react component project so plugin developers don't need to worry about project setup
• Develop an API for what props a react plugin component can expect from the UI depending on its location.

Other questions:

• Should we still have a webserver run when the FAB provider exists in order to host legacy plugins and render them as iframes?

[bbovenzi]

POC of a react plugin on the Nav level:

I also used https://bolt.new/ as an AI to generate frontend code. I wonder if we can suggest similar tools to help developers who might not know frontend technologies well.

[bbovenzi]

After chatting with @pierrejeambrun, I updated the ui_view plugin spec above. Two notes of things that we won't include there but should be well-documented:

Component props: we will try to send the most specific object we can to the React component (eg: if you're on a dag run tab, we will pass the dagRun: DagRunResponse as a prop)

Conditionally rendering a plugin: It is up to the plugin maintainer to decide if a plugin should render (eg: my plugin is for my custom operator to add a component for the task overview page, in my plugin code I need to check if the current task has that operator and if not return undefined)

Placement inside of an existing view: We should make sure that the wrapper for any plugin that lives inside of an existing view is built for an arbitrary number of extra components being added to it. With position: relative and probably as a "display: flex", it would be up to the plugin component to customize its css if it doesn't want to be added to the end of the wrapper: https://css-tricks.com/snippets/css/a-guide-to-flexbox/#aa-properties-for-the-childrenflex-items