I’m actually happy to elaborate if you’re interested in how the sausage gets made . Story time below…
The runtime actually doesn’t have this functionality! If it did, I’d definitely expose it as API in a frame tick since it would be a great feature to add.
Let’s travel back to the v2 days, before v3’s Symbols, and before the notion of a Professional variant of Hype. It was early 2014, and about the only app that used a feature called “Symbols” was Adobe Flash Professional. There was a very weird workflow where to get nearly anything done in Flash, you’d have to go though this “Convert to Symbol” phase and chose a type of symbol called a “Movie Clip.” Suffice it to say this was not the height of good UI!
Hype documents were trending to be more complex, and it was clear users needed tools to help reuse components to help manage that complexity. Initial debates were about if this should just be reusable animations to entire multiple-scene documents. Eventually we settled on a scene-within-a-scene concept. To implement this, it required the largest changes and refactoring to Hype’s code base that had ever been accomplished. This was no small task in scope and time, so we did look for ways to minimize the risk and work involved.
One of the decisions had to do with runtime support.
An observation about the Symbol implementation is that it made use of all pre-existing concepts in Hype - elements, timelines, and animations. This meant that instead of writing out the symbol and making various instances at runtime, the instances of the symbol could be created at the export time as if they were ordinary elements.
- There’s effectively no changes to the runtime required – much less work and less bug risk
- The HYPE-NNN.thin.min.js runtime itself stays a smaller filesize since there’s no new code added to support symbols
- Faster load performance
- API can be introduced later (but they can never be taken away!)
- The *_hype_generated_script.js data file could be much bigger if there are many copies of the same symbol
- There’s no programmatic support for creating instances
From a user perspective there’s really not much difference where the instances are created because the result is the same. As we were really not sure if people would even grok Symbols or ever use an API, it seemed to make sense to go with the most expedient method to make the instances as part of the export process. And, this could always be changed later!
So the current state is that the runtime has very little knowledge of Symbols. There’s a little bit sprinkled in to deal with Persistent Symbols and also Symbols’ independent physics environments.
As a side note, I was quite opposed to calling them “Symbols” and definitely did not want a menu item called “Convert to Symbol” since Flash left such a bad taste in my mouth. We did use this name as a placeholder until we could come up with a better idea. As we had mostly wrapped up the feature, Sketch released their v3 that included Symbols. At the time it was rough compared to our implementation, but given Sketch’s popularity we decided naming consistency would work in our favor, so we kept the Symbol feature name. Having this only be in the domain of the Hype Professional upgrade also swayed me that it would be okay. Now lots of design tools have Symbols!
(I will sorrily say this feature won’t make the cut for v4.0.0)