mirror of
https://github.com/apache/superset.git
synced 2026-04-24 10:35:01 +00:00
0fb7fc2721
Major restructuring of documentation to separate concerns: **New Structure:** - `/docs/` - User-facing docs (intro, quickstart, databases, using-superset, faq) - `/admin-docs/` - Administrator docs (installation, configuration, security) - `/developer-docs/` - Developer docs (contributing, extensions, guidelines, testing) **Changes:** - Move installation, configuration, and security docs to admin_docs/ - Move contributing, extensions, guidelines, and testing to developer_docs/ - Rename developer_portal to developer_docs (with underscore to hyphen in URL) - Add sidebarAdminDocs.js for admin documentation navigation - Update versions-config.json with new doc sections - Update docusaurus.config.ts with new plugins and redirects - Update internal links in versioned docs (6.0.0) to use new paths - Keep user-facing content (databases, using-superset, faq) in main docs This separation makes it clearer which documentation is relevant for: - End users exploring and visualizing data - Administrators deploying and configuring Superset - Developers contributing to or extending Superset Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
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