You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR introduces a new content property on , allowing consumers to explicitly declare the types of overlays they intend to use. This helps optimize performance by preventing unnecessary DOM updates, reducing re-render loops, and avoiding slot reparenting issues.
Previously, dynamically determined the required overlays by checking assigned slot content. However, this approach caused unintended re-renders and, in some cases, infinite render loops due to slotchange event handling. The new content property provides a declarative alternative, allowing better control over which overlays should be rendered.
The primary motivation for this change is to improve performance and prevent unintended re-renders caused by the current slot-based content detection in <overlay-trigger>. The existing approach dynamically determines which overlays to render by inspecting assigned slot content, but this can lead to unnecessary DOM updates, race conditions, and in some cases, infinite render loops. By introducing the content property, consumers can explicitly declare the overlay types they intend to use, reducing unnecessary computations and ensuring more predictable behavior.
This change not only improves stability but also provides a clearer, more declarative API for developers. Instead of relying on implicit slot detection, which can sometimes cause the unintended side effects, consumers can now specify their overlay needs up front. The implementation remains backwards compatible, allowing existing functionality to continue working while encouraging adoption of the more efficient approach (with development warnings when not using the new property). Over time, as adoption increases, we can consider making the content property a required part of the API to further standardize and optimize overlay behavior.
How has this been tested?
The original bug reporters tested this solution manually on their application and confirmed this does indeed solve #4689.
Added a new Storybook story to reflect the new property
Visit story
Inspect DOM
Verify only the respective sp-overlay are rendered by default
Added integration tests to cover new functionality
Tested for dev warnings
Tested for backwards compatibility
Tested for all combinations
Existing tests pass (backwards compatibility).
Did it pass in Desktop?
Did it pass in Mobile?
Did it pass in iPad?
Screenshots (if appropriate)
Types of changes
Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Chore (minor updates related to the tooling or maintenance of the repository, does not impact compiled assets)
If my change required a change to the documentation, I have updated the documentation in this pull request.
I have read the CONTRIBUTING document.
I have added tests to cover my changes.
All new and existing tests passed.
I have reviewed at the Accessibility Practices for this feature, see: Aria Practices
Best practices
This repository uses conventional commit syntax for each commit message; note that the GitHub UI does not use this by default so be cautious when accepting suggested changes. Avoid the "Update branch" button on the pull request and opt instead for rebasing your branch against main.
If the changes are expected, update the current_golden_images_cache hash in the circleci config to accept the new images. Instructions are included in that file.
If the changes are unexpected, you can investigate the cause of the differences and update the code accordingly.
Lighthouse scores comparing the documentation site built from the PR ("Branch") to that of the production documentation site ("Latest") and the build currently on main ("Main"). Higher scores are better, but note that the SEO scores on Netlify URLs are artifically constrained to 0.92.
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.
rubencarvalho
changed the title
chore: always render sp-overlay
feat(overlay): add content property for performance optimization
Feb 6, 2025
rubencarvalho
changed the title
feat(overlay): add content property for performance optimization
feat(overlay): add content property for overlay-trigger performance optimization
Feb 6, 2025
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.
rubencarvalho
force-pushed
the
ruben/fixing-overlay-infinite-render
branch
from
Description
This PR introduces a new content property on , allowing consumers to explicitly declare the types of overlays they intend to use. This helps optimize performance by preventing unnecessary DOM updates, reducing re-render loops, and avoiding slot reparenting issues.
Previously, dynamically determined the required overlays by checking assigned slot content. However, this approach caused unintended re-renders and, in some cases, infinite render loops due to slotchange event handling. The new content property provides a declarative alternative, allowing better control over which overlays should be rendered.
For full details, see the RFC: “content” property on
<overlay-trigger>.Related issue(s)
Motivation and context
The primary motivation for this change is to improve performance and prevent unintended re-renders caused by the current slot-based content detection in
<overlay-trigger>. The existing approach dynamically determines which overlays to render by inspecting assigned slot content, but this can lead to unnecessary DOM updates, race conditions, and in some cases, infinite render loops. By introducing thecontentproperty, consumers can explicitly declare the overlay types they intend to use, reducing unnecessary computations and ensuring more predictable behavior.This change not only improves stability but also provides a clearer, more declarative API for developers. Instead of relying on implicit slot detection, which can sometimes cause the unintended side effects, consumers can now specify their overlay needs up front. The implementation remains backwards compatible, allowing existing functionality to continue working while encouraging adoption of the more efficient approach (with development warnings when not using the new property). Over time, as adoption increases, we can consider making the
contentproperty a required part of the API to further standardize and optimize overlay behavior.How has this been tested?
The original bug reporters tested this solution manually on their application and confirmed this does indeed solve #4689.
Added a new Storybook story to reflect the new property
sp-overlayare rendered by defaultAdded integration tests to cover new functionality
Existing tests pass (backwards compatibility).
Did it pass in Desktop?
Did it pass in Mobile?
Did it pass in iPad?
Screenshots (if appropriate)
Types of changes
Checklist
Best practices
This repository uses conventional commit syntax for each commit message; note that the GitHub UI does not use this by default so be cautious when accepting suggested changes. Avoid the "Update branch" button on the pull request and opt instead for rebasing your branch against
main.