Studio subsymbol linking / library

Hey,

Pretty much anything I do in studio revolves around building reusable symbols. Sometimes I end up using these symbols in other symbols and this hierarchy can get quite deep and complex. I love that I can do this, but updating these symbols can be frustrating and time consuming. I might come up with an improvement to a symbol and if other symbols are using that one I’d have to export a new version of it and import it back in to all these symbols for the update to have effect all around. I guess this is due to the fact that every symbol has it’s own list of symbol definitions.

I’d love it if we had some sort of optional linking of symbol definitions, so that when I update one, (linked) copies of it would get updated everywhere in the project. Or perhaps it’d be better if we had a global (perhaps project-scope and global-scope separately) symbol definition list? Would probably need support for some kind of grouping / hierarchy to make the list not get out of hand with bigger projects. Could even turn these lists into symbol-libraries that could be maintained and shared in the community?

What do you guys think? Does this make any sense?

1 Like

Hi Ero,

Hope you’re well.

It’s a great suggestion with some very well made points.

We’ve actually discussed this briefly internally but there’s a few considerations we’d need to discuss and address before this would reach a stage where it can be implemented and/or released.

I’ll update this thread once there’s some progress made regarding this feature.

We love hearing everyone’s ideas on how we can improve our platform for our users so thank you for sharing, and make sure you keep them coming. :slight_smile:

Thanks,
Seb

Bumping this, because it’s been brought up a number of times, and it’s hurting right now: we’re going to have at least a dozen differently formatted versions of the current project (and that’s just the start), and because subsymbols can’t be linked nor dynamically loaded into projects, each of these dozen projects will have to be a deep copy.

And then if anything needs fixing or changing in one of the subsymbols, it’ll have to be manually replaced in every single instance.

Yes, we could do our project in UAR instead, but the whole reason we’re here is because of the rapid dev cycle Zap Studio gives us. So … excuse the bump, but it’s been nearly 4 years since it was first asked; it’s still a gaping hole in Zap’s functionality, adding repetitive busywork to our workflows, and limiting the scope of what we could do both creatively and technically.

So… any news yet? If there’s some existential technical reason, please let us know - so at least we’ll understand

¯\_(ツ)_/¯

3 Likes