user defined custom blocks

[j-ro]

The workflow I imagine is a user is creating in the editor, and they have something set up that they want to re-use, so they can click a save button and save that block. Then, when making blocks later, they see a list of saved blocks and can drag those in. And perhaps ways to manage the saved list (categorize in folders, delete, rename, etc...)

Backend actual saving could happen similar to, say, image uploads, with a javascript hook that triggers AJAX to the server to save the block, and population could happen on load via editor config or similar AJAX calls, but the save/display/drag in functionality would need to be done in the editor.

[orkhanahmadov]

Hey @j-ro, thanks for the write-up and another great idea. I like it.

Few things:

It's already planned for Cloud, and a lot of the code is in the SDK today. Saving a block as a reusable unit, a browser to search/preview/insert saved blocks, and the headless create/list/update/delete logic already exist — they're just gated behind the Cloud backend right now. The editor-side UI is mostly shared code, not Cloud-specific. You can see the Cloud feature here (it's called Saved Modules in Cloud): https://cloud.templatical.com/features/saved-modules

The reason it's planned for Cloud first is that the whole retrieve/save/delete flow requires a backend, a database, and tenant separation — a complete infrastructure. But reading your idea, since most of the required SDK code is already in place, I'm willing to open it up, document it, and allow it to be used with a BYO approach.

It would work like you mentioned — similar to the media/image-upload hooks: you supply a storage "provider" (retrieve / create / update / delete) wired to your own backend however you like, and the editor handles the save button, the list, previews, and insertion. The editor owns the state and UI; you own the transport.

As I said, most of the code is already in place, but hard-wired to the Cloud provider and authentication. To make it open, I need to define the provider interface in the open-source SDK so anyone can implement it against their own storage, then have Cloud consume that same interface as just one adapter. I'm also thinking of shipping a simple built-in provider (e.g. localStorage, browser-based) so it works out of the box with zero backend.

One naming note for clarity: I'm calling this Saved Blocks. There's already a Custom Blocks feature, but that works differently and serves a different purpose — see: https://docs.templatical.com/guide/custom-blocks

Folder organization and rename are on the list too, most likely as a follow-up once the core save, browse, and insert flow ships.

Let me know what you think about this.

Thanks again!

[j-ro]

I like this idea!

Cloud sounds convenient, and honestly I think we'd probably be starting with Cloud (once pricing and such is available so we can evaluate). But my current stance is, if we did the painful migration from our current provider, we'd want wherever we land to be the last migration we ever have to do. Templatical's open source nature helps guarantee that. So ideally, everything that interfaces with a server backend has hooks so if someone wants to build their own backend they can, giving us the independence we are looking for if we want to put in the work.

[orkhanahmadov]

@j-ro yes, I totally get it. And I want Templatical to be the last email editor SDK you have to integrate, with the power features in open source.

On your point about hooks and specifically about Saved Blocks, check this out, #451. I already have it with BYO backend almost ready to be merged. It ships with a SavedBlocksProvider interface: four methods (list/create/update/delete) wired to whatever backend you like. Cloud consumes that same interface as one adapter. The editor owns the UI and state; you own the transport. Same shape as the existing media hook (onRequestMedia).

My plan with Cloud is to offer exactly how you described — convenience, with hosted storage, multi-tenancy, realtime infra, AI. Things most teams won't want to run themselves. Pricing and launch isn't public yet — I'll post it as soon as it is, so you can evaluate. Other than that, whatever it offers, when technically possible, my commitment is to offer it as open-source/BYO.

On "the last migration": beyond hooks, the things that actually protect you are already there:

• templates are portable JSON
• output is MJML — use it as-is or render to HTML whenever you like; not using any proprietary renderer like competitors
• and there are importers from BeeFree, Unlayer and raw HTML

I think Templatical already provide guarantee that you are looking for. Worst case, you fork it; the license permits that.

Back to Saved Blocks...
I still need to finalize and polish few things before I merge but feel free to check out the PR, also preview environments.

Here's playground preview environment already running BYO Saved Blocks: https://oss-saved-blocks.templatical-playground.pages.dev
Feature ships with browser localStorage adapter. Playground uses that as "backend" to store and manage Saved Blocks. Pre-built "Product Launch" and "Newsletter" templates contain example Saved Blocks but you can create Saved Blocks also yourself, manage them, delete them.

Here's also docs preview environment with Saved Blocks usage fully documented: https://oss-saved-blocks.templatical-docs.pages.dev/guide/saved-blocks

Check it out. Let me know what you think :)

[j-ro]

just played around on the sandbox, looks perfect, love it!

[orkhanahmadov]

Merged #451 and released new SDK version 0.21.0 with Saved Blocks feature

[orkhanahmadov]

Hi @j-ro,

Just a quick update since this relates to "Saved Block". I recently shipped huge BYO-Backend features, including

• Template creating/saving/loading
• Version history and autosave
• Comments
• Sending test emails
• Saved Blocks
• Backend handled rendering and export

Check them out, I'm sure you'll like them.

https://docs.templatical.com/backend

[j-ro]

nice! this all looks quite straightforward!