[jlaneve]

A React plugin with destination: "base" renders above the content of every page, and while its bundle loads, ReactPlugin's Suspense fallback puts a bare spinner in the top left corner. The page itself has already rendered by then, so every full page load shows a stray spinner above it until the plugin's bundle arrives. On a slow connection that can take seconds. Base plugins now render nothing until they are ready. Every other destination keeps the spinner, because there the plugin fills a page or tab that would otherwise be empty.

Call-stack diff

  BaseLayout
  └─ ReactPlugin({ reactApp })              # one per destination "base" app
     ├─ globalThis[reactApp.name] set?      # unchanged: render it directly
     └─ <Suspense fallback>
-       ├─ <Spinner />                      # every destination
+       ├─ null                             # destination "base"
+       ├─ <Spinner />                      # every other destination
        └─ LazyPlugin -> loadPlugin(reactApp)

• Open question. The page still moves down when a base plugin finishes loading. Two ideas that don't change the plugin API: remember each base plugin's last measured height in localStorage and reserve it while the bundle loads, or have the server add a modulepreload link for base bundles to index.html so they download alongside the UI. Happy to follow up with either if it sounds right.
• How I checked it. I applied the same one-line change to the 3.3.1 UI and served it from an Astro Runtime 3.3.1 image with a base plugin installed. I held the plugin's bundle so the loading state stayed on screen. Before the change the page showed one spinner; after it, none. With the bundle allowed through, the plugin rendered as before. The two new tests in ReactPlugin.test.tsx cover both fallbacks. The base case fails if its fallback goes back to <Spinner />.

Before and after, with the base plugin's bundle still loading (Airflow 3.3.1):

Before: a spinner sits in the top left above the page.

After: nothing shows until the plugin is ready.

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: Claude Code (Claude Opus 5.5) following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[bbovenzi]

Let's just fix the react tests and lgtm

[bbovenzi]

For your questions the latter sounds interested if its possible. Of course not every "base" plugin attaches to the top of the page so "remembering" the offset seems too specific and doesn't solve other possible loading issues

[github-actions]

Backport successfully created: v3-4-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-4-test