EditorCore API extension

[proteye]

PR Type

• [ ] Bug Fix
• [x] Feature Request

Description

Core api extension:

• toggleReadOnly(): Promise
• insertBlock(type?: string, data?: BlockToolData, config?: ToolConfig, index?: number, needToFocus?: boolean): Promise
• updateBlock(id?: string, data?: BlockToolData): Promise
• deleteBlock(index?: number): Promise
• setToFirstBlock(position: string, offset: number): Promise
• setToLastBlock(position: string, offset: number): Promise
• setToBlock(index: number, position: string, offset: number): Promise
• focus(atEnd: boolean): Promise
• openToolbar(): Promise
• closeToolbar(): Promise

[AlbinoGeek]

Why not just expose the API from @editorjs/editorjs directly, any particular reason?

[christoph-kluge]

@Jungwoo-An could you explain why you're against exposing the whole EditorJS api?

EditorJS exposes their API for their reasons and this package is restricting it. In my opionion a wrapper should add minimal effort to make it compatible and leave all the heavy-lifting mechanics to the underlying package.

I guess If you continue this way you'll end up maintaining every single low-level change and you might block and postpone adoption of new features because every single API change needs to be reflected in your wrapper resulting in more and more maintainance.

What are your plans to avoid those scenarios?

[proteye]

@christoph-kluge I agree. I don't see the point in just rewriting the EditorJS functionality into a layer library.

[AlbinoGeek]

It makes me wonder why this repository even hides the editor JS API in the first place, it has gotten me in places where I've had to consider whether we fork this, or implement our own react bridge for the original.

The biggest thing is the lack of react 18 support, where ReactDOM deprecated the render call. That means this package has very little chance of working after react 19.

But more on topic to this pull request, I support exposing the editor JS API directly if possible.

On Sun., May 8, 2022, 2:00 p.m. Ramil Zaynetdinov, @.***> wrote:

@christoph-kluge https://github.com/christoph-kluge I agree. I don't see the point in just rewriting the EditorJS functionality into a layer library.

— Reply to this email directly, view it on GitHub https://github.com/Jungwoo-An/react-editor-js/pull/192#issuecomment-1120486187, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOSNPNTZU4KCLUKH6I3CV3VJATOVANCNFSM5UHXWCZA . You are receiving this because you commented.Message ID: @.***>

[Jungwoo-An]

@christoph-kluge @proteye @AlbinoGeek Thanks for good opinion. It was impressive. I'll change the API

[Jungwoo-An]

To leave my original thoughts behind, I want to implement the isomorphism of react-editor-js. I thought it could be rendered not only in DOM, but also in Node, react-native, other.

I didn't think of react-editor-js as a simple wrapper of editor-js, I think it's a library that provides a higher level of API.

However, as a library, I think it's a good idea to provide better DX than to maintain high-level APIs sometimes. Although direct access to editor-js is now restricted, we are trying to come up with a way to access APIs that are not abstracted from react-editor-js. (Maybe editorCore.dangerouslyLowLevelInstance

What do you think? @christoph-kluge @proteye @AlbinoGeek

I will listen to many people's thoughts and create a new road map by reflecting them.

[Jungwoo-An]

I'm sorry for the late response.

[SalahAdDin]

@proteye could you check if the i18nAPI is being omitted by this package so you could include it?

It could be related to this issue.

Thanks