Skip to content

Conversation

@ClementEXWiki
Copy link

Jira URL

https://jira.xwiki.org/browse/CRISTAL-743

Changes

Description

  • Expose an API to override the image insertion UI that is called when inserting a new image from blocknote-headless

Clarifications

N/A

Screenshots & Video

N/A

Executed Tests

N/A

Expected merging strategy

  • Prefers squash: Yes
  • Backport on branches:
    *

@manuelleduc
Copy link
Contributor

@ClementEXWiki shouldn't the Jira issue be moved in the XWIKI project, and the PR name updated accordingly?

export function extractMacroRawContent(content: InlineContent<DefaultInlineContentSchema, DefaultStyleSchema>[]): string;

// @beta
export type ImageEditionOverrideFn = (image: BlockOfType<"image">, update: (newProps: Partial<BlockOfType<"image">["props"]>) => void) => void;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WDYT about making this an async function instead, that returns a Promise<Partial<BlockOfType<"image">["props"]>>. If the promise is rejected it means the user has canceled the image edit. Otherwise, if the promise is resolved then the editor will use the resolved image properties to update the image.

I'm wondering if we need to have access to the image block or if the image properties are enough as input. I'm tempted to say that having the image properties as input is enough, because the goal is to edit those properties. The only use case I have in mind when the image block might be useful is if we want to display a popover instead of a modal, in which case we may need the position of the image block on the screen. But we'll start with a modal for sure. WDYT?

if (imageEditionOverrideFn) {
imageEditionOverrideFn(currentBlock, updateImageProps);
} else {
setShowLinkEditor(true);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You open the link editor because there is no dedicated image editor yet on Cristal side, right?

/**
* Overrides for default behavior
*
* @since 0.26
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll have to use XWiki versions now, right? So 18.0.0RC1.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely! Also, I have kept the existing @since annotations when moving the code, but I'm going to update all of them to 18.0.0RC1 as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants