Request a way to specify property's serialized name

[shrinktofit]

Creator serializes property's name as-is and prohibit serializating accessors. An object might be serialized as the following:

// The class
@ccclass
class Meow {
 get p() { return this._p; }
 set p(value) { this._p = p; }

  @property
  private _p = 0;
}

// Serialized
{
  "__type__": "I don't care",
  "_p": 0,
}

Sometime this troubles.

Issues while refactoring

It's a common pattern that people refactor the code to encapslute a property. That's, refactor @ccclass class Meow { @property p = 0; } to the above structure.

This breaks old serialized data since the property's name is changed from "p" to "_p".

Creator rescue developers with a "formerlySerializedAs" tag.

Issues when the property key is not a plain string literal

All properties in the following class can not be serialized:

const tag = Symbol();

class Meow {
  [tag] = 0; // Symbol property key

  #p = 0; // ES private field
}

Readability

Creator asset files are designed to be human-readable. It's nice if we could eliminate the _ or m_ prefix in serialized assets.

---

All these issues are related to "we can't specify a serialization name to a property". So I'm requesting such a feature.

It may look like:

class Meow {
  @serializeAs("p")
  #p = 0;  // Will be serialized as "p"
}

If users have theirown name convention, they may even extends this property, to reduce size of serialized asset:

// Remove the leading slash and forward to call `serializeAs`
function removeLeadingSlashWhenSerialize(...args) {
  const [_, key, ...remain] = args;
  return serializeAs(_, key.startsWith('_') ? key.slice(1) : key, ...remain);
}

class Meow {
  @removeLeadingSlashWhenSerialize
  _p = 0; // Will be serialized as "p"
}

[shrinktofit]

@PPpro @holycanvas @jareguo What do you think about this?

[jareguo]

I don't think I have ever consider about this idea, really interesting.
A little summary of the reasons:

1. "formerlySerializedAs" tag is not elegance enough
2. Support ES private field // But how? The deserializer is not able to assign any value to a private field.
3. Support Symbol property key
4. Human-readable

For point 3, I think we should use symbol.description as the default name.

const tag = Symbol('p');  // Will use tag.description( 'p' in this case ) to address the property
class Meow {
  @property
  [tag] = 0;
}

For point 4, are you sure? Even Unity does not resolve the readability of yaml. When serialization issues arise, they often require R&D troubleshooting, and the more aliases there are, the more the burden of troubleshooting increases IMO. Why not just Keep It Simple and Stupid.

Besides. If we support serialization-alias. I think the only way to avoid _ is use serializeAs every where. So why we don't just add a optional parameter for @serializable?

class Meow {
  @serializable("p")
  #p = 0;  // Will be serialized as "p"
}