Skip to content

Conversation

iansan5653
Copy link
Contributor

@iansan5653 iansan5653 commented Sep 23, 2025

Currently ActionBar only supports direct children because it uses Children APIs to find the props to determine what to render in the menu. By switching to a pure context-based approach using a registry that stores all the necessary data, ActionBar can be updated to support deeply nested children, aliased children, fragments, etc.

The children are registered with the same layout effect approach for determining their measurements, but they are now stored in a Map by unique ID rather than a simple array. The map allows them to update themselves if their props change and de-register themselves when they unmount.

The challenge with this approach is preserving the order of the items in the registry vs in the React tree. We need the items in the registry to always be in the same order as the tree so that the ActionBar knows which ones are last (to hide first) and can preserve their order in the overflow menu. For this we rely on Map preserving the insertion order. Since React will always render the tree from start to end, top to bottom, we know we'll receive the elements in the right order on the first render.

However, effect cleanup still presents a challenge. If we don't clean up after ourselves, the ActionBar will never know if an item got removed from the bar. But if we remove items from the map on cleanup, they will get re-added at the end of the map when they update. So instead, I've set the values to null on cleanup and added logic to ignore null values in the component. This preserves the insertion order for the lifetime of the registry.

Caveats: Unfortunately this approach is not perfect. While it's robust to an item getting removed from the list, or new items getting added to the end of the list, it will cause unexpected behavior if a new item is added in the middle or beginning of the list. This is because these items would be added at the end of the registry, rather than in the correct location. I haven't been able to come up with a solution for this -- we'd have to somehow trigger the registry to be rebuilt from scratch when an item is added, but I don't think that's possible without triggering infinite render loops, since items have to be added to build the registry in the first place.

TLDR: This change would allow consumers to wrap ActionBar item components, use aliased components, and otherwise provide indirect children. But the drawback is that it would cause unexpected behavior if new items are added to the beginning or middle after the initial render.

FWIW, I think the drawback may be a reasonable tradeoff. I don't think that adding new items to the middle would be a very common scenario anyway.

Changelog

New

Changed

Removed

Rollout strategy

  • Patch release
  • Minor release
  • Major release; if selected, include a written rollout or migration plan
  • None; if selected, include a brief description as to why

Testing & Reviewing

Merge checklist

Copy link

changeset-bot bot commented Sep 23, 2025

⚠️ No Changeset found

Latest commit: 386fa04

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link
Contributor

👋 Hi, this pull request contains changes to the source code that github/github depends on. If you are GitHub staff, we recommend testing these changes with github/github using the integration workflow. Thanks!

@github-actions github-actions bot added the integration-tests: recommended This change needs to be tested for breaking changes. See https://arc.net/l/quote/tdmpakpm label Sep 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integration-tests: recommended This change needs to be tested for breaking changes. See https://arc.net/l/quote/tdmpakpm
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants