Sygnal's Code Component Dev Approach

Goals

• Rapid prototyping

• Methodology for R&D and proof-of-concept on more complex component design patterns

• Maximum styling support

  • Leveraging the Designer UX as much as possible

• Minimize the risk of production impact to users

  • Supporting tight CI/CD

  • Unit testing

  • Integration testing

  • Separate DEV, TEST, PROD environments

    • User-accessible TEST for community validation on new features

• Separate DEV, TEST, PROD environments

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 )

The prototype component is built in a separate lib specifically for prototyping.

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

Development Approach ( v2 )

To mitigate that, we're shaping a more CI/CD-friendly v2 process.

• Single Code Components project

• Github repo

• dev branch, which is used for development, and pushed to a special DEV workspace for testing

• PR to main branch, which contains the production code. Here, Git actions or other mechanics can be used to;

  • Automatically install the new production updates to workspaces.

  • Notify the user community of updates that they can selectively pull.

Hypothetically, this would look something like;

npx webflow library share --no-input --config webflow-prod.json

• API_KEY change

• ? Lib name

• Ideally the ability to use a single multi-workspace API-KEY, while specifying the exact workspace ID you're deploying into ( this is Cloudflare Wrangler approach )

Future

• Unified repo with free v. paid versions of a component. to support DEV, TEST, and PROD, with separate branches or feature flags

Webflow Features

Ideally the ability to use a single multi-workspace API-KEY, while specifying the exact workspace ID you're deploying into ( this is Cloudflare Wrangler approach )

Marketplace support for Code Component libs + Hybrid libs. Hybrid libs have the same name, and code components are a facet.

Use cases;

• Map ( CC ) + Pins ( NC ) makes

• Slider ( CC ) + Slides ( NC )

Build feature flags, or runtime feature flags that support both free and paid libs, Ideally within the marketplace. You install Sygnal Maps, and you get a bunch of free stuff. If you upgrade to PRO, features, capabilities, and any usage tie-ins ( LLMs, etc ) expand.

This supports;

• Free trial setups

• Free basic plans + Pro advanced plans

• Possibly plan tiering

Ideally this would be managed internally by Webflow using library-facing feature flags.

Use cases;

• I have a chatbot, I want;

  • Free plan of 10 convos / day

  • Paid plans starting at 100 convos / day

• I have a map library;

  • The image map, and Google map are free

  • The interactive Globe is pro

• I have a mutlistep form library;

  • The basic MSF and all basic forms components are free, limited to a 3 step process.

  • Pro unlocks;

    • Up to 100 steps

    • Advanced validations

    • Advanced forms components like range sliders

PROD

• PR to PROD

• Google Action to deploy to prod?

npx webflow library share --no-input --config webflow-prod.json