2.0.0 Stable Release Discussion

[bdbch]

2.0.0 is finally out and I'm happy to hear about your experiences, ideas and feedback. In this thread you can discuss everything related to Tiptap 2.0.0 and Tiptap Pro 2.0.0.

[amirhhashemi]

Hey there. Thank you for all the hard work. Happy that it finally became stable.

Now that it's stable and the APIs are not going to change I think it's a good idea to add more examples for real-world use cases. For example, I've been struggling with image uploading for as long as I remember. I haven't played with TipTap lately but I'm going to in a future project and I still don't have a good idea of how to implement image uploading with a smooth loading placeholder. I see a lot of people struggling with this in the discord too.

I've seen some examples of this in projects like Think and Typist and I've implemented it myself in my past projects (though I'm not satisfied with the implementation) but still, it would be great to have an official example, especially for newcomers because it's likely something they are gonna implement in their projects. I understand that it depends on the backend but a minimal example would be great.

[bdbch]

Hey @ahhshm thanks!

We've already thought about adding demos / showcases for real-world use cases (for example comment sections, text editors, chat apps, etc.) in the future to show how Tiptap can be used / integrated into apps.

Image uploads are still tricky. We experimented on some apps with this and for the project we fall back to rendering different nodes for Uploads and Images. What I want to try next is to use Node decorations to show an uploader / spinner on the client side only while an image is uploading to see if this is a better solution.

Since collaboration is a big thing with Tiptap using a Node for uploads is a bit weird as other users would also see upload nodes in their editors.

What exactly would you struggle with the most when it comes to asset uploading? Rendering the spinner / uploader - the upload logic itself or something else?

[amirhhashemi]

My biggest question is where to run the upload logic?

1. The image input event handler? For example, we could have <input> element that gets an image from the user's filesystem and runs the onChange event handler. Then we can upload the image in the onChange function and then insert the image node. Implementing a loading spinner would be hard in this scenario because we should insert the spinner before we start uploading and remove it before we insert the image.
2. The command that inserts the Image node. We could upload the image inside the command that inserts the Image node (editor.commands.insertImage()). This way we can add a loading attribute that indicates whether the image is uploaded or not and easily change it in the command. With the help of a NodeView we can show a loading spinner when loading = true. The problem is that the upload logic is most likely async and commands can't be async.

Also the spinner shouldn't be in the HTML output. I'm not sure how to prevent that.

[bdbch]

1. Using an input is valid here. We did the same + we also registered paste and drop handlers to handle file uploads into the document at specific positions. I'd have a few ideas how to solve this loading spinner issue via Decorations but I'll need to test this for myself though. For the upload logic - I think you should have an onChange handler, that handles the insertion of a decoration / node for the loading spinner at the target location, then upload the image to a server / location of your choice and after successfully uploading the image and having the image url you could replace the range of the decoration/node with the image node
2. I think the insertImage command should be simple. The upload logic should not be done in the command as the upload is not directly part of the editor. For me I usually only setup commands when I want to do something with the editor state. As I described before onChange => editor.commands.insertUploadPlaceholder() => uploadImage(file) => editor.commands.insertImage(url) or something similar to that.

In the end I agree that we should have a few reallife use cases setup as demos.