Skip to content

Conversation

@Saadnajmi
Copy link
Collaborator

@Saadnajmi Saadnajmi commented Sep 22, 2022

EDIT: Refactored this PR to a different approach. Will update description shortly.

Platforms Impacted

  • iOS
  • macOS
  • win32 (Office)
  • windows
  • android

Description of changes

Related to #1035

One downside of switching a bunch of components' root slots' to Pressable is the type goes from IViewProps to PressableProps. The former includes the extra platform specific props. Let's try to fix that with PressablePropsExtended!

This change does a few things:

  1. Pulls out usePressableState and its types into their own files, so they are no longer sharing types / implementation with useAsPressable. This should make it easier to eventually deprecate the latter and make sure that components aren't accidentally using a type from useAsPressable (I had a lot of type issues from this mismatch)

  2. Refactors PressablePropsExtended to be kinda like what IViewProps is for ViewProps: ViewProps + the extra props from the desktop forks. I'll admit it's not the most elegant implementation, but I think it'll work for our purposes.

  3. Refactor Tabs / Experimental Tabs to use the new types. This is where I spent a lot of work to make sure none of the old I-prefixed types were still being used. I also went ahead and fixed some eslint hook warnings while I was at it.

Verification

CI should pass. Also can try locally applying change to others like #2147 to make sure the types work.

Pull request checklist

This PR has considered (when applicable):

  • Automated Tests
  • Documentation and examples
  • Keyboard Accessibility
  • Voiceover
  • Internationalization and Right-to-left Layouts

@Saadnajmi Saadnajmi changed the title [Draft] Introduce new adapter type IPressableProps Introduce new adapter type IPressableProps Sep 22, 2022
@Saadnajmi Saadnajmi marked this pull request as ready for review September 22, 2022 08:14
@Saadnajmi Saadnajmi requested a review from a team as a code owner September 22, 2022 08:14
@Saadnajmi Saadnajmi mentioned this pull request Sep 22, 2022
10 tasks
@rurikoaraki
Copy link
Collaborator

Given that there's also been two "ButtonProps / CheckboxProps / RadiogroupProps".. I'm not too worried about it.

Actually I'm fairly certain it's IButtonProps -> ButtonProps, ICheckboxProps -> CheckboxProps, etc... So you might want to make sure the name doesn't clash

@Saadnajmi Saadnajmi changed the title Introduce new adapter type IPressableProps Introduce new adapter type AdapterPressableProps Sep 22, 2022
@Saadnajmi Saadnajmi changed the title Introduce new adapter type AdapterPressableProps [Draft] Refactor PressablePropsExtended Sep 23, 2022
@Saadnajmi Saadnajmi marked this pull request as draft September 23, 2022 01:44
@Saadnajmi Saadnajmi marked this pull request as ready for review September 24, 2022 18:36
@Saadnajmi Saadnajmi changed the title [Draft] Refactor PressablePropsExtended Refactor PressablePropsExtended Sep 24, 2022
@Saadnajmi
Copy link
Collaborator Author

Saadnajmi commented Sep 24, 2022

@rurikoaraki I think I've gotten through the rest of the type errors. The main changes since your last review:

  1. I'm going with the name "PressablePropsExtended" because that type already existed and I'm reusing it.
  • If we like that name, in the future we could rename IViewProps -> ViewPropsExtended. We'll see though 😅
  1. The type exists in @fluentui-react-native/interactive-hooks rather than adapters to reduce the amount of copying I had to do in the short term while DefinitelyTyped updates. Mostly just didn't wanna copy PressableHoverProps.

@Saadnajmi Saadnajmi merged commit db03501 into microsoft:main Sep 26, 2022
@Saadnajmi Saadnajmi deleted the IPressableProps branch September 26, 2022 02:21
info.updateSelectedTabsItemRef && componentRef && info.updateSelectedTabsItemRef(componentRef);
}
}, []);
}, [componentRef, info, itemKey]);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

post commit review: Based on the comment I'm pretty sure the dependency array is meant to be empty, since the intent is to run it once post-render.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants