Coelho - Structured rich text for Phoenix

I’ve just published Coelho, a structured rich text library for Phoenix.

The idea is somewhat inspired by Rails’ Action Text: provide a proper rich text layer between the editor in the browser and the application’s data model.

But instead of storing HTML, Coelho stores the document as a structured JSON tree — the same kind of document model used by ProseMirror.

That gives the application a single source of truth for both the editor and the server:

• define the document schema once in Elixir
• export the schema to ProseMirror
• validate documents before they reach the database
• store the document directly in a jsonb column
• render it to HTML or extract plain text
• customise rendering without changing the stored document
• use different, restricted schemas for different rich text fields
• validate and cast rich text directly through Ecto
• use it from Phoenix LiveView with an included editor
• support attachments with URLs resolved at render time

One of the things I particularly wanted to avoid is treating HTML as the data model.

When rich text is stored as HTML, the markup becomes part of the persisted data. With a structured document instead, the data remains queryable and migratable, while rendering stays an application-level decision.

Coelho also deliberately keeps the core small: no file storage, image processing or collaborative editing. Those are integration points rather than responsibilities of the document layer.

It’s early, but the core is already in place and tested.

I’d particularly love feedback from people building Phoenix applications that need rich text, especially if you’ve used Action Text or another structured rich text solution before.

HexDocs: coelho.hexdocs.pm/readme.html

Hex.pm: hex.pm/packages/…

github.com/nseaSeb/coelho

Rover — Interactive maps for Phoenix LiveView

Rover is a Phoenix LiveView component for interactive maps. It wraps OpenLayers — a serious GIS engine with projections, WMS/WMTS, vector layers, cadastral data, etc. — and removes the ceremony most Phoenix applications don’t need.

What it does

<.map
  id="parcels"
  center={{45.75, 4.85}}
  zoom={12}
  markers={@clients}
  shapes={@parcels}
  tiles={:ign_ortho}
/>

Assign a list of maps, get a map.

Change the list, and Rover diffs by ID and updates only what changed — no flicker, no interrupted pan, no popups unexpectedly closing and reopening.

Markers: any struct with :id, :lat, and :lon. Optional emoji, custom colors, draggable pins, and popups (HEEx slots, escaped by default).

Shapes: GeoJSON from ST_AsGeoJSON or your own data. Shapes are diffed by revision rather than hashing, so updating thousands of points stays efficient.

Clustering for hundreds of markers.
Heatmaps for density analysis.
Popups on shapes that point to the geometry rather than its centroid.
View control without losing declarative framing with Rover.fly_to/4 and Rover.fit_to/4.

Rover also has built-in support for IGN Géoportail, including French cadastral maps and aerial orthophotography.

Why not just write a hook?

You can — and the first version is short.

Then you fix reconciliation, coordinate order, viewport framing, attribution, element ID changes, flickering, and all the little edge cases that appear once the map becomes part of a real application.

That’s the layer Rover is trying to provide.

OpenLayers itself is the bet underneath it.

Three pins on a tile layer is an afternoon’s work. The next morning you need WMS layers, a cadastral overlay, vector data, clustering, or another projection — and suddenly the ceiling has moved somewhere else.

OpenLayers can handle that. Rover tries to make it feel natural from Phoenix LiveView.

Try it

Livebook demo

Run Rover in Livebook

Documentation

Rover v0.3.0 — HexDocs

Source

GitHub — nseaSeb/rover

Rover is open source and still evolving. Feedback, ideas, and criticism are welcome.