Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling registration collisions #7

Open
mrrogge opened this issue Nov 21, 2020 · 1 comment
Open

Handling registration collisions #7

mrrogge opened this issue Nov 21, 2020 · 1 comment

Comments

@mrrogge
Copy link
Owner

mrrogge commented Nov 21, 2020

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.

@mrrogge
Copy link
Owner Author

mrrogge commented Apr 27, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant