Expose shouldCloseOnInteractOutside on Modal / ModalOverlay

[sookmax]

Closes #5916

In addition to the fix, I updated how Pick<> TS type is handled in DocsPackager.js.

In particular, the condition that I wrote last time to avoid some side effects (i.e., if (application[0]?.type === 'application')) was preventing the correct parsing of Pick<> when the expression doesn't involve generics (e.g., when the condition is present, something like Pick<AriaOverlayProps, 'shouldCloseOnInteractOutside'> wouldn't work whereas something like Pick<DatePickerStateOptions<T>, 'shouldCloseOnSelect'> would).

So by removing the aforementioned condition, a side effect such as the one described in the comment would come to life again unfortunately. I couldn't find a way to distinguish and process differently for such a case.

Without that condition it's the same as how Omit<> is processed. And yes, I checked Omit<> also suffers from the same side effects.

✅ Pull Request Checklist:

• Included link to corresponding React Spectrum GitHub Issue.
• Added/updated unit tests and storybook for this change (for new code or code which already has tests).
• Filled out test instructions.
• Updated documentation (if it already exists for this component).
• Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

Stories

• http://localhost:9003/?path=/story/react-aria-components--modal-interaction-outside-example&providerSwitcher-express=false&strict=true
• http://localhost:9003/?path=/story/react-aria-components--modal-interaction-outside-default-overlay-example&providerSwitcher-express=false&strict=true

Docs

• http://localhost:1234/react-aria/Modal.html#props

🧢 Your Project:

[snowystinger]

GET_BUILD

[rspbot]

Build successful! 🎉

• View the storybook
• View the storybook-17
• View the storybook-16
• View the documentation

[rspbot]

## API Changes

unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any', access: 'private' }
unknown top level export { type: 'any', access: 'private' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'identifier', name: 'Column' }
unknown top level export { type: 'identifier', name: 'Column' }
unknown type { type: 'link' }
unknown type { type: 'link' }
unknown type { type: 'link' }
unknown type { type: 'link' }
unknown type { type: 'link' }
unknown type { type: 'link' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }
unknown top level export { type: 'any' }

[snowystinger]

thanks for submitting!

[LFDanLu]

LGTM, thanks! We can try to dig into making the docs types processer better for the Pick as a followup

[sookmax]

@LFDanLu I'm not so sure if we can distinguish the case where we need the literal Pick<> from the case where we want to merge the Pick<> (most of the use cases) in the current docs-processing structure. I even tried to use one of the JS doc's tag @constant to label the literal Pick<> in the comment and process them differently, but failed to make it work 😭.

But maybe there's a way that I'm not aware of, and I'm all for correcting this docs-processing issue, so let me know if I can be of any help achieving that!