Skip to content
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

Merged
merged 2 commits into from
Nov 4, 2024

Conversation

greg-in-a-box
Copy link
Contributor

image

@greg-in-a-box greg-in-a-box force-pushed the previewdialog branch 3 times, most recently from 411fa0b to aaa6b3a Compare October 7, 2024 22:50
@greg-in-a-box greg-in-a-box marked this pull request as ready for review October 7, 2024 22:55
@greg-in-a-box greg-in-a-box requested review from a team as code owners October 7, 2024 22:55
jpan-box
jpan-box previously approved these changes Oct 7, 2024
Copy link
Contributor

@tjuanitas tjuanitas left a 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
Copy link
Contributor

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

Copy link
Contributor

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?

Copy link
Contributor

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 {
Copy link
Contributor

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 {
Copy link
Contributor

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

Copy link
Contributor Author

@greg-in-a-box greg-in-a-box Oct 8, 2024

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

Comment on lines 2 to 15
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;
}
Copy link
Contributor

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;
Copy link
Contributor

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

jpan-box
jpan-box previously approved these changes Nov 4, 2024
Comment on lines +31 to +37
onCancel: any,
onDownload: any,
onPreview: any,
parentElement: HTMLElement,
previewLibraryVersion: string,
requestInterceptor?: Function,
responseInterceptor?: Function,
responseInterceptor?: any,
requestInterceptor?: any,
Copy link
Contributor

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

Copy link
Contributor Author

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

Comment on lines 66 to 68
if (onPreview) {
onPreview(cloneDeep(data));
}
Copy link
Contributor

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?

Comment on lines 26 to 27
// eslint-disable-next-line @typescript-eslint/no-explicit-any
onPreview: (data: any) => void;
Copy link
Contributor

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

Comment on lines 78 to 85
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}
Copy link
Contributor

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';
Copy link
Contributor

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';
Copy link
Contributor

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`}
Copy link
Contributor

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?

Comment on lines 6 to 4
// @ts-ignore
import APICache from '../../../utils/Cache';
Copy link
Contributor

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 });
Copy link
Contributor

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

Comment on lines +20 to +21
// eslint-disable-next-line @typescript-eslint/no-explicit-any
render: (args: any) => {
Copy link
Contributor

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

@mergify mergify bot merged commit a426f57 into box:master Nov 4, 2024
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants