Render post menu items lazily (take two) #6473
Open
+741
−672
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resubmit of #6437.
I broke dialogs in #6437. We can't put dialogs inside the
<Menu.Outer>
conditionally rendered content because that would destroy their state and controls, and those need to be alive even after the dialog is closed.Now I'm unreverting it but applying a few more fixes on top:
6b1640
?w=1 applies a slightly different approach. The dialogs are placed outside of<Menu.Outer>
so that they don't depend on the menu open/close state. However, the menu itself is not rendered until the first time you press the button. In other words, the menu is now initialized lazily.useMenuControl
only hasisOpen
for web and I can't figure out how to fix that. This new implementation is ugly but works cross-platform.Test Plan
Verify the menu works. Verify the dialogs within the menu also work (unlike last time). Verify you can toggle the menu repeatedly. Refresh the page and verify that you can also toggle the menu (both once and repeatedly) using keyboard.
Do this on all platforms.