[ruckstar]

You're thinking bang-on about the product and where we're going.

Regarding design systems, we have a feature coming that we're either calling Components or Symbols (Sketch's term), we haven't decide which yet. The idea is to package up a configured set of layers into a saved "thing" that can be reused across your experiences. For example a standard button made up of a rectangle, image and text. Designers/builders can then use this button anywhere in their experience and override the value of the text while retaining the style (size, color, font, drop shadow etc.).

Custom data is supported today! You can pass information you know about the user locally to the SDK and use it to personalize your experiences. In the Mac app you can also supply sample user values in the Document Inspector to preview how your personalized experiences will look when viewed within your app by a real user. After adding sample values in the Document Inspector you can use {{user.}} to insert those values into your text layers.

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.

Custom actions are supported today through URLs with custom schemes (aka deep links). You can attach an action to any layer in Judo and supply a custom URL you want it to open when the user taps it. We are expanding on what you can do with buttons in an upcoming release so more to come there as well.

[ruckstar]

I should also add, for your question about custom components, if you build them in Judo, they can be connected to your own APIs via the DataSource, Collection and Conditional layers. It's not super intuitive atm but we have a video course on how it works dropping next week. In the meantime, if you want to try out data sources and get stuck, let me know and I can walk you through it.

[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.