As businesses develop and require more customizable layouts, handling several JSON templates, custom sections and deeply nested blocks can get very complicated with shopify.
How would you handle JSON templete and sections schemas if you were in charge of larger themes?
Do you like to develop several distinct parts or do you prefer to create modular reusable sections with rich schema setting?Also how do you handle upgrading template JSONs without destroying old client content or customizer settings?
The part that bit me hardest on big themes was not the section count, it was that section data can’t be shared across JSON templates. Each template holds its own sections object keyed by section ID, so a hero you use on 12 templates is 12 independent copies of the settings. Change the schema and you have 12 places where the old values already live.
So I stopped thinking of a section as a layout and started treating it as a settings contract. Modular reusable sections with a rich schema wins, but only if setting IDs become an API you don’t get to rename. The merchant’s value is stored under the setting ID inside the template JSON. Rename heading_size to title_size and every existing instance quietly falls back to the schema default while the old key sits orphaned in the file. Same story for the section type, since renaming the file orphans every reference to it.
Limits worth knowing before you commit to an architecture. 25 sections per JSON template, 50 blocks per section, 1000 JSON templates per theme. Deep nesting eats the block budget faster than people expect.
On upgrading without destroying client content, the trap is presets. Presets only fire when someone adds the section from the Add section picker, so existing instances never see your updated preset. That means a schema change has to ship with defaults that are safe for sections placed a year ago. I add new settings with a default that reproduces the current rendered output, never a default that improves it.
One more trap if you use the GitHub integration. It commits theme editor changes back to the connected branch, and the docs say that behaviour can’t be disabled. Your client’s customizer session is writing into your git history. Any merge that touches JSON templates can silently revert their work, so I keep template JSON out of the PR diff unless changing it is the actual point of the PR.
How many templates are you sitting on? The answer changes a lot between 15 and 200.
Building modular, highly adjustable sections with rich schemas is far more appealing to me than constructing lots of unflexible, one-use pieces. A single well-designed section can support numerous UI use-cases on various pages by utilizing dynamic blocks and adjustable container parameters (spacing, grid layout, alignment). This prevents theme bloat and maintains the codebase’s maintainability.