Canvas is almost here: preparing your components

Canvas is arriving in four months. The beta has been out for six. I have watched the implementation stabilise, and the patterns emerging are clear enough that anyone running a component-based Drupal site should start thinking about what changes when Canvas lands.

This is not a post about whether you should upgrade immediately. This is about what your component library needs to be in the next few months so that when you do upgrade, you are not trapped rebuilding everything.

What Canvas actually changes

I have written before about how Canvas reframes composition — editors will not just pick components and configure them, they will compose interactions, styles, and nested layouts. What that means in practice is that a component’s contract is about to get more specific.

In current Drupal, a component provides markup and styling. Canvas introduces a layer where components can declare what interactions they support. A card might declare: “I can be clickable. When clicked, I can open a modal or navigate.” A hero might declare: “I can have a background interaction — scroll parallax, fade, or none.” The composition layer uses these declarations to build pages.

This is not radical. It is what sophisticated frontend frameworks have done for years. But in Drupal, it is new enough that every component library will have to decide: do we add this layer or do we pretend it does not exist?

The platforms that prosper will decide early.

The work that happens now

The good news is that you do not have to wait for Canvas to ship. The work is straightforward and can happen in parallel with current development.

First, audit your component library. For each component, answer: what interactions does it need? Not “what would be nice.” What does it actually require to do its job? A card might need to be clickable. A button definitely does. A block of plain text does not.

Write that down. It does not need to be formal. A comment in the component schema is enough: “This component declares support for click navigation.”

Second, think about variation. Right now, you probably handle variation through props or through separate component variants. Canvas will let you handle it through composition — a card can be wrapped in a container that adds the styling for a featured context. If you start thinking in composition terms now, the Canvas transition is smaller.

Third, and this is the hard part: test your components with nesting. Canvas makes nested components more compositional. Your card might sit inside a featured-article component which sits inside a layout grid which sits inside a page. Right now, that nesting might break because of CSS specificity or because a parent component made assumptions about its children. Find and fix those assumptions now.

What does not need to change

Your component markup does not need to change. Your CSS does not need to change. Your Twig does not need to change. The props your components accept do not need to change.

Canvas is a layer on top. It looks at what your components can do and gives editors new ways to orchestrate them. If your components are well-built now, they will work with Canvas later.

The one thing that might need attention is accessibility. Canvas introduces more complex interaction patterns. If your components are not accessible now, they will not magically become accessible when Canvas appears. Fix that first.

The risk of waiting

I have watched teams delay this kind of preparation because the new framework is not out yet. They wait. The framework arrives. Now they have six months of work to do while also debugging incompatibilities and learning a new system.

The teams that succeed are the ones that did the prep work early. They identified their interaction patterns. They thought about composition. They tested their component library’s assumptions. When Canvas arrived, they upgraded incrementally instead of all at once.

For higher-education platforms, that matters. A relaunch is expensive. An incremental upgrade where components keep working and the composition layer improves is manageable.

What I think gets solved and what does not

Canvas will make it much easier to compose complex pages without writing custom markup. That is genuinely valuable. For a university site where different schools need genuinely different layouts, it is foundational.

What Canvas does not solve is the institutional variation problem. Two schools can now compose pages differently, but if the underlying components are not designed for that variation, you still end up with constraint. Canvas is a tool. A well-designed component library is the precondition.

I think the platforms that will thrive are the ones that treat Canvas as an enabler, not a solution. The work of building a coherent component library is not going away. Canvas just makes it more obvious when you have done the work badly.

Start now. Audit your components. Write down what they do, what they need, how they compose. The time to find the gaps is before Canvas arrives, not after.