-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Brain dump #1
Comments
What's missing:Compared to our recent prototypes, this leaves out the ability to create "fake parts" in the UI tree that don't map 1:1 to CSS components. |
The downside of having an extensive interop API that covers so many aspects of a component is the requirement it puts on the author to use the proprietary API and the commitment to depend on the API and the platform. What if there would be a way to use props only as a public API and render component on different targets same way react renders them to dom, string or native platforms? I might be lacking the context here though. |
Yeah, that's for sure. It's all very early on this idea, but the elevator pitch on interop is "use this CSS-in-JS library and it will export to design tools, is visually editable in JSX tools, and generates its own docs". It might even just be a layer on top of existing CSS-in-JS libraries, so we don't reinvent the wheel. I am definitely keen to use props and TS definitions to reduce the manual registration work and API weight. You do need some additional information to make the above goals possible though – and you see things like Framer's We've been working on this internally for Modulz primitives. The registration API is verbose at the moment; we're kind of living in the problem space for now until we fully understand the requirements, and then we'll polish it up into something friendly and approachable. Anyway, that's the context. Would love to hear more of your thoughts about this. |
@StephenHaney Yeah sounds like a good approach to start with something you can control and then add more things which can be supported out of the box with no registration code like |
Yeah, big fan of their work. I actually talked with John and Jackson specifically on the need for more info than props provide... they're trying to figure out the same thing for Blocks, though they aren't trying to export the components to drawing tools as well. At the time, they forked Framer's |
Allo 👋
This is an initial effort to organize and catalog the meta data we need to create fully visually editable components.
It's super early, and we are more concerned with identifying the needs and less concerned with solutioning the perfect API at this stage.
Here's one pseudo-code approach with fake examples. Please pick it apart for what won't work:
Registering a component
Using the Parts to build a component
Registering a new component with interop will return a Styled Component (or CSS-in-JS component of your choosing). We'll probably need to re-arrange this example code or use a property to access the CSS-in-JS component like
<Slider.Component />
Creating examples
Collocating docs
Though I think most docs will be built visually in the Style Guide visual editor, they'll write to the same JSON object as the rest of this... so I think there should be function endpoints to write it too. This is the least defined part of all of this, but wanted to keep it on the list of needs.
Data IDs to support hover highlights:
Global helper data
What am I forgetting?!
The text was updated successfully, but these errors were encountered: