raystack / raystack/apsara

Docs: hand-duplicated props tables drift risk, missing a11y sections, no per-component changelog

Open
#879 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement global
Dominant language
TypeScript
Stars
70
Forks
13
Avg merge
2d 5h
Merged PRs (30d)
8

Description

Summary

Component docs (apps/www) have the right shape — props table, live demo playground, accessibility notes — but three gaps showed up in a practices audit.

Issues found

  1. Props tables are hand-duplicated and can drift. Each component has a shadow props.ts file (e.g. apps/www/src/content/docs/components/button/props.ts) read by fumadocs-typescript's remarkAutoTypeTable (apps/www/source.config.ts:16-33,62) instead of being generated from the real component types. Comparing button/props.ts against the actual button.tsx:127-134 union already shows props omitted from the doc.

  2. Accessibility sections are inconsistent. Present on Button, Dialog, Checkbox, Tabs, Select, Sidebar. Missing entirely on Combobox, Menu, ContextMenu, and DataView — notably the most complex component in the library has no accessibility documentation.

  3. No per-component changelog. Only one repo-wide packages/raystack/CHANGELOG.md (changesets-generated), and it isn't linked or surfaced anywhere on the apps/www docs site. Consumers browsing a component's docs page have no way to see what changed for that component.

Suggested approach

  • Generate props tables directly from the real component source, or add a CI check that diffs the shadow props.ts files against the actual exported prop types so drift fails a build instead of shipping silently.
  • Backfill Accessibility sections for combobox, menu, context-menu, and dataview.
  • Surface per-component changelog entries on each docs page (even a filtered view of the existing changesets changelog would close most of the gap).

Notes

Found via a components.build practices audit (docs dimension).

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with apps/www/src/content/docs/components/button/props.ts, the corresponding button.tsx prop types, and apps/www/source.config.ts to understand the current table generation. Review the component docs for existing accessibility sections and packages/raystack/CHANGELOG.md for changelog data. Done means the documented props no longer drift, the named components have accessibility sections, and component changes are surfaced on their docs pages.

Written by the indexing model from the issue text.

Assessment

Tech stack
react, typescript
Domain
accessibility, documentation, frontend
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.