Closed Ithamar closed 3 years ago
We took this out because it's an anti-pattern. You should really be using systems to access/mutate component data. If you really really need to get component data outside of a system you can pluck it directly from the registry.
world.registry.components.COMPONENT_NAME.property[eid]
Right, I can see an argument for keeping Systems nicely isolated, and sticking to accessing components they are registered for. But in that case, I guess hasComponent should have gone too, or is there a good reason to keep that?
It's used internally in this iteration of the API. We used to have getComponent()
but we removed it as to not encourage people to create performance bottlenecks in their code. We should probably remove hasComponent()
from the API as it's misleading :). That said, until we hit version 1.0.0, the API is subject to change. We are working on the next iteration of the API thats going to be somewhat of a major revision.
Okay, fair enough. That "major revision" sounds like it might be wise for me to wait a little before investing too heavily in the current API? Or would migrating a code base from the current to the new API be pretty straightforward?
It should be pretty straight forward. Probably could write a codemod to automate it. Going to be hard to know until we finalize the API, but we can keep you posted as it develops.
Okay, thanks for the information!
I guess this is intentional, but although I can check if a particular entity has a component (World.hasComponent) there does not seem to be a way to get the data for that component (besides using a Query, which feels utterly wrong).
Am I overlooking something obvious?
[EDIT] Moved some unrelated comments to a separate issue