mirror of
https://github.com/apache/superset.git
synced 2026-05-08 09:25:56 +00:00
752ebd47cb
- Snapshot all four versioned docs sections at v6.1.0; master continues to serve as "Next" (lastVersion: current, banner: unreleased) so editing master keeps updating the canonical URLs - Enable the previously-disabled components plugin and version it - Rename stale "developer_portal" references to "developer_docs" across package.json scripts, manage-versions.mjs, theme files (DocVersionBadge, DocVersionBanner), DOCS_CLAUDE.md, and README.md (URL backward-compat redirect /developer_portal/* preserved) - Add admin_docs version scripts; drop dead "tutorials" plugin id from the version badge - Generalize fixVersionedImports in manage-versions.mjs to walk every section's snapshot and rewrite ../../src/ and ../../data/ imports, catching admin_docs and components files that previous version cuts would have broken - Remove orphan files: developer_portal_versions.json, tutorials_versions.json, and stray empty versions.json files inside components/ and developer_docs/ content directories
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