Radial bar components shifts the filled part relative to the unfilled background about recharts HOT 15 CLOSED

If you allow I made screenshots of what it looks like in recharts: 1.8.2:

And this is what it looks like in recharts: 2.12.2:

from recharts.

@PavelVanecek our developer had the idea that it's probably sub-pixel misalignment due to decimal numbers. We're using
cx="47%" and cy="45%" on the radial graphs, with a width and height of 340 and 280. The misalignment is happening here because 47% of 340 is a decimal number. If we change 340 to a number that has a whole number as 47% of it, then the issue goes away. This number worked for us is 340.4255319149

It seems the library is placing the bar on top using rounded numbers, but it's placing the background using decimals, hence the misalignment, or vice versa. Maybe this little investigation will help to find the reason and fix it?

from recharts.

Thank you for the details!

from recharts.

I can reproduce in this unit test:

  test('renders background in the exact same position as foreground', () => {
    // Reproduction of https://github.com/recharts/recharts/issues/4264
    const preparedData = [{ value: 42, fill: '#241084' }];
    const emptyBackgroundColor = '#D8BDF3';

    const { container, debug } = render(
      <RadialBarChart data={preparedData} height={280} width={340} cx="47%" startAngle={180} endAngle={0}>
        <RadialBar
          background={{
            fill: emptyBackgroundColor,
          }}
          dataKey="value"
          isAnimationActive={false}
        />
      </RadialBarChart>,
    );
    debug();
    const background = container.querySelector('.recharts-radial-bar-background-sector');
    expect(background).toBeInTheDocument();
    const foreground = container.querySelector('.recharts-radial-bar-sector');
    expect(foreground).toBeInTheDocument();
    expect(foreground.getAttribute('d')).toEqual(background.getAttribute('d'));
  });

from recharts.

Hey @AigiulGasymova

No update really, the last I looked for this was my last comment above.

I can't promise anything with when, it really depends on how much free time I have which is pretty random.

from recharts.

released in 2.12.3

from recharts.

It appears this is a change from 2.9 release (the one where I made my first contribution 😬 )

from recharts.

@PavelVanecek thanks for the screenshots! Yes, it appears that the issue started reproducing somewhere in the latest versions. Do we have some fixes or workarounds for this?

from recharts.

Looks to me like something that we should fix directly in recharts. Not sure what causes it yet. It looks to me like the problem is in the first X coordinate of path.d. Here in my codesandbox it is 65.3 in the foreground RadialBar but 64.5 in the background RadialBar (look for HTML attribute that goes d="M 64.5...":

If I edit it manually to be the same 64.5 then it renders fine:

Although when I open the same example in 2.8.0 (the working version) it appears that the 65.3000000001 was the correct one:

I still don't know which change in 2.9.0 caused this but hopefully this will help narrow it down

from recharts.

I have simplified the codesandbox a little bit, it no longer looks like a chart but I think it still demonstrates the problem: https://codesandbox.io/p/sandbox/recharts-issue-template-forked-94jylk

from recharts.

Thanks for helping here @PavelVanecek!

So maybe we started rounding at some point? I think I remember something like that..

from recharts.

The calculation itself - this logic hasn't changed n 9 years.

Path calculation for sector - also hasn't changed.

Most likely this PR https://github.com/recharts/recharts/pull/3803/files#diff-445315e1448c74882c065c4b50377b6231aadafa6b72dd3632b233e404c71e45R280 and specifically where we start parsing things as ints

from recharts.

@ckifer sorry to bother you, but is there any update on this issue? This issue is not urgent and does not have a significant impact on anything other than appearance, and we are considering using the fractional width workaround, but if a fix is coming soon, we'd rather wait for it.

from recharts.

Hey @AigiulGasymova

No update really, the last I looked for this was my last comment above.

I can't promise anything with when, it really depends on how much free time I have which is pretty random.

Sure, thanks for the answer (and for pretty cool and useful library!). We'll use the workaround and keep tracking this thread just in case!

from recharts.

PR #4295

from recharts.