Gutenberg blocks without fighting the editor

Most Gutenberg pain comes from fighting the editor’s defaults. The block editor is opinionated — and those opinions are usually right.

After shipping 25+ plugins over the past five years, I’ve narrowed down what works to three patterns. They’re not novel, but I see them get violated in almost every plugin I review.

The mindset shift

Old WordPress development was “build the UI, then save the markup.” Gutenberg flips this: define the data shape (attributes), declare what the editor can already do for you (supports), and let the editor render. Your save function becomes incidental.

If you find yourself reimplementing colour pickers, alignment, or padding controls — stop. The editor ships those.

Pattern 1 — Composition over configuration

A block that does one thing well composes better than a block that does ten things via toggles. The WordPress core team learned this the hard way with the Cover block (now a sprawling composition of media, overlay, columns, and inner blocks).

If your block has more than 4 attribute toggles, you probably have two blocks pretending to be one.

Pattern 2 — Trust the supports flag

{
  "supports": {
    "color": { "background": true, "text": true },
    "spacing": { "padding": true, "margin": true },
    "typography": { "fontSize": true, "lineHeight": true },
    "align": ["wide", "full"]
  }
}

This one block.json declaration replaces ~200 lines of custom InspectorControls. Use it.

Pattern 3 — Lean on InnerBlocks

If your block contains other content, use <InnerBlocks> with an allowedBlocks and a template instead of building child editors. You get drag-and-drop, copy-paste, and the keyboard accessibility for free.

What’s next

In the next post I’ll cover Gutenberg’s data layer — when to use useEntityProp, when to use useSelect, and when to step out into Redux directly.