| Filename | Latest commit message | Latest commit date |
|---|---|---|
* feat(experimental): derive client toggles from ClientCapabilities (#1240) Closes the Phase 5 audit partial: ExperimentalFeaturesPanel now accepts clientExperimental: ClientCapabilities['experimental'] (the SDK record shape) instead of a parallel clientToggles array of UI metadata. Adopts Option B from the design question: toggle metadata (label, description) lives in a static CLIENT_EXPERIMENTAL_TOGGLE_METADATA map inside the component file. Iteration is over Object.keys of the live record, so presence-in-record means enabled. Unknown keys (in record but not in the metadata map) render with the raw key as label and no description, per AC. Renders one Checkbox per active toggle plus an indented HintText description when metadata is known. Callback signature unchanged. Stories cover empty, all-known, and mixed-known-and-unknown cases. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Render full toggle universe, derive checked from record Address in-review feedback: with the strict-AC iteration over Object.keys(clientExperimental), unchecking a toggle made its row disappear (no schema slot for "disabled but available"), so the user couldn't re-enable a toggle they just turned off. Refines Option B: render the union of metadata-map keys and record keys. Each row's checked state is derived from name-in-record. Result: known toggles always render, regardless of record state; toggling is fully reversible from the UI; unknown record keys still surface with a raw label. Story rename: NoClientToggles → NoneEnabled, AllKnownClientToggles → AllKnownEnabled, MixedKnownAndUnknownToggles → MixedKnownAndUnknown — the new names describe state, not record shape. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
| .. | ||
| .storybook | ||
| public | ||
| src | ||
| .gitignore | ||
| chromatic.config.json | ||
| eslint.config.js | ||
| index.html | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| tsconfig.app.json | ||
| tsconfig.json | ||
| tsconfig.node.json | ||
| tsconfig.storybook.json | ||
| vite.config.ts | ||
| vitest.shims.d.ts | ||
React + TypeScript + Vite
This template provides a minimal setup to get React working in Vite with HMR and some ESLint rules.
Currently, two official plugins are available:
- @vitejs/plugin-react uses Oxc
- @vitejs/plugin-react-swc uses SWC
React Compiler
The React Compiler is not enabled on this template because of its impact on dev & build performances. To add it, see this documentation.
Expanding the ESLint configuration
If you are developing a production application, we recommend updating the configuration to enable type-aware lint rules:
export default defineConfig([
globalIgnores(['dist']),
{
files: ['**/*.{ts,tsx}'],
extends: [
// Other configs...
// Remove tseslint.configs.recommended and replace with this
tseslint.configs.recommendedTypeChecked,
// Alternatively, use this for stricter rules
tseslint.configs.strictTypeChecked,
// Optionally, add this for stylistic rules
tseslint.configs.stylisticTypeChecked,
// Other configs...
],
languageOptions: {
parserOptions: {
project: ['./tsconfig.node.json', './tsconfig.app.json'],
tsconfigRootDir: import.meta.dirname,
},
// other options...
},
},
])
You can also install eslint-plugin-react-x and eslint-plugin-react-dom for React-specific lint rules:
// eslint.config.js
import reactX from 'eslint-plugin-react-x'
import reactDom from 'eslint-plugin-react-dom'
export default defineConfig([
globalIgnores(['dist']),
{
files: ['**/*.{ts,tsx}'],
extends: [
// Other configs...
// Enable lint rules for React
reactX.configs['recommended-typescript'],
// Enable lint rules for React DOM
reactDom.configs.recommended,
],
languageOptions: {
parserOptions: {
project: ['./tsconfig.node.json', './tsconfig.app.json'],
tsconfigRootDir: import.meta.dirname,
},
// other options...
},
},
])