System / Data API suggestion

[vmwxiong]

Had an idea for a potential syntax that might be able to simplify how you access components. Essentially the idea was to allow a system to process components as parameters to some sort of callback function. Hopped on the Typescript discord and they came up with this snippet. You can see the usage at the very bottom, and the stuff above that is an example of how you would implement the types. Think this or something like it might be a reasonable direction to go in instead of creating a separate data object like in the main readme example for Systems.

class Foo { name = "foo" }
class Bar { age = 5 }

type Ctor = new () => object

type ToInstances<T extends Ctor[]> = {
    [K in keyof T]: T[K] extends Ctor ? InstanceType<T[K]> : T[K]
}

function makeReadonly<T extends Ctor>(arg: T): new () => Readonly<InstanceType<T>> {
    return arg as any;
}

function createQuery<T extends Ctor[]>(...args: T) {
    return {
        execute<U>(fn: (...args: ToInstances<T>) => U) {
            return fn(...args.map(x => new x()) as any)
        }
    }
}

const query = createQuery(Foo, makeReadonly(Bar));

query.execute((foo, bar) => {
    console.log(foo.name);
    console.log(bar.age);
});

[minecrawler]

I think I experimented with this before, but was not able to get it entirely right (also asking around). But I think I just saw one missing piece in the puzzle to a struct-less System in your code. I will play around with it. However, I don't think I will change how a system looks entirely. I would like systems to ideally

• be self-encapsulated, meaning it can have its query next to its private fields next to its logic
• have an opinionated architecture, so that systems always look the same. Enforcing a class with implemented interface is very helpful to that end
• be manage-able, so that I can distribute them (across several workers) and instantiate or destroy them without relying too much on user-code

Systems being functions would be a counter to that end imho. It may also be just my preference. I will give this another go and see if I can make the current API simpler, ideally removing the extra struct :)

[vmwxiong]

Yeah going with fully functional Systems would definitely be a pretty specific take on things.

You might want to check out the API that Ape-ECS is going with if you haven't already, might give you some ideas: https://github.com/fritzy/ape-ecs/blob/master/docs/System.md

It's a very different direction, but basically the idea is to think about whether or not you want the notion of multiple Queries vs a single, purely matched system. Both approaches have their pros and cons. Multiple queries allows for easier to implement batching of functionality by interacting with multiple types of entities in one go. On the other hand, it drastically alters separation of concerns, and makes it immediately more difficult to tell what components a system is even capable of "messing up". Just food for thought.

[minecrawler]

I messed around a bit with the type system, and still was not able to come up with a good way to statically type a generic query without generics. While going functional, like in your example, might work, it still does not provide any way for a system to build a cache or be optimized, especially when running in a distributed way - which is the ultimate goal. So I think it is best left to ape-ecs to go down that route, while I try another direction 😉

If you or anyone else comes up with a better plan on how to achieve all goals, then I'm all for merging a PR and make it happen!

[minecrawler]

Hi @vmwxiong , wanted to update you on what I am working on right now, since you may be interested in the change! I am reworking how querying a world works. I finally found a satisfying alternative to the type boilerplate, which may even lead to very simple queries you can easily use everywhere with caching benefits (but sans the life-cycle). The new queries come with better type support, less typing and allow for some new good stuff under the hood. The status is: WIP. I still have to update some under-the-hood things to make it all work, but the Query class has come a long way, so I feel comfortable to share a bit :)

Also, I want to get some feedback from you, if the below demo code is closer to what you would love to work with.

Say goodbye to type boilerplate for Systems:

• Just write a query and do not worry about types, it will work out as expected

Deverloper convenience is still a goal:

• Auto-complete and checking at dev and compile time
• Even read-only status is now enforced by the type system
• Choose the field name yourself for consistency, control and stability, without any surprises when changing fields
• Queries can be written anywhere and will still be cached and updated automatically (if they were registered at world creation)
• Queries can also be one-shot and created dynamically by passing a world object to the iter() method

[vmwxiong]

Ooooh, very interesting. I like the direction for sure.

I think I'd personally want to be using some kind of syntax that would still look like a callback in the end, sort of like

this.query.execute(({info, test}) => {
  info.count++;
  console.log(test);
});

But that might just be me. This would probably be some syntactic sugar on top of what you already provide here, since there may be occasions when you would want to halt prematurely. I just think this kind of format is easier to understand semantically, given my preconceived notions of what a query is and does in general.

Looking good!

[minecrawler]

Your snippet is a nice idea and solves the problem with the field order and type. Writing a method for a callback is simple and straight forward, now So, I did it and will include it as alternative :)

Thank you for the feedback!