* 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>
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:
- Before making code changes, run
npm run test:perf:baseline. This will generate baseline data. You only do this once for each change. - Make your code changes now
- 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. - 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.