[bug][docs] <rh-button> second, empty button appearing in WebKit
#2097
Comments
hellogreg
added
bug
hellogreg
changed the title
<rh-button> second, empty button appearing in WebKit<rh-button> second, empty button appearing in WebKit
|
Not sure if this is related to #2055, but mentioning that here in case it is. |
|
Same solution here as for icon and CTA At this point I think this did require an SSR debug controller, which is unfortunate. I'll try to make a repro and file on lit |
|
Hi there! I noticed @bennypowers posted this in the Lit GitHub and figured I'd chime in. Double rendering like this is usually either: A.) A timing issue withthe hydration support module Since theres no errors on hydration mismatch ,its most likely A. I noticed the following on this page: https://ux.redhat.com/elements/button/demo/ <head>
<script type="module">
// dsd polyfill needs to happen before hydration attempts
// lit-element-hydrate-support needs to be included before lit is loaded
import '/assets/javascript/dsd-polyfill.js';
import '@lit-labs/ssr-client/lit-element-hydrate-support.js';
import 'element-internals-polyfill';
// include these, which are often internal to elements, to avoid SSR defer-hydration bugs
import '@rhds/elements/rh-icon/rh-icon.js';
import '@rhds/elements/rh-surface/rh-surface.js';
// load up the demo and picker
import '@rhds/elements/lib/elements/rh-context-picker/rh-context-picker.js';
import '@rhds/elements/lib/elements/rh-context-demo/rh-context-demo.js';
</script>
</head>The timings of imports parsing + execution is different across browsers and can't really be relied upon like this. I would try the following just to isolate if it is indeed the hydration module loading too late: <script type="module">
window.componentsLoaded = new Promise(async (resolve) => {
await import('import '/assets/javascript/dsd-polyfill.js');
// I'm assuming order doesn't matter here?
await Promise.allSettled([
import('@lit-labs/ssr-client/lit-element-hydrate-support.js'),
import('element-internals-polyfill');
])
await Promise.allSettled([
// include these, which are often internal to elements, to avoid SSR defer-hydration bugs
import('@rhds/elements/rh-icon/rh-icon.js');
import('@rhds/elements/rh-surface/rh-surface.js');
// load up the demo and picker
import('@rhds/elements/lib/elements/rh-context-picker/rh-context-picker.js');
import('@rhds/elements/lib/elements/rh-context-demo/rh-context-demo.js');
])
resolve()
})
</script>And then for the components you load on the page, just make sure everything has loaded first. <body>
<script type="module">
await window.componentsLoaded
import('@rhds/elements/rh-button/rh-button.js');
</script>
</body>Its entirely possible this isn't the case, but I remember hitting similar timing issues in Rails with importmaps and figured I'd throw it out there. |
|
@KonnorRogers i suspect that what's happening here is that
If that's the case, then we should be able to do something like this: <script type="module">
window.ssrSupportLoaded = new Promise(async (resolve) => {
await import('import '/assets/javascript/dsd-polyfill.js');
// I'm assuming order doesn't matter here?
await Promise.allSettled([
import('@lit-labs/ssr-client/lit-element-hydrate-support.js'),
import('element-internals-polyfill');
])
resolve()
})
</script>
<script type="module">
await window.ssrSupportLoaded
await Promise.allSettled([
// put app dep imports here in any order
])
</script>I haven't tested that, but WDYT, does that track with your understanding? We found that simply loading rh-button higher up in the chain (i.e. just after lit-element-hydrate-support) did the trick for us <script type="module">
// dsd polyfill needs to happen before hydration attempts
// lit-element-hydrate-support needs to be included before lit is loaded
import '/assets/javascript/dsd-polyfill.js';
import '@lit-labs/ssr-client/lit-element-hydrate-support.js';
import 'element-internals-polyfill';
// include these, which are often internal to elements,
// and are definitely required by context-picker and context-demo
// to avoid SSR defer-hydration bugs and SSR double-rendering bugs
import '@rhds/elements/rh-icon/rh-icon.js';
import '@rhds/elements/rh-surface/rh-surface.js';
import '@rhds/elements/rh-button/rh-button.js';
import '@rhds/elements/rh-tooltip/rh-tooltip.js';
</script> |
|
Your first code block is going to be much more reliable. The second one is kind of just hoping import order is respected by the browser (which im not 100% will always be the case) I also think I read the script wrong the first time, you may even be able to do this: <script type="module">
window.ssrSupportLoaded = new Promise(async (resolve) => {
- await import('import '/assets/javascript/dsd-polyfill.js');
// I'm assuming order doesn't matter here?
await Promise.allSettled([
+ import('/assets/javascript/dsd-polyfill.js'),
import('@lit-labs/ssr-client/lit-element-hydrate-support.js'),
import('element-internals-polyfill'),
])
resolve()
})
</script>
<script type="module">
await window.ssrSupportLoaded
await Promise.allSettled([
// put app dep imports here in any order
])
</script> |
|
i think you're right on both counts. Our problem is that we aren't building apps, we're shipping libraries, so we can't impose too many hard requirements on module loading (it's hard enough to get users to load modules in the first place) |
github-project-automation
bot
moved this from Todo
to Done ☑️
in Red Hat Design System Roadmap
Describe the bug
At the docs site, a second, empty button typically appears next to
<rh-button>in Mac and iOS Safari. This can be seen at the button demo page and for other elements where we're usingrh-button(e.g., tooltip).Word on the street is that this is an SSR-related issue.
Screenshots
Steps to reproduce
rh-buttondemo page in Safari.Expected behaviour
Only the real button should appear, not the impostor.
Operating System (OS)
macOS and iOS
Browser
Safari 18.2
The text was updated successfully, but these errors were encountered: