So you saw code components demoed at Webflow conf, but what can they really do?
I’m building out a series of ~50 code component currently for a wide range of uses, and I’ll start sharing demos here to the community to showcase what’s possible and what you’ll be able to literally drag-drop into your site once code components are supported in Marketplace libraries.
This code component is a masonry grid. drop it on your canvas, slot in some images, choose the number of columns you want at each breakpoint, and boom. done.
Not only that, you can drop individual image, or collection lists full of images, or both… this component will unpack everything and make it a full masonry layout - fully self-contained with no custom code added anywhere.
Webflow is still working out the paths for deployment of code components through the marketplace, but I’m looking forward to making components like these available to the community as a whole. For now, since they require direct workspace access I can only publish them directly into workspaces my agency Sygnal is a guest in.
If you’re already working with me and want to try it out, let me know!
Code components in Webflow are powerful tools that extend your site’s functionality beyond standard visual design capabilities. They’re particularly useful for:
Creating complex, reusable UI elements
Implementing advanced interactions and animations
Sharing consistent components across multiple pages or sites
Building custom functionality using React
Once installed, code components can be configured directly through Webflow’s designer interface, making updates and maintenance straightforward. For masonry grid layouts specifically, code components offer more flexibility than traditional grid systems, allowing for dynamic resizing and advanced layout options.
To get started with code components, you’ll need to have them enabled in your Webflow workspace and some familiarity with React development. You can find detailed implementation guides and examples in our documentation at developers.webflow.com.
Hopefully this helps! If you still need assistance, please reply here so somebody from the community can help.
That masonry setup looks super clean , love that it handles both static images and CMS lists without extra code. Curious if you’re planning to add lazy loading or lightbox support in future versions?
I have a question to the component properties you used:
I see that you have some switches with the label “True“ and “False“. If I’m correct the only switch we can use in the properties panel outside of code components are “Visible“ and “Hidden“.
Does that mean you can create custom properties with custom values?
And if so, what are the limitations of it?
For example: I often use LottieFile Animations on my websites and I also use components a lot. But its not possible to link a lottie file to a component property.
Would it be possible to create a custom property that supports LottieFiles?
I’m looking forward seeing more of your code components!
Code components have an additional Boolean property. Nicely done, you can choose the labels for True and False states as well, and the default setting.
Unfortunately not that flexible yet- you can see the list of supported prop types at my link above.
In other component systems I’ve worked with there’s usually a point where there is a step into “custom property handlers” where you actually have a design-facing component that sits in the property panel, and can manipulate the component settings for the main component.
That’s needed for complex component configs- think graphs/charts, table settings, tab component ordering, slider setup, map address locator for map pins… someday maybe but I don’t think it’s on Webflow’s roadmap currently.
The way I’d approach it is to use a Link property- I really like the way that works in the context of a code component. You can enter a URL to an externally-hosted resource, or you can pick an asset. Unfortunately there isn’t a way to constrain a link to the supported file types, but in that situation the title and tooltip should be enough to communicate what the user needs.
You’d need to integrate your own Lottie player inside of the component, but that lets you version-manage too.
I’ll do another demo now, that uses that approach.
Ah okay I understand.
I see that fully customizable properties would be may more complex.
Going with a link property is a good idea. Only downside is that the person who edits the website needs to learn an additional platform for the lottie-hosting. But they will get used to it.
I think its really nice what is possible with code components.. looking forward seeing more of your stuff
Actually the link property allows them do either an external link or an asset link, it’s fairly ideal for this purpose. In my audio player, I typically link to assets-stored MP3s.
