A server based html visual editor with liveview

phoenix
live-view
#1

So as a play-test-drive of liveview I decided to try and implement a visual html editor server rendered with live view.

https://cocktail-demo.herokuapp.com/cocktail-editor/1A5FA1337B87

There’s a lot of hiccups, on the free heroku dyno it’s way too slow (locally it behaves quite in real-time), there’s some issues with the fact that liveviews wrap their components in a phoenix specific div (which on the editor makes some things not behave as they should). The phx-loader also introduces some problems. The structure of rendering each “component” as a liveview probably introduces big patches not well suited to be broadcasted.

This is probably an example of what you not use live view for, but it was quite an interesting experience.

If anybody is interested I can publish a git repo for it with the current code. I think the idea is interesting, with some polishing and a layer of js that builds the “dom” on the client side from messages emitted from the backend it could be quite better though.

3 Likes
#2

Nice! I tried it and works great! Just sometimes the server hangs because of heroku.

Is everything rendered on server? even the modals and buttons that add and edit the contents?

#3

Thanks! Yes - it’s a class change on the modals and attribute on the buttons, all menus are rendered initially but start hidden and when you click them it changes the classes so they’re displayed. Some parts of the modals are re-rendered, like the list of styles/classes, etc, but the original structure is done on first render.

(I also noticed that it’s not the best way to demo it, because the views broadcast changes according to the page id, so if two persons are editing the same page, and one opens a modal, the other one sees it opening as well… Details)

#4

Just a thought, I know that for ‘demo’ putting everything on the server is nice to show how much it can handle, but maybe wouldn’t be better to let just the view that you are building be rendered on server and the controls, modals and such be local, that could lead to a “real-time colab html editor”. :thinking:

#5

Ahah indeed the modals popping up when another user is editing the same page/component wasn’t intended at all - the idea of a real-time collab editor is present, though it would require I guess quite a bit more work to be usable - a canonical “saved” version would need to be in place, then each editing user would get a “copy” of that and then when a user edited (and “saved” ?) it would need to issue a “diff” warning so that the other user editing the same page could be notified and choose to “merge” those changes? It makes the whole thing more complex.

This was more an experiment with liveview and I wanted to see if it could work when online - there’s still many bits of functionality not implemented, like specifying global stylesheets, javascript files/content, dynamically access resources (db queries, or wtv). I think though that if liveview allows something like this it’s a good sign it can be used for other stuff (as most things won’t be as complex as a visual html editor).

In this particular case it most certainly warrants building your own “communication” protocol and a JS layer on top of it for this particular use, and then the back-end and client just exchange messages of the changes. I’m thinking some JS template literals could work well as they’re very fast to re-render. So the html tree would be built client side as a JS object, changes would be sent to the server and the same tree would be kept in the server. But then I wouldn’t have experimented with live view.