spdev3000 commented 3 months ago

This PR adds a way to use fill-start="0" as reference point as well as respecting a provided normalization function to correctly calculate fill offset and length.

Description

First check, if we really just have the attribute fill-start provided with no number value, if so, use centered point of track like before. For all other number values, use normalization function of model of active handle to calculate real fill-offset and fill-length.

Related issue(s)

4559

Motivation and context

2 current problems:

Currently fill-start attribute only allows to set values !== 0, but sometimes clients have sliders with min<0 , so for example: min="-100", max="200" - so we need a possibility to define fill-start="0" to not start from centered track position
Also currently the fill-start calculation doesn't respect any provided normalization function, so we'd like to calculate all fill-related values (offset + length) by a given normalization function of model of active handle

How has this been tested?

2 new test cases have been added into slider.stories.ts as well as into slider.test.ts

Screenshots (if appropriate)

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Chore (minor updates related to the tooling or maintenance of the repository, does not impact compiled assets)

Checklist

[x] I have signed the Adobe Open Source CLA.
[x] My code follows the code style of this project.
[x] If my change required a change to the documentation, I have updated the documentation in this pull request.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.
[x] I have reviewed at the Accessibility Practices for this feature, see: Aria Practices

Best practices

This repository uses conventional commit syntax for each commit message; note that the GitHub UI does not use this by default so be cautious when accepting suggested changes. Avoid the "Update branch" button on the pull request and opt instead for rebasing your branch against main.

github-actions[bot] commented 3 months ago

Branch preview

Visual regression test results

github-actions[bot] commented 3 months ago

Tachometer results

Chrome

## slider [_permalink_](#user-content-slider) ### test-basic | Version | Bytes | Avg Time | vs remote | vs branch | |---|---|---|---|---| | npm latest | 480 kB | 74.24ms - 76.13ms | - | faster ✔
1% - 5%
1.05ms - 3.77ms | | branch | 467 kB | 76.62ms - 78.58ms | slower ❌
1% - 5%
1.05ms - 3.77ms | - |

Firefox

## slider [_permalink_](#user-content-slider) ### test-basic | Version | Bytes | Avg Time | vs remote | vs branch | |---|---|---|---|---| | npm latest | 480 kB | 161.54ms - 168.66ms | - | faster ✔
1% - 6%
1.28ms - 10.28ms | | branch | 467 kB | 168.13ms - 173.63ms | slower ❌
1% - 6%
1.28ms - 10.28ms | - |

Rajdeepc commented 3 months ago

@spdev3000 Can you also add some documentation around it! That would be very helpful to let the consumers know about the flexibility to use the min-max ranges from -ve minimum values. Also can you make sure the storybook and the documentation links are not broken as here