Improved docs for custom fieldtype richtext field using tiptap about storyblok HOT 18 OPEN

Thanks for the insight @katerlouis. I understand that our richtext solution might not fit everyone, but the goal is to make it as universal usable as possible. You make some good points though about needing a custom solution and I think it makes even more sense, if the content is not within a website, but maybe a mobile framework. That said, building a custom richtext editor is quite complex and I would not advise it to most clients, just because of the sheer amount of implementation work. My hope is that in the future we can build some kind of bridge for our clients to build their own extensions through https://tiptap.dev/guide/custom-extensions and then use that within our richtext editor.

from storyblok.

I want this too! For example sup and sub-script is not available right now.

from storyblok.

Hi @SebbeJohansson, yes we're looking into adding emoji and coloring support, I expect it will come within the next quarter

from storyblok.

Thanks for the insight @katerlouis. I understand that our richtext solution might not fit everyone, but the goal is to make it as universal usable as possible. You make some good points though about needing a custom solution and I think it makes even more sense, if the content is not within a website, but maybe a mobile framework. That said, building a custom richtext editor is quite complex and I would not advise it to most clients, just because of the sheer amount of implementation work. My hope is that in the future we can build some kind of bridge for our clients to build their own extensions through https://tiptap.dev/guide/custom-extensions and then use that within our richtext editor.

Thats a fair point; but that doesn't justify the lack of documentation on HOW to get started with a custom tiptap field after mentioning that it's possible.

So my suggestion (or my request even) would be to either remove this part of the docs, or flesh it out more. To me, and I know thats subjective, theres not much more frustrating in the dev world than ambiguous misleading, outdated or just false docs. We all work on multiple projects, with varying tech stacks. The web is driven by third party tools, using other third party tools etc.– Good documentation is vital these days.

If you decide to flesh it out: Why not provide a working boiler-plate with the bare minimum of functions, or maybe even the entire functionality of the storyblok tiptap field so that the developer can just alter that in a custom field?

from storyblok.

Yeah, as mentioned in #422, this is quite important to document and get right. Currently there are a lot of open questions and the documentation fails far short of the expected standard of a production tool like Storyblok, in this area.

from storyblok.

Extending the tiptap should probebly be a future live stream from storyblok.

Great idea, but just to clarify: I'm not talking about extending the existing tiptap field, but creating your own custom one, which the docs state is fairly easy. I got it to work since then with some minor caveats, but the flexibility we get is worth it.

@katerlouis, I would say the documentation is bad for both of those situations. 😁

from storyblok.

Hi @katerlouis, thank you for this suggestion. We're planning to make improvements to the richtext field and adding some more extensions like sub and superscript, which is already in development. Can you tell me the reason what you're missing the in the current richtext field, that makes you want to build your own field?

We needed a lot more from our richtext field, but most of it is arguably highly subjective. What I think everybody would benefit from:

• different kinds of unordered lists (basically classes inside a dropdown for ul)
• different kinds of ordered lists (basically classes inside a dropdown for ol)
• different text sizes
• coloring / highlighting / marking text sections

I hear you say: "Have you seen 'class options' in the fields settings?" to which I say: yes, I have; but we needed different classes PER NODE; sharing classes between headlines, paragraphs, links and lists is just not realistic and introduces a lot potential for human error;

That being said: I'm certainly just not the target group for an all-in-one solution richtext field. Thats why I was so happy to read about the ability to just make my own richtext field, which was quickly followed by disappointment due to a lack of documentation on how to get started.

We've solved almost all issues since then; we even built our own custom link-dialog, that unfortunately had to fit inside the tiny space provided by the iframe of the field plugin.

For those interested what we came up with:

from storyblok.

Extending the tiptap should probebly be a future live stream from storyblok.

from storyblok.

Extending the tiptap should probebly be a future live stream from storyblok.

Great idea, but just to clarify: I'm not talking about extending the existing tiptap field, but creating your own custom one, which the docs state is fairly easy. I got it to work since then with some minor caveats, but the flexibility we get is worth it.

from storyblok.

Extending the tiptap should probebly be a future live stream from storyblok.

Great idea, but just to clarify: I'm not talking about extending the existing tiptap field, but creating your own custom one, which the docs state is fairly easy. I got it to work since then with some minor caveats, but the flexibility we get is worth it.

Have you got a working example of how you did this in Storyblok? I found no documentation on this. You mean you replaced the default rich text editor in the dashboard and have full customisation unlocked?

from storyblok.

Extending the tiptap should probebly be a future live stream from storyblok.

Great idea, but just to clarify: I'm not talking about extending the existing tiptap field, but creating your own custom one, which the docs state is fairly easy. I got it to work since then with some minor caveats, but the flexibility we get is worth it.

@katerlouis, I would say the documentation is bad for both of those situations. 😁

Exactly, it is very bad for both cases either way and should be addressed by the storyblok team ASAP.

from storyblok.

Extending the tiptap should probebly be a future live stream from storyblok.

Great idea, but just to clarify: I'm not talking about extending the existing tiptap field, but creating your own custom one, which the docs state is fairly easy. I got it to work since then with some minor caveats, but the flexibility we get is worth it.

Have you got a working example of how you did this in Storyblok? I found no documentation on this. You mean you replaced the default rich text editor in the dashboard and have full customisation unlocked?

I did and am currently working on it. It's more work than I expected to be honest. All the flexibility comes at the cost of having to actually make everything. And a huge disadvantage is not being able to "break out of the iframe" in which the field type plugin lives. Why do I want that? Well.. storybloks Link-Dialog cannot be used compared to how one can use the sb-asset-selector – so I have to make my own Link-Dialog and... yeah...

My work in progress so far, probably won't be of much use without context though

Getting there is actually easier than you think: I created a field plugin with local dev mode as explained here and installed tiptap like I normally would in any other Vue environment. Yes, this means tiptap will be baked in the exported field plugin, ... but it works :D

from storyblok.

Hi @katerlouis, thank you for this suggestion. We're planning to make improvements to the richtext field and adding some more extensions like sub and superscript, which is already in development. Can you tell me the reason what you're missing the in the current richtext field, that makes you want to build your own field?

from storyblok.

@lisilinhart Thanks for the update regarding sup and subscript! looking forward to that being in the editor.
Are you looking at adding anything else in the near future? For us the most important thing would be adding color to parts of the text.

from storyblok.

I had some time left over today, so I spent an hour or so trying to get this to work, but I wasn't successful.
I used a combination of the following:
https://www.storyblok.com/docs/plugins/introduction#local-development
https://www.storyblok.com/tp/react-field-type-plugin
https://markus.oberlehner.net/blog/building-a-custom-storyblok-field-type-plugin-with-vue/
https://tiptap.dev/installation/vue2

Issues I was facing:
I couldn't get storyblok to connect to my local environment over HTTPS (resulting in nothing loading).
https://user-images.githubusercontent.com/5083273/223509286-55e70173-5c50-4121-bf57-b9ede4f28f0c.png
I tried building locally and uploading the resulting code as described, resulting in an empty plugin without the editor.
https://user-images.githubusercontent.com/5083273/223509343-797d4ec0-710c-419d-8b66-d9a6714cb66c.png
I manage to create the editor object, but sending it to the model and then to the template doesn't seem to work.
https://user-images.githubusercontent.com/5083273/223551980-4fca3168-f300-4144-92f9-d1d4c9d49d7c.png

My attempt can be found here:
https://github.com/SebbeJohansson/storyblok-custom-tiptap-plugin/blob/main/src/Plugin.vue
https://user-images.githubusercontent.com/5083273/223552030-6a68b832-1fa0-4613-ba3f-109b8cc6de27.png

I do see that @katerlouis managed to do it. Not sure how they managed to get it to work!

@lisilinhart Maybe I could get some help from the extension team to look at this?

Edit: I had better luck with ckeditor, so maybe its just tiptap that refuses to work.

Edit number 2! 😁
After some sleep and some clarifications from @katerlouis I managed to get it to work!
The working code can be found here:
https://github.com/SebbeJohansson/storyblok-custom-tiptap-plugin

from storyblok.

I recommend holding the editor instance inside data() instead of storyblok plugins model. The editor itself does not need to be stored. It's unlikely to be the reason for your issue, but just to be sure, I'd put it in data() – you want to save the output of tiptap in model.value or model.content (or whatever property you like :D)

I had trouble using EditorContent directly in Plugin.vue, so I created a wrapper TipTap.vue file in order to use custom v-model, which then worked fine. And believe me: This will be a lot of code, so the wrapper is worth it.

For not stressing too much, I debounced the the custom v-model emit whenever tiptap is updated.

Plugin.vue

<template>
  <div class="dumbo-richtext">
    <TipTap v-model="model.content" />
  </div>
</template>

<script>
import TipTap from './TipTap.vue';

export default {

  components: {
    TipTap,
  },

  mixins: [window.Storyblok.plugin],

  watch: {
    'model': {
      handler: function(value) {
        this.$emit('changed-model', value);
      },
      deep: true,
    },
  },

  methods: {
    initWith() {
      return {
        plugin: 'dumbo-tiptap',
        content: '',
      };
    },

    pluginCreated() {
      console.log('plugin:created dumbos tip tap');
    },
  },
};
</script>

TipTap.vue

<template>
  <div class="tip-tap">
    <TipTapMenu
      v-if="editor"
      :editor="editor"
    />
    <TipTapBubble
      v-if="editor"
      :editor="editor"
    />
    <EditorContent :editor="editor" class="content" />
  </div>  
</template>

<script>
import TipTapBubble from './TipTapBubble.vue'; // my custom bubble menu
import TipTapMenu from './TipTapMenu.vue'; // my custom menu

import { Editor, EditorContent } from '@tiptap/vue-2';
import StarterKit from '@tiptap/starter-kit';

import debounce from 'lodash.debounce';

export default {
  name: 'TipTap',

  components: {
    // Editor, // do not use Editor here! It's not a vue component
    EditorContent,
    TipTapMenu,
    TipTapBubble,
  },

  props: {
    // for custom v-model
    value: {
      type: undefined,
      required: true,
    },
  },

  data() {
    return {
      editor: null,
    };
  },

  mounted() {
    this.editor = new Editor({
      extensions: [
        StarterKit.configure({
          // optional
          // see tiptap docs
        }),
      ],

      content: this.value, 
    });

    // (!)
    this.editor.on('update', debounce(({ editor }) => {
      this.$emit('input', editor.getJSON());
    }, 200));
  },
};
</script>

from storyblok.

Thanks for the insight @katerlouis. I understand that our richtext solution might not fit everyone, but the goal is to make it as universal usable as possible. You make some good points though about needing a custom solution and I think it makes even more sense, if the content is not within a website, but maybe a mobile framework. That said, building a custom richtext editor is quite complex and I would not advise it to most clients, just because of the sheer amount of implementation work. My hope is that in the future we can build some kind of bridge for our clients to build their own extensions through https://tiptap.dev/guide/custom-extensions and then use that within our richtext editor.

Thats a fair point; but that doesn't justify the lack of documentation on HOW to get started with a custom tiptap field after mentioning that it's possible.

So my suggestion (or my request even) would be to either remove this part of the docs, or flesh it out more. To me, and I know thats subjective, theres not much more frustrating in the dev world than ambiguous misleading, outdated or just false docs. We all work on multiple projects, with varying tech stacks. The web is driven by third party tools, using other third party tools etc.– Good documentation is vital these days.

If you decide to flesh it out: Why not provide a working boiler-plate with the bare minimum of functions, or maybe even the entire functionality of the storyblok tiptap field so that the developer can just alter that in a custom field?

@katerlouis I agree on the documentation point. I scheduled a meeting with our documentation team to get their point of view on this topic and to align all the different people involved in the richtext development. I generally think the documentation on richtext needs some doover from our side. We also have a few of the suggestions that are missing in richtext already in the development phase and coming soon, including:

• sub & sup
• text color and text highlight
• undo / redo
• emoji

from storyblok.

@lisilinhart Amazing. That sounds great 🥳

from storyblok.