Runtime Instance Data

[krakow10]

RBXScriptSignal is not serialized or represented in the Roblox file formats, but is associated to specific instances at run time. Implementing this without the RBXScriptSignal being directly owned by the Instance means creating a garbage collector.

I can think of three different implementations of this, and have written two:

1. Generics (Generic WeakDom using AsRef<Instance> #488)
   • awful but extensible
2. Feature gated field (Add Userdata Field To rbx_dom_weak::Instance Behind Feature Flag #513)
   • surgical but not useful for others
   • could be changed to Option<Box<dyn std::any::Any>> to drop mlua (implemented here)
3. Implement a generic field for Instance rather than Instance itself being a generic
   • this would probably be a smaller mess than 1 and less awful

I am looking for feedback on whether this can make sense upstream or whether I should continue to maintain a fork of various rbx-dom crates. Thanks.

[kennethloeffler]

Additional Instance data/methods required for your program do not need to belong to rbx_dom_weak's Instance - and Instance is not meant to be a generic data bag, but rather only the data and behavior required to correctly represent and interact with a Roblox Instance.

One pattern used by several consumers, including Rojo, Argon, and Lune is to define a "wrapped DOM" and/or "wrapped Instance" composed of rbx_dom_weak's WeakDom/Instance, plus any additional data and methods. This compositional approach is very flexible and keeps concerns separate.

Is there a reason why this approach will not work for you, necessitating changes to rbx_dom_weak?

[krakow10]

Thanks for the feedback. The fact that there are three users of rbx_dom_weak wrapping every dom manipulation method is surprising to me. Maintaining a separate HashMap and an entire suite of manipulation wrapper functions seemed like an anti-pattern because of the possibility of a synchronization mistake, which is why I was pursuing a "generic data bag" approach (love this term you coined xD).

Seeing the duplicate code across the three implementations does give me an idea for another alternative. Perhaps rbx-dom can supply and maintain macros to generate an api wrapper that attaches custom metadata. This would deduplicate the code, as well as reduce the possibility of synchronization mistakes.

None of the "data bag" code I've written thus far seems tenable, so seeing how other library users are tackling the issue is valuable to me. I'll ruminate on the new information and see what I can come up with.