
Show HN: A renderless and extendable rich-text editor for Vue.js - hanspagel
https://github.com/scrumpy/tiptap
======
jacquesc
I started paying attention to this when i saw the "Suggestions" demo.
[https://tiptap.scrumpy.io/suggestions](https://tiptap.scrumpy.io/suggestions)

Every rich text editor I've tried so far, it's been a nightmare to add
autocomplete for stuff like mentions and hashtags. I haven't integrated tiptap
yet so maybe it's the same, but the code for the demo looks very promising.

~~~
whatl3y
At a quick glance tiptap looks great and I don't want to derail the thread
mentioning another solution, but after admittedly struggling longer than I'd
hoped to implement mentions into a Vue-compatible RTE I got it working fine
using modules (NPM) `vue-quill-editor` and `quill-mention`.

Since this is the first public thread I've ready of at least one other person
struggling with this (I'm sure there are others), I created this gist of my
Vue component in case it helps anyone who want to use Quill instead of tiptap:
[https://gist.github.com/whatl3y/d1a9fb7bab75c2188b226e902c6f...](https://gist.github.com/whatl3y/d1a9fb7bab75c2188b226e902c6faff5)

~~~
jacquesc
Looks great, thanks for the recommendation!

------
Etheryte
As a frontend dev, this is really, really nice and I wish more libraries
followed the renderless principles. So many manhours are wasted, daily, just
because a library is a tad too specific about it's preferences. It would be
nice to see it standardized in some shape or form so that it's both easier to
write for newcomers as well as test.

~~~
ng12
I read the renderless article linked to in the README
([https://adamwathan.me/renderless-components-in-
vuejs/](https://adamwathan.me/renderless-components-in-vuejs/)) and it seems
like an absolute nightmare in Vue. Lots of cognitive overhead for something
that's completely natural in React.

~~~
Etheryte
I didn't downvote your comment, but it seems you've misunderstood the core
concepts under discussion here. Renderless isn't inherent to Vue in any way —
the problems it addresses are equally present in React-based libraries. You
can easily override render functions and the given bindings in both Vue and
React, but given libraries that aren't built to be easily extendible, this can
often lead to maintenance nightmares. Renderless seeks to counteract that,
giving guidelines to architect libraries in a way that doesn't introduce
considerable complexity on the library side but makes it a lot more extensible
on the consumer side.

~~~
ng12
I think you've misunderstood my post. I'm saying renderless components come
"for free" in React -- there's no cognitive overhead or new concepts to learn.
It's something that comes very naturally as you develop React components to
the point where I've been writing renderless components for years without ever
really thinking about it. From reading the article linked above it feels very
clumsy in Vue based on the fact that there's a whole feature (slots) which not
only feels fairly magical but requires a rather meaty article to explain it's
usage.

I guess what I'm saying is if you're really interested in renderless
components it's probably easier to just use React.

~~~
Etheryte
I still don't really see what you mean — the functionalities are practically
identical between the two frameworks, Vue uses slots, React uses props
children. The only difference is naming and minor semantics differences. The
same principles apply for both, and the discussion is just as relevant for
both. Personally I prefer the Vue approach over the React one since React
components are usually build more black-box style in this architecture, but
that is mainly a preference argument. The "cost" of the approach is the same
in both libraries.

~~~
ng12
> The only difference is naming and minor semantics differences

I don't agree at all. There are no naming/semantics for doing renderless in
React. React has no analogue for "slots" because it's just naturally part of
the framework. It's as simple as doing:

    
    
       <LinkList renderLink={(linkProps) => <div>...</div>} />
    

No extra terminology to learn, no slot keys, extra attributes, or rendering
magic, and definitely not something you need a whole article to explain.

~~~
Etheryte
That's a basic example which doesn't address the topics discussed in the
article at all. The same is just as easy in Vue, even with identical property
names if you like.

    
    
        <link-list :render-link="(props) => ..." />
    

The whole idea of renderless is to move beyond this very limited and crude
approach for library code where you might need to override only small bits of
the logic or all of the logic, depending on your use case. At the moment I
can't help but feel you've missed the core ideas of the article and we're
discussing completely different points.

~~~
ng12
Why would you want to use slots, then? It's just extra steps for the same
functionality.

> The whole idea of renderless is to move beyond this very limited and crude
> approach for library code where you might need to override only small bits
> of the logic or all of the logic, depending on your use case

Not at all. For example, react-select does this super seamlessly:
[https://react-select.com/components](https://react-select.com/components)

I guess what I'm trying to say is I don't understand why it seems so
complicated in Vue.

------
billconan
This is really cool! and I really want to adopt it. I have a question though,
can the data be represented as markdown, instead of html and json?

My current editor is monaco and the format is markdown. Monaco is too heavy, I
want something closer to what Medium.com has. This renderless rich-text editor
looks perfect. But my backend accepts only markdown ...

And I also need to support math equations ...

~~~
philippkuehn
There is already a feature request about markdown support. You can follow that
issue on github. At the moment I'm not sure if this will land in tiptap.

------
burlesona
This is really awesome. I’ve been watching Prosemirror for a long time and
have considered building something like this on top of it, but haven’t had the
time to try. I’ve been using Quill instead, since it’s a lot simpler and was
pretty easy to just drop in place. This looks like a nice upgrade though!

~~~
philippkuehn
We used Quill before as our rich text editor at scrumpy.io … a few months
later I started working on tiptap :)

------
manigandham
Nice work here, very smooth and supports a good set of functionality by
default.

Added to the list of HTML editor:
[https://gist.github.com/manigandham/65543a0bc2bf7006a487](https://gist.github.com/manigandham/65543a0bc2bf7006a487)

------
lol768
Might be nice to do some more input validation, particularly for links - the
editor is happy to insert a javascript: link. I don't think this poses a
security issue (at most, you'll get what - a self XSS?) because you'd
obviously do server-side sanitisation in a real application, but it might be
nice to check for non-https protocols and warn the user when they insert them?

~~~
philippkuehn
Good catch! That should be easily done.

------
echopom
It fascinating that in 2019 we aren't able to get one text editor that would
work seamlessly across all frameworks , but instead need to basically re-write
huge "bindings" to support the reactivity and the rendering logic in each of
them.

Web Components have definitely failed.

~~~
zemptime
While I agree we (as in the internet at large) haven't solved the text editor
problem, by saying "web components have failed" you're concluding in bad
faith.

If such a "universal rich text edit" web component comes out, have web
components then succeeded? Then failure isn't such a permanent state as your
comment implies, rather an indication of work yet to be done.

Unless you'd like to clarify more, your comment seems to me like you're
flinging mud without being able to back it up. What's the reason for that?

Of note, Trix has been using the `customElements` standard since forever:
[https://github.com/basecamp/trix/](https://github.com/basecamp/trix/)

There's also slate, the (old!) tinymce, umm... I know I've at least
experimented with a good couple more I can't recall.

And, on the topic of components I wish existed (anywhere - react, vue,
angular, etc - anything), I've been searching for a good rich multiselect for
a long time! If you know of any please let me know :)

~~~
deergomoo
> And, on the topic of components I wish existed (anywhere - react, vue,
> angular, etc - anything), I've been searching for a good rich multiselect
> for a long time! If you know of any please let me know :)

Select2 [1] has been around forever but it's always worked out pretty nicely
for me.

It's a jQuery plugin, so it's somewhat out of vogue these days, but it's
trivially easy to wrap it in a component to make it play nicely with Vue (in
fact, the Vue documentation uses it as the example for writing wrapper
components [2]). I imagine something similar can be done with React, Angular,
etc., though I'm not too familiar with the process there.

[1] [https://select2.org](https://select2.org)

[2]
[https://vuejs.org/v2/examples/select2.html](https://vuejs.org/v2/examples/select2.html)

~~~
dpau
not that there's anything wrong with jquery or select2, both of which i used
heavily in the past, but if you're working in vue it's a very nice feeling to
just completely drop the jquery dependency. ive been using
[https://github.com/shentao/vue-multiselect](https://github.com/shentao/vue-
multiselect) for over a year now in production and despite its quirks i'd
recommend it.

~~~
zemptime
ooooh nice. I didn't know this was a thing. Yeah, the jquery bundle size
really isn't justified for a single thing (rich multiselect). I recently
ported `selectr` for use in an app at work, but I'd love to replace it as
there's some wonkiness

------
philippkuehn
creator of tiptap here. a bit late, unfortunately.

~~~
Theodores
Can you write an editor that moves on from 1990's WYSIWYG to use the HTML5
content sectioning elements, so that different 'sections' and 'asides' can be
moved around? In so doing - and nesting them - the headings could be given an
automatic h2 - h6 level, with the headings inside sections/articles.

It would also be nice to see details/summary entries and nothing in the
toolbar that creates inline CSS things.

Out the box such an editor should create accessible HTML that can be easily
styled, with structure to it that would result in a document outline.

I think such an editor could be what a lot of the web needs, to make people
wonder why we ever had WYSIWYG backend editors that render nothing like the
frontend, e.g. the things you get in Wordpress and other content editors.

WYSIWYG made sense in the 1990's when what you wanted was a printed 'dead
tree' page, but we have responsive design now and lots of different screen
sizes, so it is getting the structure right that matters more, not just for
accessibility but SEO.

------
ceejayoz
This is _really_ slick. I like it.

Would love details on browser support, though.

~~~
philippkuehn
It's built on top of ProseMirror. They're targeting IE11.

------
werber
I used this for a demo (that took about 30 minutes to build) and my
stakeholders loved it. Thanks!

------
realty_geek
Yaaaay, there is a project that integrates it with vuetify my favourite vue UI
kit:

[https://github.com/iliyaZelenko/tiptap-
vuetify](https://github.com/iliyaZelenko/tiptap-vuetify)

------
azangru
On the topic of rich text editors (since people mentioned Slate) what's your
opinion of react's draft.js?

~~~
underwater
Not OP, but I was an early contributor to Draft.

Draft JS lacks a few features, notably nested block support (tables) and a
schema definition and sanitization. Slate is more focused on providing a nice
plugin experience.

On the plus side Draft’s core is battle tested and has just picked up Android
support, and has the excellent Draft JS Plugins resource.

------
mathnmusic
While this is really nice, it's a shame that a VueJS developer is unable to
re-use a React-based text-editor which already exists and he found it perfect.
This is why Web Components start making a lot of sense.

~~~
woah
Will web components let him use a React module with Vue.js without loading
both libraries and learning React?

Or is web components a _third_ library that is so much better that you don’t
need the other two libraries?

Is this the situation where there are too many standards and you can only
solve the problem by creating another standard?

~~~
mfatica
Web Components should replace them both. They aren't standards - just
frameworks developed by third parties. The Web Components standard is the
official standard and should be the one people reach for

