meshai/work/dashboard-frontend/node_modules/recharts/CONTRIBUTING.md
malice 2c46c9104d
feat(region-routing): unified per-family routing cards + region-scoped family→channel routing (#87)
* feat(region-routing): P1 tagging + region_routes primitive + read/write API + preview launcher

- config.py: add Coverage.region_tagging (bool=False); add RegionRouteMatrix
  dataclass (enabled, cells) above NotificationsConfig; add region_routes field
  to NotificationsConfig; add explicit hydration branch for region_routes in
  _dict_to_dataclass mirroring destinations pattern.

- coverage_area.py: add MonitoringArea.name (str|None=None, frozen); update
  areas_from_config to preserve name; refactor inline geom extraction from
  classify_event_areas into shared _event_geom_json helper; add
  matching_area_names(geom_json, areas)->list[str] (additive, all named
  matches, config-order, deduped; gate unchanged); add event_region_names
  convenience wrapper.

- coverage_filter.py: add region_tagging ctor kwarg; stamp event.region/
  regions before the gate when region_tagging=True and areas non-empty and
  not event.regions (never clobbers satpass preset).

- pipeline/__init__.py: wire region_tagging into CoverageFilter construction.

- notification_routes.py: add GET /notifications/regions (named coverage area
  names, config-order, deduped); GET /notifications/region-routing (matrix as
  JSON); POST /notifications/region-routing (explicit RMW — only region_routes
  changes, toggles/rules/destinations survive).

- scripts/preview_dashboard.py: mesh-free launcher — dashboard API only, no
  mesh connector, no broadcast loop; vite runs separately.

All 87 coverage tests pass; 300 total pass; 6 pre-existing failures unchanged
(adapter config count mismatch + MeshCore EventType.NEW_CONTACT).

* feat(region-routing): manual region x family matrix editor page

Adds RegionRoutingMatrix.tsx — a plain editor over the region_routes
config primitive. Rows = families (via useFamilies()), cols = regions
(from GET /api/notifications/regions). Each cell exposes MT channel
(ChannelPicker single + includeDisabled), MC channel name (text input),
min_severity select (routine/priority/critical/immediate), and an enabled
checkbox. Only cells where MT or MC is set are included in the sparse
POST payload. Master enable toggle maps to top-level enabled. MT budget
guard warns when more than 7 distinct MT indices are in use. Sticky
family column; horizontal scroll for wide region sets.

Registers route /region-routing in App.tsx and adds "Region Routing"
nav entry (Map icon) under the Meshtastic section in Layout.tsx,
immediately after Routing.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* fix(region-routing): regions endpoint reads saved (disk) coverage so routing columns are dynamic without a bot restart; preview reloads config after writes

* feat(routing): unify MT/MC routing into per-family cards; region routing as an in-card expand; remove rules/destinations UI + standalone page

* refactor(routing): move Meshtastic Routing from /notifications to /meshtastic/routing (mirror /meshcore/routing); redirect legacy path

* feat(region-routing): dispatcher honors region_routes matrix (authoritative-on-match, per-region cooldown, per-channel dedup); non-matrix path unchanged

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(region-routing): matrix dedup key must match boot-restore 2-tuple form (prevents restart re-broadcast flood); regression test

---------

Co-authored-by: Matt Johnson <mj@k7zvx.com>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-07-07 16:52:03 -06:00

4.7 KiB

Contributing to Recharts

We'd love for you to contribute to our source code and to make Recharts even better than it is today! Here are the guidelines we'd like you to follow:

Ongoing Initiatives

We use Github Discussion to organize our discussion along new initiatives and organize ourselves. Please do check the announcements section for an overview of recent initiatives.

Issues and Bugs

Where to Find Known Issues

We will be using GitHub Issues for our bugs and feature requests. We will keep a close eye on this and try to make it clear when we have an internal fix in progress. Before filing a new task, try to make sure your problem doesn't already exist.

Reporting New Issues

The best way to get your bug fixed is to provide a reduced test case. codesandbox provide a way to give live examples. You can fork our example in recharts.org to show your case.

Testing

We do cherish tests. They help us move swiftly, and release with confidence. In our repo, you will find three types of tests: Unit tests, rendering tests with RTL, and user interaction tests in storybook. Wherever possible we prefer the simplest tests - unit tests. Only where needed / useful we would use RTL or storybook tests.

Unit tests

When implementing a new feature we would prefer to extract pure helper function for data processing. Such functions are found a few utils files. An example is test/util/ShallowEqual.spec.ts

React Testing Library

Some behaviour must be tested upon rendering, such as interactions between components (Line, Tooltip), see test/component/Tooltip.spec.tsx for an example.

Storybook Test Runner

Storybook also has a great interface for adding tests. By default every story in storybook is a smoke test (rendering without error logs means the test passed). Additionally, it is possible to add actual tests as play functions with an assert to a story. This will often be easier than using React Testing Library, because the natural test debugging tool is Storybook itself. See for example storybook/stories/Examples/cartesian/ReferenceLine/ReferenceLineIfOverflow.stories.tsx

Performance tests

Recharts uses (https://callstack.github.io/reassure/)[Reassure] to run performance tests. Here is how to use:

  1. Before making code changes, run npm run test:perf:baseline. This will generate baseline data. You only do this once for each change.
  2. Make your code changes now
  3. Run npm test:perf. Reassure will run tests again, compare with the baseline from step 1. and print results to the console. If you wish you can also review the results in a markdown file in path ./reassure/output.md.
  4. If you are satisfied with the performance impact then go ahead and commit! If you wish to make more changes go back to step 2.

Reassure will look for *.perf-test.tsx files by default.

Also be aware that the performance tests might take a long time to run; up to several minutes.

Pull Requests

Working on your first Pull Request? You can learn how from this free series How to Contribute to an Open Source Project on GitHub

Before submitting a pull request, please make sure the following is done…

  • Search GitHub for an open or closed Pull Request that relates to your submission. You don't want to duplicate effort.

  • Fork the repo and create your branch from master.

  • If you have added functionality or changed existing functionality, be sure to add a test. Ideally a unit test for helper function, or a test that includes rendering with RTL.

  • If you've changed APIs, make sure that the stories in Storybook are working as expected.

  • Ensure the test suite passes (npm run test).

  • Make sure your code lints (npm run lint) - we've done our best to make sure these rules match our internal linting guidelines.

Code Guide

Our linter will catch most styling issues that may exist in your code. You can check the status of your code styling by running: npm run lint

However, there are still some styles that the linter cannot pick up. If you are unsure about something, looking at Airbnb's Style Guide will guide you in the right direction.

License

By contributing to Recharts, you agree that your contributions will be licensed under its MIT license.