hey @Oleg Isonen . Thanks
We are launching radix ui integration tomorrow, just for the starters where things are going
our goals are big but the team is small, so we are very careful about prioritization
in particular expectations on code quality are high and core team has to review every change carefully
after this launch, next big milenstone will be CMS integration pipeline - ability to integrate with any CMS, starting with one that we integrate ourselves
this will unlock a lot of use cases
And we are heavily thinking and building extensibility, this is the core of everything, but we haven't open up any apis yet as an official public api, simply because our ressources are focused on getting builder to production grade capabilities.
as we build out first cms integration, we will start documenting and finalizing the public api for extensibility.
in fact there is already a need to start documenting the meta data json for components
Syncing design tokens with external services is also part of the roadmap, but I am not sure it takes priority over CMS and APIs
In fact I think we need to provide an api (which we already have internally) to access the entire data to a 3rd party plugin and this way it should sync the bits it needs with any service.
Example: a plugin could access all design tokens in webstudio format, convert them to the standard design tokens format and sync them with figma design tokens plugin.
For a plugin like this to be possible we need
- ability to install plugins
- render plugin UI (similar to figma maybe?)
- provide them with our data access api
I think all of this has to start with the data access api and it's docs
UI to install plugins could be the same UI for installing UI kits and other complex systems.
I think fundamentally user shoudln't care if its a UI kit, plugin or anything else, they are just installing the functionality and it is using the apis it needs.
We also need to decide if 3rd party integrations would be centrally governed, e.g. a single repo where everyone contributes to or completely distributed.
Centralized has a benefit of more quality control, more eyes on the changes and potentially more consistency.
Decentralized benefit is ownership, having someone to fully control the source code of the integration they built and do anything they want any time.
Maybe we need both and highlight them differently.
As for concrete actions for you right now, I would first spend some time using it, learning the code base a bit etc, get a broad understanding of everything we created an posted in the blog
then reach out in dm to figure out some more concrete steps
Wooll. Thanks for the awesome overview. I'll read this ASAP.
I think the same: "Maybe we need both and highlight them differently."
do you think the builder should have a tokens management panel? I think I did read something from you on some discussion o GH about this
