[danpalmer]

This all sounds great, thanks for the additional info!

> For custom components, you could either build them as Judo components/symbols when they come out. We have also floated the idea of inserting placeholders in the Mac app which are replaced with your own custom components when rendered in your app. Although we haven't fully thought through how this will work yet.

While I'm sure just building these as Judo components would be quicker, I must give a strong +1 to the placeholder concept. Just thinking about our product card component, there are 3 different interactions, 10+ different visual parts, it's a core concept repeated throughout the app, there are lots of analytics things tied to it, and it has been optimised a fair bit. I don't think we can reasonably expect to rebuild a version in Judo that meets our needs, and I think that would be misusing Judo for things it's not really designed to do.

[ruckstar]

Thank you for this feedback! I'm gonna bump the priority of the placeholder feature in our roadmap. I think the use case you're describing is a very common one. Judo experiences integrate themselves seamlessly into your app in certain places where it makes sense. I think it's equally important for it work the other way around as well. I.e. parts of your native app should be able to integrate seamlessly within a Judo experience where it makes sense. Basically your view hierarchy should be able to mix in and out of Judo experiences depending on the use case.