Is symbol-instance is actually an element with a special class name ( behind the scene )?

[VishwasGagrani]

Is symbol actually a special kind of element behind the scene ? Or is it a javascript class?

I was looking at this thread:

Instantiating Symbols

That’s what this thread… Is there a Physics API? …has been about. Hype could be awesome for game development, but it hasn’t really leveraged the matter.js API. There’s a “Matter Create” method… http://brm.io/matter-js-docs/classes/Body.html#method_create While I’m not sure if that would work wit Symbols, it would be really cool for making games if it did.Yet, a Symbol can be moved and hidden, so a similar effect can be created. It’s just not as dynamic.

And it seems, I cannot instantiate a symbol. So is it not possible to add symbol dynamically? And needs to be done only via the IDE for now?

Vishwas

[h_classen (Hans-Gerd Claßen)]

Every hypespecific element hast to exist before Export …

[MaxZieb (Loves Hype)]

It is both: HTML and JS (runtime) “wired” together…

There is the runtime that creates the symbols on the fly. But the runtime doesn’t expose that functionality to the end user. Meaning you cannot attach symbols from the library through runtime functions (native support). Just copying the HTML part leaves the runtime in the dark about the „new“ symbol and it won’t be accessible via the Symbol API. Meaning no timelines etc. it is a soulless copy in the sense of (lat.) “animare”.

We are all hoping to have an official attachSymbol function. This functionality can also not be programmed as an extension as the runtime is encapsulated (rightly so) in an immediately invoked function expression protecting it‘s inner functionality.

Immediately invoked function expression

You can always hack the runtime to expose more but not only is this a repetitive patching task on ever update by Tumult, you also are dealing with parts (they also feature MIT parts) of software that are intellectual property of Tumult. Meaning redistribution of the runtime could be possible a legal issue.

[VishwasGagrani]

My aim to ask this question was to only confirm the fact that ultimately every container is an element. And symbols are just for the easing things up in the Hype UI. And so I don’t have to worry about any other class type while scanning through the elements and nodes. And treat symbols just like an element only.

[h_classen (Hans-Gerd Claßen)]

Hype has got an own section in its API relying Symbols. …
From the Viewpoint of HTML every hypeelement ist a div.

[jonathan (Jonathan Deutsch)]

@VishwasGagrani

My aim to ask this question was to only confirm the fact that ultimately every container is an element. And symbols are just for the easing things up in the Hype UI. And so I don’t have to worry about any other class type while scanning through the elements and nodes. And treat symbols just like an element only.

This is correct.

You can, for instance, add a unique element ID on the symbol instance element.

For development efficiency reasons, at export symbols are converted to their elements and timelines, and put inside of a containing element. While we make no promises/schedules, it definitely would be great for a future version of Hype to be able to dynamically make symbol instances.

(note that persistent symbols are handled a bit more specially by the runtime, as those DOM elements get transferred around between scenes)