feat(upload-extension): improve upload extension

[shlroland]

Description

Checklist

• I have read the contributing document.
• My code follows the code style of this project and pnpm fix completed successfully.
• I have updated the documentation where necessary.
• New code is unit tested and all current tests pass when running pnpm test.

Screenshots

[changeset-bot]

⚠️ No Changeset found

Latest commit: 59e02c3

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[ocavue]

If PlaceholderPluginMeta is just an array of PlaceholderPluginAction, it seems both the typing could be simpler (e.g. no Omit is needed anymore).

[shlroland]

Even though the type property in PlaceholderPluginMeta doesn't have much use, keeping it directly can make the code look a bit simpler. I'll have a try.

[ocavue]

Your change for setUploadPlaceholderAction looks good to me. I'm thinking maybe we can move it forward and add multiple files uploading feature to uploadFile, and maybe also relative places in the @remirror/extension-file. After all, setUploadPlaceholderAction is most like an internal API and most people won't use it directly.

[shlroland]

Your change for setUploadPlaceholderAction looks good to me. I'm thinking maybe we can move it forward and add multiple files uploading feature to uploadFile, and maybe also relative places in the @remirror/extension-file. After all, setUploadPlaceholderAction is most like an internal API and most people won't use it directly.

I agree with your perspective. It seems like we need to separate the functionality into three methods: add remove and update, to make them directly available for users to use.
The current uploadFiles is still functional, treating each file individually for uploading. If I understand correctly, you're asking if we should consider it as an array of files in the file-upload to achieve the uploading functionality, is that right?

[ocavue]

The current uploadFiles is still functional, treating each file individually for uploading. If I understand correctly, you're asking if we should consider it as an array of files in the file-upload to achieve the uploading functionality, is that right?

Current uploadFiles already support multiple files, by dispatching multiple individual transactions. With your change in this PR, we can achieve that within single transaction, which could bring better performance more or less.

I agree with your perspective. It seems like we need to separate the functionality into three methods: add remove and update, to make them directly available for users to use.

By using uploadFiles, the editor will trigger AddPlaceholderAction and RemovePlaceholderAction (when the uploading is done). Speaking of that, I would like to know in which scene people would want to use UpdatPlaceholderAction. We should write some kind of document, unit test, or a storybook story to show such scene.

[shlroland]

By using uploadFiles, the editor will trigger AddPlaceholderAction and RemovePlaceholderAction (when the uploading is done). Speaking of that, I would like to know in which scene people would want to use UpdatPlaceholderAction. We should write some kind of document, unit test, or a storybook story to show such scene.

I noticed your PR #2100. The modifications in this PR caused some of my current test cases to fail. So I think there is a tight coupling between the current upload-extension and file-extension, so I believe that the file-placeholder-plugin should exist as a plugin for file-extension rather than being a built-in extension.In this case, the file-placeholder-plugin can be used as a specific placeholder for the file-extension, while users can utilize the relevant methods from the decoration-extension when they need to use general placeholder functionality.

[shlroland]

Speaking of that, I would like to know in which scene people would want to use UpdatPlaceholderAction.

In my project, the use case for the upload-placeholder is in scenarios where asynchronous requests are needed. A typical example is when I need to call a backend API to re-sign copied resource nodes, ensuring that the permissions of the resource nodes are not compromised.

[shlroland]

It's worth noting that currently, the uploadImage in the image-extension is calling the placeholder method within the decoration-extension. When building rich text editor, the upload interfaces for images and files might often be the same, but they require adapting to two different upload logics, which can be confusing. Perhaps we should find a way to unify these two upload logics while keeping compatibility.