|
|
|
|
|
|
by karaterobot
1182 days ago
|
|
|
Hey, I'm impressed by that demo video. I especially like all the nice little touches that let you grab images, paste in data, and so on. One question I didn't see answered was: how does someone define one of these components? Does Noya infer the rules about which component to translate a user-defined shape into, or does someone have to go in and say something like "if it's the full width, and it's at the top of the screen, it's probably the navigation header"? It feels like defining the rules for page-level layout blocks, vs. fiddly little micro UI elements could get tricky. Oh, and how do components get into the system at all? Does it have to be an off-the-shelf design system (like Chakra, which you mention supporting) that you've translated into Noya, or can I add my company's design system myself? |
|
|
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.