Description
Airflow PR #70149 added route identifiers and resolved Dag, Dag run, task instance, and asset objects to React plugin props, but explicitly leaves them undefined for the base destination because its parent-route mount cannot see child-route parameters. Follow up could be created to derive the context for persistent base plugins from the complete active route branch rather than from parameters visible only at the mount route. Airflow's route definitions could be used to provide a semantic page kind, together with any Dag, Dag run, task, task instance, mapped task, and asset identifiers present on the matched child route. Pages that genuinely lack resource identifiers, such as Dashboard and list pages, should expose their semantic page kind while leaving those identifiers undefined. With this base mounted plugins (like a hideable sidebar) should not need to parse URL paths to recover this information.
Use case/motivation
I'm building a persistent open/closeable sidebar plugin, that would greatly benefit from this information. I'm willing to provide a PR for this, if no objections.
Related issues
No response
Are you willing to submit a PR?
Code of Conduct
Description
Airflow PR #70149 added route identifiers and resolved Dag, Dag run, task instance, and asset objects to React plugin props, but explicitly leaves them undefined for the base destination because its parent-route mount cannot see child-route parameters. Follow up could be created to derive the context for persistent base plugins from the complete active route branch rather than from parameters visible only at the mount route. Airflow's route definitions could be used to provide a semantic page kind, together with any Dag, Dag run, task, task instance, mapped task, and asset identifiers present on the matched child route. Pages that genuinely lack resource identifiers, such as Dashboard and list pages, should expose their semantic page kind while leaving those identifiers undefined. With this base mounted plugins (like a hideable sidebar) should not need to parse URL paths to recover this information.
Use case/motivation
I'm building a persistent open/closeable sidebar plugin, that would greatly benefit from this information. I'm willing to provide a PR for this, if no objections.
Related issues
No response
Are you willing to submit a PR?
Code of Conduct