-
Notifications
You must be signed in to change notification settings - Fork 247
feat(data-modeling): export diagram to png COMPASS-9449 #7055
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
Conversation
| // So, when exporting, we need to include those defs as well so that | ||
| // edge markers are exported correctly. |
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.
Wouldn't it be easier to hide what we don't need instead of doing this?
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.
Can we make this configurable in the diagramming package?
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.
Wouldn't it be easier to hide what we don't need instead of doing this?
I'll evaluate this, last time (in poc) i checked this, it did not give me good results.
Can we make this configurable in the diagramming package?
These custom marker are rendered here in the package. I am not sure if i follow what you mean by making it configurable?
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.
Sorry, comment somehow attached to the wrong place, should've been this part:
It excludes diagram title, minmap, and other UI elements
We're doing all this to avoid including controls in the diagram screenshot. Can we change diagramming package to allow us to render it with hidden controls? Then you don't need to do anything to target an element that doesn't include everything that you need
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.
ah, yeah that should be possible with the package. but again it depends on if we are able to export the root container (.react-flow) and if not, then maybe we don't need it.
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 tried to do this and was not able to get it to export correctly using this approach.
| waitForFileDownload, | ||
| } from '../helpers/downloads'; | ||
| import { readFileSync } from 'fs'; | ||
| import { recognize } from 'tesseract.js'; |
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.
For current changes in this file, I ended up doing png export e2e tests in this PR. While exploring OCR testing, wdio relies on tesseract.js. So i added it as a dep and as we are downloading an image, it makes sense to do it this way (as compared to using wdio api to read contents from an image on webpage).
I ran this test many time locally to ensure it does not fail randomly. Collection name changes in this file are mainly because it struggles to read testCollection1 (reads it as testCollectionl)
Also, when @paula-stacho's positioning PR lands, it will ensure that nodes don't overlap and we will not have any unexpected failing assertions.
packages/compass-data-modeling/src/components/export-diagram-modal.tsx
Outdated
Show resolved
Hide resolved
| ): Promise<string> { | ||
| return new Promise<string>((resolve, reject) => { | ||
| export function getExportPngDataUri(diagram: DiagramInstance): Promise<string> { | ||
| return new Promise<string>((resolve, _reject) => { |
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.
Is there a reason why we're going to the Promise resolve/reject here? I'm thinking it could lead to an uncaught exception. Could we instead have the cleanup in a finally or catch block?
We could do await something like the rafraf as well and await the toPng.
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.
What would you recommend in this case? I only want to resolve once dom has been converted to a data uri (and as such show loading state to the user). For clean up, its already in place where we export.
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 would recommend async/await here with try/catch. I find it makes the code easier to read through and the error handling less prone to be uncaught.
| }, [exportFormat, onCloseClick, model, diagramLabel]); | ||
| }, [onCloseClick]); | ||
|
|
||
| const onExport = useCallback(async () => { |
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 is way too much logic in the UI here (like if you see that you're keeping abort controllers in render, you probably should start thinking about that), this should really be an action in the store instead
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.
Yeah, i'll add another slice for export. Or, I can do it as a follow up if that sounds okay to you.
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.
Follow-up sounds good, let's not hold this code in the branch for too long 👍
| const diagram = useDiagram(); | ||
| const [isExporting, setIsExporting] = useState(false); | ||
| const abortControllerRef = useRef<AbortController | null>(null); | ||
| const toast = useToast(); |
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.
Use our openToast instead, not sure how are we even exporting this one, we really shouldn't
| })); | ||
|
|
||
| const reject = (error: Error) => { | ||
| document.body.removeChild(container); |
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.
Seems like we're missing clean-up on resolve, this should probably be in a finally block
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 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.
Sounds good!
i'll do a follow up to remove it from compass-components
Just FYI, I already did in eslint update PR, so no need to worry about this (was in the way of some new issues that update started to show there)
| expect(text).to.include('jint'); | ||
| // it does not correctly recognize `iString` and only returns `String`. | ||
| // its already good enough to verify this for now and if it flakes | ||
| // more, we may need to revisit this test. |
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.
that was unlucky naming on our part 😅 it'd be easier to OCR full words rather than lone letters, especially tricky ones like 'i'. now that it's used everywhere, I assume it'd be too much hassle to rename
gribnoysup
left a comment
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.
Looks good taking into account some follow-ups we're planning to do
| const viewportElement = container.querySelector( | ||
| '.react-flow__viewport' | ||
| ); |
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: instead of relying on arbitrary frames you can probably wait for this element to be in the view (similar to what we do in tests sometimes)
| })); | ||
|
|
||
| const reject = (error: Error) => { | ||
| document.body.removeChild(container); |
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: you don't need it here now that you have it in finally
Description
Checklist
Motivation and Context
Open Questions
Dependents
Types of changes