-
-
Notifications
You must be signed in to change notification settings - Fork 622
fix: File HTML export and resizing UX #1305
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
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
packages/core/src/api/blockManipulation/commands/moveBlocks/moveBlocks.test.ts
Outdated
Show resolved
Hide resolved
packages/core/src/api/clipboard/fromClipboard/pasteExtension.ts
Outdated
Show resolved
Hide resolved
packages/core/src/api/clipboard/fromClipboard/handleVSCodePaste.ts
Outdated
Show resolved
Hide resolved
packages/react/src/blocks/AudioBlockContent/AudioBlockContent.tsx
Outdated
Show resolved
Hide resolved
packages/react/src/blocks/VideoBlockContent/VideoBlockContent.tsx
Outdated
Show resolved
Hide resolved
- Renamed `DefaultFilePreview` to `FileNameWithIcon` - Made file `src` get set straight away only if `resolveFileUrl` is undefined
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.
awesome progress!
packages/react/src/blocks/FileBlockContent/fileBlockHelpers.tsx
Outdated
Show resolved
Hide resolved
packages/react/src/blocks/FileBlockContent/fileBlockHelpers.tsx
Outdated
Show resolved
Hide resolved
packages/react/src/blocks/ImageBlockContent/ImageBlockContent.tsx
Outdated
Show resolved
Hide resolved
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 if there are no major changes in the moved files (can't really easily review that as the diff doesn't show)
I liked the convenience of the default resolveFileUrl
, but don't think it's worth implementing a different option (e.g.: hasCustomResolveFileUrl: boolean
) as that doesn't seem great either (unless you have a better idea :) )
This PR fixes a few issues:
fix: Files don't have
src
attribute in HTML exportProblem
The
src
attribute for file blocks was not added when exporting to external HTML, since thesrc
would only be set after the download URL was resolved.Solution
The
src
attribute is now set toblock.props.url
ifeditor.resolveFileUrl
isn't defined, which will at least fix the issue for blocks which are not uploaded via the editor. Sinceeditor.resolveFileUrl
isasync
, we don't have a way of getting the correct URL when converting the block, which is done synchronously.fix: Images/videos throw error exporting to HTML using server editor
Problem
Exporting file blocks using the server editor would throw an error. This was because of a typing issue, as even though
_tiptapEditor
is not defined for theServerBlockNoteEditor
, you can still use all of its functions as if it was. The error was being thrown as the image blockrender
function was trying to access_tiptapEditor.view.dom
.Solution
Image/video block max widths are now constrained by CSS instead of the editor
DOMRect
, meaning they no longer need to access_tiptapEditor
.Also, the typing has been adjusted such that at least
_tiptapEditor.view
can be undefined, as this can even happen for the regular client editor. This is a small improvement, but we should look into a more robust typing fix in the future.feat: Improved image/video block resize handling
Problem
The width of image/video blocks is constrained to the width of the editor. This was done by checking if the width of an image/video block was wider than the editor
DOMRect
when rendering or resizing, then updating it if necessary. These updates were causing a number of issues.First, it was not great code-wise as clamping the width of image/video blocks could be accomplished using CSS instead.
Second, upon loading, images outside the viewport horizontally would become invisible, as the editor
DOMRect
width would be 0. So any images/videos would also also have their widths set to 0 to not be wider than the editor.Finally, image/video caption widths would only update once the user stopped resizing the image/video itself, leading to bad UX.
Solution
As mentioned in the previous issue, constraining the image/video block widths is now done with CSS. The
previewWidth
of file blocks is no longer limited to the width of the editor. Instead, the blocks' widths are now capped using a CSSmax-width
rule. SincepreviewWidth
no longer necessarily represents the visual width of a file block, the block'sreferenceRect
is used to get the actual width when resizing.This also fixes the second issue as we're no longer checking any
DOMRects
on initial render - we just set the width topreviewWidth
and CSS figures out if it needs to be clamped.Finally, the
FileAndCaptionWrapper
&ResizeHandlesWrapper
elements/components have been removed & restructured intoFileBlockWrapper
&ResizableFileBlockWrapper
.DefaultFilePreview
has also been renamed toFileNameWithIcon
for better clarity. The changes made both fix the caption resizing issue, and streamline the rendered output by getting rid of a few wrapper divs.TODO
ServerBlockNoteEditor
exporting file blocks to HTMLCloses #1036
Closes #1049
Closes #1309