📊 Data visualization library for React based on D3

When bumping from 10.3.0 to 10.4.4 I encountered the following issue when building my project:

> Build error occurred
Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /home/runner/work/monorepo/monorepo/website/node_modules/d3-array/src/index.js
require() of ES modules is not supported.
require() of /home/runner/work/monorepo/monorepo/website/node_modules/d3-array/src/index.js from /home/runner/work/monorepo/monorepo/website/node_modules/reaviz/dist/index.cjs.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /home/runner/work/monorepo/monorepo/website/node_modules/d3-array/package.json.

Is this an ESM-first module now?

In my opinion, this should be clearly stated in the documentation.

Also, since this breaks backward compatibility (given the current JS ecosystem), I think this should warrant a major version change; not a minor one.

PR Checklist

Please check if your PR fulfills the following requirements:

• [ ] Tests for the changes have been added (for bug fixes / features)
• [ ] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Issue Number: N/A

Current label polyline coords calculation algorithm may produce odd results in some cases.

The lines may have completely wrong direction:

In other cases the lines have such trajectory, that it is difficult to understand exactly to which section the line points to:

What is the new behavior?

In this PR I have added an alternative algorithm for the case, when label position is lower, than pie chart outer radius centroid. So now we have two ways to draw label lines:

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

Please add hacktoberfest-accepted label if it is possible to merge this fix till the end of month :)

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Other... Please describe:

Current behavior

If a bar chart is further down in a longer page, the hover element showing the data values on the chart is rendered much below the chart, sometimes even extending below the length of the page, below the footer.

Expected behavior

It should always show these elements on the chart. Pie charts for example work fine.

Minimal reproduction of the problem with instructions

Create a page with a bar chart further down in it. UPDATE: codesandbox

What is the motivation / use case for changing the behavior?

Environment

Libs:
- react version: 16.13.1
- reaviz version: 8.1.3

Browser:
- [x] Chrome (desktop) version 83
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [x] Firefox version 77
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [x] Edge version 83
 
For Tooling issues:
- Node version: 13.8.0  
- Platform: Windows

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Other... Please describe:

Current behavior

This is a copy-paste from jask-oss original issue

When putting an SVG or SVG partial into the format property, they do not appear because they are put inside a title tag.

Expected behavior

Putting an SVG into the format property will render it properly (maybe even extend this to normal HTML with <foreignObject>.

Minimal reproduction of the problem with instructions

https://codesandbox.io/s/reaviz-bar-demo-x2b24

• Return an SVG inside the format property.
• SVG does not appear because it's embedded in a title

What is the motivation / use case for changing the behavior?

Having icons for labels instead of text can improve the look and feel of charts.

Hello,

first of all I would like to have a label hacktoberfest-accepted on this PR (I still hope to collect all the PRs till the end of month :sweat_smile:)

PR Checklist

Please check if your PR fulfills the following requirements:

• [x] Tests for the changes have been added (for bug fixes / features)
• [x] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

This PR implements custom label feature for pie chart (other chart will be implemented later in this or other PR). See #1

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Issue Number: #1

Currently you can only use text labels

What is the new behavior?

After this PR merged, the user will be able to use any React component as a label for pie chart.

Here are some screenshots:

Does this PR introduce a breaking change?

[ ] Yes
[x] No

PR Checklist

Please check if your PR fulfills the following requirements:

• [ ] Tests for the changes have been added (for bug fixes / features)
• [ ] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• [x] Refactoring (no functional changes, no api changes)

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Refactor BarChart component to Functional component.

Does this PR introduce a breaking change?

• [ ] Yes
• [x] No

Other information

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[X] Feature request
[ ] Documentation issue or request
[ ] Other... Please describe:

Current behavior

The Map component only supports a Mercator projection.

Expected behavior

It would be great if the Map component could optionally render as a Robinson projection-style chart.

For the version of d3-geo used in Reviz, the geoNaturalEarth projection is pretty close.

Minimal reproduction of the problem with instructions

Here's a test of this change in Storybook:

And the original Mercator projection for contrast:

I was able to smoke-test this by importing a the geoNaturalEarth1 projection function from d3-geo:

It would be a trivial addition to add an optional projection prop to MapProps to support this feature:

interface MapProps extends ChartProps {
  markers?: MarkerElement[];
  data: any;
  fill?: string;
  projection?: "mercator" | "natural-earth"
}

What is the motivation / use case for changing the behavior?

The Mercator projection inflates the size of objects further away from the equator - notably this results in Greenland being inflated significantly. It would be exciting for the Map component to have more versatility and I think supporting a more varied selection of projections would be an awesome place to start!

I'd be happy to raise a PR with this addition - let me know your thoughts, and thanks for all the terrific work on Reaviz!

PR Checklist

Please check if your PR fulfills the following requirements:

• [x] Tests for the changes have been added (for bug fixes / features)
• [ ] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Issue Number: #28

What is the new behavior?

Does this PR introduce a breaking change?

[ ] Yes
[x] No

PR Checklist

Please check if your PR fulfills the following requirements:

• [ ] Tests for the changes have been added (for bug fixes / features)
• [ ] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[X] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

[ ] Yes
[X] No

Other information

Refactor AreaSerias Dir to use React functional component.

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[ ] Feature request
[x] Documentation issue or request
[ ] Other... Please describe:

Current behavior

Using the current code and sample data from the CalendarHeatmap code at Reaviz Charts page gives the Error Uncaught TypeError: date.getFullYear is not a function. When instead passing the keys as Date objects, it renders. The docs and sample data should be updated to reflect this.

Fixes #88

Changes:

• Package type set to module
• calculate-size has been inline
• react-cool-dimensions import has been hardcoded to esm
• Changes a couple configs to use esm

Could you test that everything still works as expected when using this module with CommonJS? I wouldn't want to fix ESM but break CommonJS.

PR Checklist

Please check if your PR fulfills the following requirements:

• [ ] Tests for the changes have been added (for bug fixes / features)
• [ ] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?

Chart renders incorrectly when using StackedAreaChart without area and with brush and zoom

Issue Number: 21

What is the new behavior?

Fixed chat renders when using StackedAreaChart without area and with brush and zoom

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

https://user-images.githubusercontent.com/1290843/209805762-ebef457b-10bd-4984-b077-0595dd985cc1.mov

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Other... Please describe:

Current behavior

The Map component currently supports a single fill color for all features.

Expected behavior

It would be nice if we could pass a property key as the fill value alongside colorScheme and emptyColor as props in order to render fill colors based on the designated property value of each feature.

Minimal reproduction of the problem with instructions

I wasn't able to come up with a complete test, but I think this feature can be implemented by adopting some of the logic in the HeatMap component.

The getValueScale() function used by HeatMapSeries would have to be adjusted to indicate which property to use as the value since geojson doesn't conform to the standard ChartDataShape.

The resulting valueScale() function could then be passed to the renderCountry() callback in order to apply individual fill colors to each path.

What is the motivation / use case for changing the behavior?

Mapping scaled fill values to individual paths would allow users to build choropleth maps, which offer more informative data viz than the current single-color basemaps.

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Other... Please describe:

Current behavior

Scales from common/scales are not exported. The export is missing in /src/common/index.ts. This makes it harder to follow some of the docs (Bar chart axis examples) since getXScale and getYScale are not available to import.

Expected behavior

Scales are exported as part of the library

Minimal reproduction of the problem with instructions

import { getXScale } from "reaviz"

Error log:

export 'getXScale' (imported as 'getXScale') was not found in 'reaviz'

What is the motivation / use case for changing the behavior?

Easier to follow the documentation

Environment

Libs:
- react version: 18.2.0
- reaviz version: 13.1.13


Browser:
- [x] Chrome (desktop) version XX
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
For Tooling issues:
- Node version: 16.16.0  
- Platform:  Windows 

Others:

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[ ] Feature request
[x] Documentation issue or request
[ ] Other... Please describe:

Current behavior

Attempting to read the documentation on Histograms (Bar Chart > Vertical > Histogram > Dates or Numbers) but the documentation will display very briefly (only a second or so) and then disappear. Opening the Dev Tools shows errors in the console:

vendors~main.173cd315.iframe.bundle.js:6 Uncaught Error: Minified React error #185; visit https://reactjs.org/docs/error-decoder.html?invariant=185 for the full message or use the non-minified dev environment for full errors and additional helpful warnings.

This is occurring both in the Reaviz documentation (https://reaviz.io/?path=/docs/charts-bar-chart-vertical-histogram--numbers) as well as through Chroma. It occurs in Chrome, Brave, and Edge browsers as well as on Chrome mobile (Android).

Expected behavior

Should be able to read the documentation on Histograms

Minimal reproduction of the problem with instructions

• Step 1 - Navigate to the docs page: https://reaviz.io/?path=/docs/docs-intro--page
• Step 2 - Navigate to Charts > Bar Chart > Vertical > Histogram
• Step 3 - Click on either Dates or Numbers

What is the motivation / use case for changing the behavior?

Environment

N/A - Issue with the documentation

Libs:
- react version: X.Y.Z
- reaviz version: X.Y.Z


Browser:
- [x] Chrome (desktop) version 102.0.5005.115
- [x] Chrome (Android) version 102.0.5005.125
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [x] Edge version 102.0.1245.44
- [x] Brave version 1.39.122 Chromium: 102.0.5005.115
 
For Tooling issues:
- Node version: XX  
- Platform:  

Others:

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Other... Please describe:

Current behavior

When the treemap label is longer than it's rect, it doesn't wrap and instead just disappears.

Expected behavior

Labels wrap nicely.

Minimal reproduction of the problem with instructions

I've checked the current shape of the wrapText function here and while looping over the words, in lines 33 and 38 it always adds the word width to the sum. It then compares sumWidth to container width in line 52 and if we need wrapping, it's obviously longer, so it returns null. Since wrapText is used in different charts as well and I've just started using reaviz, I'm probably not the person to fix it so I don't cause any regressions.

const simpleData: ChartShallowDataShape[] = [
    {
      key: "Very long text, make it as long as necessary or shrink the treemap width so it's longer than the rect's width.",
      data: 1,
    },
    ]
    
     return <TreeMap
      height={400}
      data={simpleData}
      margins={20}
      series={
        <TreeMapSeries  />
      }
    />

Environment

Libs:
    "react": "17.0.2",
    "reaviz": "13.1.3"
Others: