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
Problem: Add docs for no-JS/SSR fallback where applicable. is currently not completed, and it blocks feature parity and/or quality improvements identified in the audit.
Scope: Implement the change with associated test coverage and documentation updates where applicable.
Acceptance criteria:
The implementation is merged with appropriate tests.
Storybook/docs are updated for behavior/API changes.
Release notes/changeset entry is added when user-facing behavior changes.
It means the docs should explain how components behave:
during SSR
before hydration
with JavaScript disabled
In plain terms, users want to know:
does this component render useful HTML on the server?
is it accessible before client JS loads?
if JS is off, does it still show content, partially work, or completely depend on hydration?
are there fallback patterns they should use?
Examples of what such docs usually cover:
a Dialog may render nothing useful without JS-driven open/close behavior
a simple content component like Text, Heading, Table should SSR fine
an accordion, menu, combobox, tooltip, or popover may need JS for interaction, so docs should say that clearly
if there is a recommended fallback, document it, like “render static content server-side” or “use native HTML element X when no-JS support matters”
So the issue is basically:
“Document which components degrade gracefully with SSR/no-JS, and which ones require client-side JS.”
In your repo, this is likely more relevant as guidance than as a code task. If you want, I can inspect the public components and tell you which ones actually need SSR/no-JS notes and which ones don’t.
It means the docs should explain how components behave:
during SSR
before hydration
with JavaScript disabled
In plain terms, users want to know:
does this component render useful HTML on the server?
is it accessible before client JS loads?
if JS is off, does it still show content, partially work, or completely depend on hydration?
are there fallback patterns they should use?
Examples of what such docs usually cover:
a Dialog may render nothing useful without JS-driven open/close behavior
a simple content component like Text, Heading, Table should SSR fine
an accordion, menu, combobox, tooltip, or popover may need JS for interaction, so docs should say that clearly
if there is a recommended fallback, document it, like “render static content server-side” or “use native HTML element X when no-JS support matters”
So the issue is basically:
“Document which components degrade gracefully with SSR/no-JS, and which ones require client-side JS.”
In your repo, this is likely more relevant as guidance than as a code task. If you want, I can inspect the public components and tell you which ones actually need SSR/no-JS notes and which ones don’t.