Server does not sync state with clients on the latest version

[jog1t]

Steps to Reproduce

Example CodesSandbox: https://codesandbox.io/s/dazzling-mountain-hwzfxh

1. Open CodeSandbox
2. Preview of HTML shows client's state (check console for more details).
3. Client sends ping message to server.
4. Server every 1s modifies the state.

Context

Server receives ping messages, but client is not updated with the latest state. Checked with DevTools, server is not sending any message (sends only two at the beginning, I think they are schema types related).

Adding @colyseus/monitor, and inspecting room's state also shows empty state.

Your Environment

• Colyseus Version: 0.14.23, ws-transport 0.14.21, schema: 1.0.34
• Node.js Version: v14.8.1
• Link to your project: https://codesandbox.io/s/dazzling-mountain-hwzfxh

[endel]

Hi @jog1t,

Interesting find. It seems that defineTypes() and defining plain JavaScript properties directly don't play nicely together:

class State extends Schema {
  number = 0;
  property = "";
}
defineTypes(State, {
  property: "string",
  number: "number"
}); 

I've just tried commenting out the property initializer and then your example works: (See sandbox link)

class State extends Schema {
  // number = 0;
  // property = "";
}
defineTypes(State, {
  property: "string",
  number: "number"
}); 

For TypeScript this is not an issue. We need to investigate why this is happening, if you have any clues, I highly appreciate it!

[jog1t]

@endel thanks for quick reply! 🙌🏻 Didn't have too much time today to look properly at this, but it looks like getters/setters are not set properly for properties with initial values. Will try to look at it in the following days.

[jog1t]

It's looks like TypeScript's type decorator also does not work 😢. I've tried also using different versions, but without any luck.
Here's the same example from CodeSandbox, but uses ts-node or vite-node to run the server - https://github.com/jog1t/colyseus-issue-510.

🎉 What has worked for me is to define a schema class similar to this (see working-solution branch):

class State extends Schema {
  constructor() {
    super();
    this.property = "";
    this.number = 0;
  }
}

defineTypes(State, {
  property: "string",
  number: "number",
});

interface State extends Schema {
  property: string;
  number: number;
}

[WesleyClements]

This seems to only be a problem for TypeScript if you are compiling to ES2022/ESNext. Public instance fields are added to subclass instances using Object.defineProperty immediately after the super() call returns so the property defined in the Schema constructor is being overwritten. I don't think there is an elegant solution to fix this currently. Could move the getters and setters definition to outside the constructor but that's kind of wonky.

[devlsh]

This seems to only be a problem for TypeScript if you are compiling to ES2022/ESNext

Just upgraded my entire stack to compile to ESM and this is the only major issue I've had so far. Would be great to have some movement on this!

[justin-m-lacy]

This seems to only be a problem for TypeScript if you are compiling to ES2022/ESNext. Public instance fields are added to subclass instances using Object.defineProperty immediately after the super() call returns so the property defined in the Schema constructor is being overwritten. I don't think there is an elegant solution to fix this currently. Could move the getters and setters definition to outside the constructor but that's kind of wonky.

If this is as you say would the solution be to abandon subclassing of schemas entirely; instead turning schemas into typed data containers? const playerSchema = new Schema<PlayerType>({ ...playerData });

It feels similar to what Pinia does for reactive data stores.

[khoakomlem]

It's looks like TypeScript's type decorator also does not work 😢. I've tried also using different versions, but without any luck. Here's the same example from CodeSandbox, but uses ts-node or vite-node to run the server - https://github.com/jog1t/colyseus-issue-510.

🎉 What has worked for me is to define a schema class similar to this (see working-solution branch):

class State extends Schema {
  constructor() {
    super();
    this.property = "";
    this.number = 0;
  }
}

defineTypes(State, {
  property: "string",
  number: "number",
});

interface State extends Schema {
  property: string;
  number: number;
}

Any solution for using @decorators defining schema? My current solution for this is just change target from esnext to es2018.

[endel]

Just found a workaround for this: setting "useDefineForClassFields": false on the tsconfig.json file:

  "compilerOptions": {
    "useDefineForClassFields": false,
    // ...
  }

This setting may conflict with projects that rely on it being true (which is the new default for ES2022+ and the upcoming ECMA runtime behavior)

More info:

• Documentation for useDefineForClassFields
• More on the history of the decisions TypeScript made behind emitting class properties

[SIGSTACKFAULT]

works:

export class MySchema extends Schema {
    constructor(){
        super();
        this.foo = 3;
    }
    @type("int32") foo: number;
}

doesn't work:
but does work with "useDefineForClassFields": false

export class MySchema extends Schema {
    @type("int32") foo: number = 3;
    // presumably the getters and setters are clobbered?
    // at any rate the setter is never called if you do this
}

[endel]

Closing this as it seems a non-issue for the moment. #510 (comment)