Opinion: Section blocks or Metaobjects?

Short description of issue

With repeatable content, should metaobjects be favoured over section blocks?

Reproduction steps

n/a

Additional info

I’m working on a store feature that will contain repeated blocks of content. Using either metaobjects or section blocks will achieve the same result.
So I wonder if I should favour one over the other?

On one hand, using section blocks will be more user-friendly; on the other hand, I risk losing content during theme switches. Metaobjects survive theme changes, but then also have a sub-par user experience.

Thoughts?

What type of topic is this

General discussion

1 Like

Hey @ConduciveMammal ,

Would this content be used elsewhere?
I would tend to lead metaobjects just because the content can be moved and used on other pages there.

The theme updates you mentioned is also an issue too.

Honestly, I’m moving more towards using metaobjects wherever possible just because it does give a lot more flexibility when it comes to themes.

You could use a block and just render the dynamic content in there via the customiser

Thanks!

I think now we have the metaobject_list input setting it makes more sense to use metaobjects.

1 Like

Here’s an example of the block content. I am leaning towards metaobjects instead. One annoyance I’m finding with metaobjects is the crappy url / link field type that doesn’t produce the resource list like block/section settings do.

Given what you shown, I would lean towards metaobjects + metaobject_list input theme setting. As there is a 100 dynamic sources limit by template, you would most likely hurt yourself in the long run going down this road.

Just build your interface by giving all necessary fields in the metaobject definitions and assign theme to the different sections/blocks via the associated metaobject_list setting :wink:

Hope it helps !

1 Like

The visual theme editor is UX||content-mgmt overhead that is only going to grow.

Default to MOBs for connected consistent content; that isn’t a one off.
Especially now with the increased limits.

Haven’t really figured out a clear and cut rule set.
easier api access/handling, easier to stand up content versioning without parsing JSON settings in a JSON response, and probably more upstream/downstream benefits.

Friendly to who and in what way.
We here might be hardened to be used to things like a theme editor but it is very noisy mess for the average.
Theme editor really only applies if VISUAL feedback is needed.
And VISUAL should indicate some sort of dynamic layout that drastically can effect the design in some unguessable/unreliable way. Like someone is assigning specific fonts to specific things. Which can then run into the problem of STAFF playing designer, or worse the designer having to play designer for every one off.

And that’s not including things like hardware requirements for a sane experience vs theme size + apps, in the visual theme editor.

If it’s marketing copy, do vendors really need theme access.
give em a spreadsheet > MOB update.

Sometimes all staff need is a literal form, even devs.
If one word needs to be changed why open an entire editor, then probably also NAVIGATE to the right spot.
it’s why I loathe bloat like the vscode editor replacing the near instant old one.