Legacy Approach
Development Approach ( v1 )
The components I'm most interested in push the design boundaries of Webflow's setup a bit, so I'm two-phasing it using two separate Code Component projects - a prototyping lib and a production library.
Phase 1 - prototyping ( sygnal-prototype
lib )
sygnal-prototype
lib ) The prototype component is built in a separate lib specifically for prototyping.
As a separate library, it can be deployed to any project without impacting the production lib deployments.
The prototype lib contains a number of features to aid development, including various "test" components that model specific solution-approaches to specific needs like slot-processing, state sharing, and attribute configurations.
These can be used both as a reference for the dev team, and for any AI coding assistants like Claude code that the team might utilize.
In this library;
Functional prototype tested locally using Vite, and framed in App.tsx.
If the component has shared state like Sygnal's Audio player ( playing one pauses others ), that framework can also be built and tested locally.
As a separate library, it can be deployed to any project without impacting the production lib deployments.
Phase 2 - testing
Once it's feature complete, I deploy the lib into Sygnal's main Webflow workspace as the sygnal-prototype
lib. This keeps it discrete.
Integration testing is then performed;
Designer experience testing
Component functionality on the canvas
Slot functionality
Slotted collection list processing
Property presentation and ordering
Styling concerns
Preview mode
Published site testing
Functional testing
Richtext processing
HTML/CSS review
This process requires a lot of recurring deployments, but that's quite fast with the smaller prototype lib, from an SSD.
Production Release
Once fully complete, the code is manually copied over to the appropriate production library, e.g. sygnal-layout
, sygnal-forms
, sygnal-maps
, etc.
From here it needs to be deployed to;
Sygnal's workspace
Client workspaces
The community as a whole
2025-09-23 - CLIENT WORKSPACE DEPLOYMENTS ( UNTESTED ) Current plan is to maintain multiple .env files to swap the API_TOKEN with a script, and then deploy.
Ideally this would be handled with an --env or --config param on the CLI deploy command.
2025-09-23 - PUBLIC DEPLOYMENTS ( UNTESTED ) Current plan is to make the lib public as a repo, with a detailed guide on how to git clone, install npm, and deploy to your own workspace.
Last updated