mirror of
https://github.com/apache/superset.git
synced 2026-05-22 16:25:49 +00:00
cbcfd9599f
Snapshots all four versioned Docusaurus sections at v6.1.0. Built on top of the version-cutting tooling work in chore/docs-cut-6.1.0-versions so the snapshot benefits from: - Auto-gen refresh before snapshotting (database pages from engine spec metadata, API reference from openapi.json, component pages from Storybook stories) — captured at the SHA we cut from rather than whatever happened to be on disk. - Data-import freeze: country list, feature flag table, database diagnostics, and component metadata are copied into snapshot-local `_versioned_data/` dirs so the historical version doesn't silently mutate when the source files change. - Depth-aware import-path rewriter that handles deeply-nested component MDX files referencing `../../../src/` from the snapshot. Versioning behavior: `lastVersion` stays at `current` for every section, so the canonical URLs (`/docs/...`, `/admin-docs/...`, `/developer-docs/...`, `/components/...`) continue to render content from master. The `current` version is consistently labeled "Next" with an `unreleased` banner, and `6.1.0` is a historical pin accessible only via its explicit version segment. Component playground: previously `disabled: true` in versions-config.json, now enabled and versioned. The plugin block in docusaurus.config.ts was already gated only by the `disabled` flag, so no other code changes were needed to bring it back online. The frozen `databases.json` in the snapshot is the canonical 80-database artifact from the latest committed state in master (preserved by the generator's input-hash cache), not a fallback regenerated from a local Flask environment.
3.0 KiB
3.0 KiB
title, sidebar_position
| title | sidebar_position |
|---|---|
| Overview | 1 |
Frontend Style Guidelines
This is a list of statements that describe how we do frontend development in Superset. While they might not be 100% true for all files in the repo, they represent the gold standard we strive towards for frontend quality and style.
- We develop using TypeScript.
- See: SIP-36
- We use React for building components, and Redux to manage app/global state.
- We prefer functional components to class components and use hooks for local component state.
- We use Ant Design components from our component library whenever possible, only building our own custom components when it's required.
- See: SIP-48
- We use @emotion to provide styling for our components, co-locating styling within component files.
- We use Jest for unit tests, React Testing Library for component tests, and Cypress for end-to-end tests.
- See: SIP-56
- See: Testing Guidelines and Best Practices
- We add tests for every new component or file added to the frontend.
- We organize our repo so similar files live near each other, and tests are co-located with the files they test.
- See: SIP-61
- We prefer small, easily testable files and components.
- We use OXC (oxlint) and Prettier to automatically fix lint errors and format the code.
- We do not debate code formatting style in PRs, instead relying on automated tooling to enforce it.
- If there's not a linting rule, we don't have a rule!
- See: Linting How-Tos
- We use React Storybook to help preview/test and stabilize our components
- A public Storybook with components from the
masterbranch is available here
- A public Storybook with components from the