Show HN: A renderless and extendable rich-text editor for Vue.js

by hanspagel • 7 years ago

278 53 7 years ago

billconan• 7 years ago

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 ...

lol7682• 7 years ago

can the data be represented as markdown

Sounds like a niche enough requirement that you'd be better off writing some form of transformation logic for your needs that can produce a markdown approximation from the JSON structure that the editor generates.

philippkuehn10• 7 years ago

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.

ceejayoz• 7 years ago

This is really slick. I like it.

Would love details on browser support, though.

philippkuehn10• 7 years ago

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

mathnmusic2• 7 years ago

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.

jeremyjh• 7 years ago

It is possible to use a react component in a Vue app but of course what it does to your page weight may not be acceptable.

https://github.com/akxcv/vuera

adrianhel• 7 years ago

This depends on the app however. For a landing page? No way. For a module within an app I would not mind, as long as lazy imports are used.

woah• 7 years ago

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• 7 years ago

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

mathnmusic2• 7 years ago

Web components can't make React/Vue/Angular components reusable anywhere else, but web components themselves are reusable in React/Vue/Angular apps.

philippkuehn10• 7 years ago

I didn't call it "perfect". Slate.js is great but has some downsides too. But for Vue.js there was like nothing, so I took the first step.

There is also a core package of Slate, so it's up to you to build a wrapper for Vue too. Slate is still in beta. That's why I chose to built on top of ProseMirror.

jacquesc2• 7 years ago

I started paying attention to this when i saw the "Suggestions" demo. 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.

philippkuehn10• 7 years ago

That's one reason why I built tiptap!

whatl3y• 7 years ago

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...

jacquesc2• 7 years ago

Looks great, thanks for the recommendation!

lol7682• 7 years ago

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?

philippkuehn10• 7 years ago

Good catch! That should be easily done.

echopom• 7 years ago

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.

marmada• 7 years ago

What does this have to do with Web Components? Even if you used Web Components you would still need to write bindings for each framework.

philippkuehn10• 7 years ago

It's built on top of ProseMirror (plain JavaScript).

dwaltrip2• 7 years ago

You only have 5 comments, all from today, and 2 of them were flagged dead. I couldn't see any reason why so I vouched for them. I am a bit confused about the situation though.

pxtail• 7 years ago

Same thing goes about almost all controls and UI elements existing inside web browsers. I'm around web development for years and it's very saddening and heart breaking for me to see all this milling around in one place, round and round and results are not that much different.

Sometimes I really, really dread this whole "frontend" related churn, tooling, javascript and it's quirks. I looked at Flutter recently wondering - maybe this is the answer? But this probably is just another turn of the wheel, it was attempted already in the past with adobe air/flex and many other projects.

Maybe reason for this is that programming and whole IT is very young craft, mere child's play compared to different industries like for example construction which has thousands years of history, trials, successes and errors.

luckydata• 7 years ago

the web is a really poor abstraction for building UIs and it's kinda incredible that we collectively don't internalize that simple lesson. We have hacked to death a platform for linked text documents because it's what everyone has, that's the extent of the merits of the web platform, but it's not a good fit for what we're trying to do in the productivity world. Flex for example was leaps and bounds better in that regard, and any desktop OS is too. Javascript is a poorly designed language that we beat into submission by working around its many, many flaws.

We keep making this mistake of wanting to use what's available instead of coming together to build something better, so we waste MILLIONS of collective hours because we're dumb.

zemptime2• 7 years ago

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/

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• 7 years ago

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

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

Vinnl• 7 years ago

If such a "universal rich text edit" web component comes out, have web components then succeeded?

I think (but this is my interpretation) that GP meant to assert by saying "Web Components failed" that no such component will ever come out, because Web Components cannot properly solve that use case. I haven't delved into it deeply, but my intuition is that, indeed, quite a lot of ceremony would be needed to integrate such a component into a larger web app, regardless of whether you use a framework or which one.

h1d• 7 years ago

bootstrap-select?

https://developer.snapappointments.com/bootstrap-select/exam...

burlesona• 7 years ago

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!

philippkuehn10• 7 years ago

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

philippkuehn10• 7 years ago

creator of tiptap here. a bit late, unfortunately.

Theodores• 7 years ago

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.

azangru• 7 years ago

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

underwater• 7 years ago

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.

werber• 7 years ago

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

Etheryte4• 7 years ago

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.

faitswulff• 7 years ago

For those who were confused about the "renderless" bit:

What does renderless mean?
With renderless components you'll have full control over markup and styling. tiptap doesn't tell you what a menu should look like or where it should be rendered in the DOM. That's all up to you.

https://tiptap.scrumpy.io/docs/#what-does-renderless-mean

ng124• 7 years ago

I read the renderless article linked to in the README (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.

Etheryte4• 7 years ago

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.

svieira• 7 years ago

I like it too - the pitch reminds me of https://github.com/enkidevs/seapig (where I first saw this pattern explained for React)

manigandham• 7 years ago

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

realty_geek2• 7 years ago

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

https://github.com/iliyaZelenko/tiptap-vuetify

Show HN: A renderless and extendable rich-text editor for Vue.js

Related Stories