@react-aria/slider: allow `direction` to be passed as a parameter in useSlider and useSliderThumb

[jeanpan]

🙋 Feature Request

Currently, useSlider and useSliderThumb use useLocale to get direction. I'd like to request a direction (or dir) parameter to be able pass in useSlider and useSliderThumb so that we don't need to reply on useLocale to get the direction for LTR/RTL.

🤔 Expected Behavior

If the direction parameter is provided, it override the direction of useLocale.

😯 Current Behavior

Current behavior is that we must use <I18nProvider> to specify locale for the direction.

💁 Possible Solution

Add an optional dir parameter in useSlider and useSliderThumb.

/**
 * Provides behavior and accessibility for a thumb of a slider component.
 *
 * @param opts Options for this Slider thumb.
 * @param state Slider state, created via `useSliderState`.
 * @param dir Direction for this Slider thumb.
 */
export function useSliderThumb(
  opts: SliderThumbOptions,
  state: SliderState,
  dir?: Direction
): SliderThumbAria {
  const { index, isRequired, isDisabled, validationState, trackRef, inputRef } =
    opts;

  const isVertical = opts.orientation === "vertical";

  let { direction } = useLocale();

  direction = dir ?? direction;
  ...
}

Same for useSlider. So we can use our theme direction.

const theme = useTheme();
const { thumbProps, inputProps } = useSliderThumb(
   {
     index,
     trackRef,
     inputRef
   },
   state,
   theme.direction
);

🔦 Context

Our system is using ThemeProvider with theme direction directly, it's difficult to convert direction to locale and use <I18nProvider>, so we can't make the useSlider and useSliderThumb work correctly for RTL. It would be great that if they have direction parameter to be more flexible to use.

I am not sure if there is any other way to make them work correctly for RTL, except using <I18nProvider>. Please let me know if there is a better way to do that.

If this proposed change makes sense to you guys, I am happy to prepare the pull request. Thank you. 🙇‍♀️

[snowystinger]

I'm not sure I follow your concern. Is it that we don't support enough scripts and langs?

react-spectrum/packages/@react-aria/i18n/src/utils.ts

Line 14 in 3bfb608

const RTL_SCRIPTS = new Set(['Arab', 'Syrc', 'Samr', 'Mand', 'Thaa', 'Mend', 'Nkoo', 'Adlm', 'Rohg', 'Hebr']);

Why are you going this direction convert direction to locale? I think I'm not understanding enough about your application if the direction is determining the locale.

Can you just make one I18nProvider at the root of your application and pass it the locale being used and let it determine RTL?

Otherwise we'd need to support this in a lot of components and you'd need to remember which ones to pass it to. Since this is something you should only need to figure out once, it'd be better if it was on the context.

[jeanpan]

@snowystinger, thanks for the reply.

Sorry, I didn't make it clear. We are not building the application but we are offering component library. Our component library currently only supports having direction for LTR/RTL, so if an application uses our library, it needs to provide the direction in our context provider. In our library, what we get is direction only and it's difficult to convert direction to locale and then use I18nProvider.

I understand that the difficulty to support this in many components. If we want to have it on the context, I wonder if it's possible that the direction in I18nProvider can be overridden?

[snowystinger]

That would definitely be better. Thank you for thinking about it more. I'm still not certain we want to allow for a direction that is against the locale though. I'll bring it up with the team.

[devongovett]

The locale is used for many things though, not just direction. E.g. number formatting is locale dependent. I imagine you'll need that in your library, if not now, then at some point in the future. It would be ideal if you could add it to your own provider. Only setting the direction without setting the locale might cause all sorts of weirdness.

A temporary workaround in case that's not possible would be to hard code two locales depending on the direction.

let locale = direction === 'rtl' ? 'ar' : 'en';

[ktabors]

Closing and we can reopen if it's still a problem.