Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
85 lines (57 loc) · 3.52 KB

CONTRIBUTING.md

File metadata and controls

85 lines (57 loc) · 3.52 KB

Contributing to Mantine React Table

Suggesting New Features or Bug Fixes

Before making large PRs, you may want to discuss your proposals in either the Discord Contributing Channel, the GitHub Discussions page, or the GitHub Issues page.

Running the project locally

This project uses PNPM and a TurboRepo with 2 projects.

  • The library itself in /packages/mantine-react-table which also contains a storybook site for local development
  • The docs site in /apps/mantine-react-table-docs

1. Fork and Clone the project

Create your own fork, clone, and then make a feature/bugfix branch off of main. Branch name does not really matter.

2. Install Dependencies

pnpm i

3. Run the project(s)

Run the Storybook for Local Development

pnpm storybook

The Storybook site will open on port 6007 by default.

Run the Docs for Local Development

pnpm docs:dev

The Docs site will open on port 3001 by default.

Note: If you are contributing a new locale and are trying to test it in the docs site, you will need to run pnpm lib:build-locales and then pnpm docs:dev before it can be imported.

See Library Live Changes While Running Docs

If you are just using Storybook for local development you don't need to do this, but if you want to see library code changes while running the docs you'll need to have the library run in watch mode:

In a 2nd terminal, run:

pnpm lib:dev

Alternatively, you can just run pnpm dev in just 1 terminal and both the library and docs will run in dev mode for development

Fully Build the Library

pnpm lib:build

Note: After building the library, if you are running the docs site locally, it will use the compiled output of the dist folder. This can be annoying if you are trying to test changes to the library in the docs site itself. Just delete the /dist folder to test lib changes in the docs site.

Library Code Style Guide

  1. All styles should be written in .module.css files with a file name that matches the component.tsx file name.
  2. All dynamic styles should be handed with CSS variables (__vars prop)
  3. CSS variables should be named --mrt-<component/element-name>-<property-name> (e.g. --mrt-tbody-display) in order to avoid name collisions with elements down the tree.
  4. Class names in .module.css files don't really matter since they get compiled away, but just use all lowercase and hyphenated (e.g. table-cell). Just use .root for the root element, and use other names that make sense for sub-elements.
  5. All major elements in internal MRT components should have an mrt-<component/element-name> class name (e.g. mrt-table-body-cell).
  6. Always use the clsx utility to assign class names to elements. Always allow for mantine*Props.className to be passed in and merged with the internal class names. For example
className={clsx('mrt-table-body', classes.root, tableBodyProps.className)}`
  1. When assigning __vars or styles, don't forget to spread ...mantine*Props.__vars in order to allow for external variables to be passed in and merged with internal variables. For example
__vars={{
  '--mrt-table-body-cell-padding': '10px',
  ...tableBodyProps?.__vars,
}}