<!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -->

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.
  • See: Component Style Guidelines and Best Practices
• 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.
  • See: SIP-37
  • See: Emotion Styling Guidelines and Best Practices
• 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 master branch is available here