brochington
commented
6 years ago Thank you! 😊
Is the <TweenComponent /> in your example a System?
In ECS, data is passed around mostly through Components. In React, data is passed via props.
I've developed another project called Akkad that tried to implement an ECS system over top React. In it Entites(which were React components) had children which were Systems (React components as well). I bypassed the abstraction you have above, and injected the "Components" via props directly into the Systems. This worked...okay. One of the problems with this approach was that in order for Systems to be decoupled from the entity itself, they would have to be passed in as children. It would be hard to pass Entity id's, and hard to correctly time when child Entities or Systems should "render" themselves.
I took a lesson from how the A-Frame project handles ECS, and moved systems to a special prop. This has simplified things A LOT, especially in the decoupling department.
Another huge win has come when trying to teach how Declarity works to others. I found that many thought it hard to understand the difference between an <Entity /> and a <Component /> especially when React's main structure is called a <Component /> as well. Being able to look at anything that is JSX, and know that it is an <Entity /> of some sort, helps to make things explicit.
Personally, I like the understanding that when I look at a render method's output, I'm looking at the "tree" of my structure. When I'm looking at an array of Systems, I'm looking at the horizontal processing that occurring on the state related to the entity.
There is more to it than just this, but hopefully this will give you a better understanding of why I've chosen the API that I have. 😄
First - Nice project! was considering something similar.
I've built a and used a few ECS's. I was wondering why you explicitly declare the systems on an entity? Why didn't you declare components as children of entities and let some other code match the entity to the right system(s)?
e.g.