dabbott
Joined 10 years ago
Joined 10 years ago
For getting components into the system: we're working on a protocol (more specifically a TypeScript interface) that defines a mapping from component types that the tool understands (sidebar, navigation header, etc) to component implementations. You can add component types that the tool doesn't understand too, but like you point out, then it's more work to define the rules they use. Anyway, you can bring your company's design system into the tool by implementing this protocol - the tool loads your implementation (currently from npm, but could be anywhere) at runtime.
Right now the default rules are based on component type, so when you add a new design system implementation, you start with the default rules for known components. These can be customized on a per-design-system basis via the protocol, but again it's a bit tedious to do. We've explored using generative AI for determining component rules which seems promising so far. This could potentially be less tedious and more flexible for custom design systems, and is one area we hope to explore more.
1. There isn't anything fundamental about that tool that requires React. We have a lot of React experience and it's a very popular framework, so it made sense for us as a place to start, but we can definitely consider supporting other options.
2. Absolutely! We have a first draft of our mapping protocol already that works reasonably well, but still needs more iteration before we open things up. It supports a custom hook for attaching things to the DOM, so shouldn't require React specifically either.
Can you share a little about how you use web components, so we can better understand what an integration should look like? Do you use any kind of JS framework (at build time or runtime)? Do you use JSX, or is it all vanilla HTML?
Creating real designs and shipping to production within a constrained environment (e.g. https://medium.com/airbnb-engineering/a-deep-dive-into-airbn...) can be super high leverage, so that's ultimately where we want to go. Right now every company that wants to do this has to build it themselves. We didn't use an off-the-shelf solution like Webflow at Airbnb (afaik) because there was no realistic way to integrate it into our stack. I'm not sure if Noya's code export will be what people end up using for this - maybe some kind of JSON-config or something else will be the more useful artifact.
As an analogy, Retool makes it easy to create internal tools, and is usable by more than just eng. But somebody on the eng team needs to first configure it a bit (e.g. plug in the company's data sources) before making real tools becomes possible/efficient. Noya will require a similar level of configuration to become usable in these more advanced scenarios, but we think the value it delivers will be worth the effort.
We're currently working on a protocol for adding new design systems, which will support integrations at different levels, from component libraries like Chakra to more complete design systems like Airbnb's DLS. We'll have more to share on this soon!