-
Notifications
You must be signed in to change notification settings - Fork 307
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
chore(content-explorer): Migrate previewDialog #3702
Conversation
greg-in-a-box
commented
Oct 7, 2024
411fa0b
to
aaa6b3a
Compare
aaa6b3a
to
3ec6d98
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
based on testing, the blueprint modal doesn't seem like a straight replacement for react-modal in this case
<Modal onOpenChange={onCancel} open={isOpen}> | ||
<Modal.Content aria-label={formatMessage(messages.preview)} container={parentElement} size="xlarge"> | ||
<ContentPreview |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there's an important behavior change when using the blueprint modal (this applies to the other CE dialogs as well):
the blueprint modal renders on top of the entire webpage while the react-modal was contained to only the container space of the element
for example, if an app has multiple elements on one page (such as ContentPicker and ContentExplorer and maybe some form inputs) then opening preview in a blueprint modal hijacks the entire page instead of rendering over just the ContentExplorer element
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this modal also doesn't seem to work well with the dropdown menu or tooltips. have you tested this with sidebar?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think due to the above issues, it might be worth sticking with react-modal for element dialogs
@@ -0,0 +1,16 @@ | |||
[class^='bp_modal_module_content'].bce-PreviewDialog { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bce-PreviewDialog
isn't added to the component
@@ -0,0 +1,16 @@ | |||
[class^='bp_modal_module_content'].bce-PreviewDialog { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can't rely on class name or specificity as a long term solution
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you have a suggestion in mind about this? VRTs should fail in either case though
position: fixed; | ||
top: 0; | ||
right: 0; | ||
z-index: 1000; | ||
display: grid; | ||
max-width: 100%; | ||
max-height: 100%; | ||
margin: 0; | ||
inset: 0; | ||
border-radius: 0; | ||
|
||
.be.bcpr { | ||
height: 100vh; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
position: fixed
and height: 100vh
have same concerns as the other comment about the change in behavior for this modal. these properties will hijack the entire page outside of the element
position: fixed; | ||
top: 0; | ||
right: 0; | ||
z-index: 1000; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
z-index
is pretty fragile, id avoid updating if possible. we'd have to test against how it interacts with other floating components like tooltips, dropdowns, selects, datepicker, flyout, annotations, etc
28d5e73
to
f095b0e
Compare
f095b0e
to
5b1fc0a
Compare
onCancel: any, | ||
onDownload: any, | ||
onPreview: any, | ||
parentElement: HTMLElement, | ||
previewLibraryVersion: string, | ||
requestInterceptor?: Function, | ||
responseInterceptor?: Function, | ||
responseInterceptor?: any, | ||
requestInterceptor?: any, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Function
-> any
seems backwards in terms of helpfulness
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thats the codemods doing, if i recall correctly
if (onPreview) { | ||
onPreview(cloneDeep(data)); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
onPreview
isn't an optional prop so is this guard necessary?
// eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
onPreview: (data: any) => void; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unknown
rather than any
? otherwise we should do something about this eslint rule
isOpen={isOpen} | ||
parentSelector={() => parentElement} | ||
portalClassName={`${CLASS_MODAL} be-modal-preview`} | ||
className={CLASS_MODAL_CONTENT_FULL_BLEED} | ||
overlayClassName={CLASS_MODAL_OVERLAY} | ||
contentLabel={formatMessage(messages.preview)} | ||
onRequestClose={onCancel} | ||
appElement={appElement} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: sorting
type Props = { | ||
import messages from '../common/messages'; | ||
|
||
import './PreviewDialog.scss'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this file exist?
import messages from '../common/messages'; | ||
import ContentPreview from '../content-preview'; | ||
|
||
import ContentPreview, { ContentPreviewProps } from '../content-preview'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
technically i think ContentPreviewProps
needs to be imported as a separate type for flow files
<Modal | ||
isOpen={isOpen} | ||
parentSelector={() => parentElement} | ||
portalClassName={`${CLASS_MODAL} be-modal-preview`} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need be-modal-preview
?
// @ts-ignore | ||
import APICache from '../../../utils/Cache'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whats the ts error?
|
||
test('does not call onPreview with cloned data on load', () => { | ||
const data = { id: '1', type: 'file' }; | ||
renderComponent({ onPreview: null }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
when does this scenario happen? onPreview
is required in PreviewDialog and has a default prop passed from ContentExplorer
5b1fc0a
to
ecc3697
Compare
// eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
render: (args: any) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should do something about this too. no point in having the rule if we're just disabling it