Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type for Tooltip formatter function limits return type to input type #2976

Closed
dhulme opened this issue Sep 20, 2022 · 1 comment · Fixed by #3618
Closed

Type for Tooltip formatter function limits return type to input type #2976

dhulme opened this issue Sep 20, 2022 · 1 comment · Fixed by #3618
Labels
bug General bug label

Comments

@dhulme
Copy link

dhulme commented Sep 20, 2022

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

Type for Tooltip formatter function limits return type to input type:
(value: TValue, name: TName ....) => [TValue, TName] | TValue;

What is the expected behavior?

For formatting labels you may want to return a different type to the input, for example return string when a number is the input.

Which versions of Recharts, and which browser / OS are affected by this issue? Did this work in previous versions of Recharts?

Change was introduced by #2916 in 2.1.14. Prior to this version returning a different format to the input value was supported.

@ckifer ckifer added the bug General bug label label Sep 25, 2022
@natBizitza
Copy link

Having the same issue. I temporally allowed a union type there.

ckifer pushed a commit that referenced this issue Jun 12, 2023
## Description

1. The DefaultTooltipComponent is now a functional component.
2. The result of formatter function is either
   `[React.ReactNode, React.ReactNode]` or `React.ReactNode`, instead of
   being the same type as the inputs, because inputs can be transformed
   and the result of the format is eventually is rendered in the JSX, so
   its meaningful to le the user return anything that react accepts for
   rendering.
3. A story is added for a case of Tooltips that use click to show
    tooltip instead of hover with pointer.

## Related Issue

Fixes: #2976

## Motivation and Context

<!--- Why is this change required? What problem does it solve? -->

## How Has This Been Tested?

<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->

## Screenshots (if appropriate):

## Types of changes

<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->

- [X] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)

## Checklist:

<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->

- [X] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [X] All new and existing tests passed.
GMer78 pushed a commit to GMer78/recharts-1 that referenced this issue Nov 24, 2023
…s#3618)

1. The DefaultTooltipComponent is now a functional component.
2. The result of formatter function is either
   `[React.ReactNode, React.ReactNode]` or `React.ReactNode`, instead of
   being the same type as the inputs, because inputs can be transformed
   and the result of the format is eventually is rendered in the JSX, so
   its meaningful to le the user return anything that react accepts for
   rendering.
3. A story is added for a case of Tooltips that use click to show
    tooltip instead of hover with pointer.

Fixes: recharts#2976

<!--- Why is this change required? What problem does it solve? -->

<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->

<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->

- [X] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)

<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->

- [X] My code follows the code style of this project.
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [X] All new and existing tests passed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug General bug label
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants