You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when registering classes (components, systems, subcomponents, etc.) you specify a string ID. This makes it difficult to write modular code. For example, say you have one plugin that registers a component class to ID "sprite". If you want to use another plugin that registers a different "sprite" component, you can't do so without creating issues with the first plugin.
How can this be resolved? One way might be to write the plugins with config options that allow you to override the ID used for each class. This seems kinda hacky though.
Another possible solution would be to do something similar to vuex modules: https://vuex.vuejs.org/guide/modules.html#module-local-state. For example, maybe there could be rude "modules" that define a namespace for registered classes. Still, this would really just be pushing the issue up a level, because then there could be collisions between equivalent module names. This would at least make it easier though, instead of having to configure many different IDs you would only need to configure the module ID. I think for now, having a way to group registered classes into modules would be a sufficient solution.
The text was updated successfully, but these errors were encountered:
I think I've come up with a solution for this, see DataContext. This allows me to wrap the component ID associations into separate objects. I also changed several methods like addCom() so that you can pass context objects, or expicit classes.
That said, I'm now wondering if using these dataContext objects is really the right approach. For example, if I make a plugin that uses several component classes and systems, should the component IDs be fixed, or should you be allowed to extend the plugin by re-mapping those IDs? For now, I think it's at least better than the original way things worked.
Currently, when registering classes (components, systems, subcomponents, etc.) you specify a string ID. This makes it difficult to write modular code. For example, say you have one plugin that registers a component class to ID "sprite". If you want to use another plugin that registers a different "sprite" component, you can't do so without creating issues with the first plugin.
How can this be resolved? One way might be to write the plugins with config options that allow you to override the ID used for each class. This seems kinda hacky though.
Another possible solution would be to do something similar to vuex modules: https://vuex.vuejs.org/guide/modules.html#module-local-state. For example, maybe there could be rude "modules" that define a namespace for registered classes. Still, this would really just be pushing the issue up a level, because then there could be collisions between equivalent module names. This would at least make it easier though, instead of having to configure many different IDs you would only need to configure the module ID. I think for now, having a way to group registered classes into modules would be a sufficient solution.
The text was updated successfully, but these errors were encountered: