pierrejeambrun commented on code in PR #54994:
URL: https://github.com/apache/airflow/pull/54994#discussion_r2322257694
##########
providers/edge3/src/airflow/providers/edge3/plugins/www/src/pages/JobsPage.tsx:
##########
@@ -22,12 +22,17 @@ import { useUiServiceJobs } from "openapi/queries";
import { ErrorAlert } from "src/components/ErrorAlert";
export const JobsPage = () => {
- const { data, error } = useUiServiceJobs();
+ // Note: might use this in future but core-ui-API is not yet bound:
+ // const autoRefreshInterval = useConfig("auto_refresh_interval") as number
| undefined;
Review Comment:
> Main question that I have is if we build some "common components" in core
that might be used (via npm?) would this include Core API as well?
Public API is stable and all of the front-end code can also be public
interface and stable. So the custom hooks / interfaces to query public API can
be shared. In this case the `get_config` endpoint.
On the other hand as you mentioned, if you need to query a `ui` endpoint for
your plugin, I think it's a no go. By design `ui` endpoints are not stable and
crafted for core UI needs. User plugins / providers plugins etc.... I don't
think they should depend on `ui` unfortunately. (That's arguable for our own
maintained providers plugins such as this one, but I wouldn't introduce
coupling between providers and core UI API).
The path forward would be to acknowledge that some users might need
`get_config` endpoint, and figure out a way to expose it publicly. (make it
stable, and move it from `UI` to `public` API)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
