feat: JSON property order

[splincode]

@PropertyOrder([ 'id', 'password', 'email' ])
export class User {
   email: string;
   id: number;
   password: string;
}

plainToClass(User, jsonData) // User { id: 1, password: 'xxx', email: 'etc@email.com' }

[Logrythmik]

Or just preserving the order they are declared in. This is a real pain for me.

[prateekkathal]

Bump! .... Can we please look into this? I think this will be a great addition.

[NoNameProvided]

Can you guys explain the reasoning behind this? Why is it important to be able to specify the property order on the object?

[prateekkathal]

@NoNameProvided The real reasoning I feel is readability in responses.

When using Class Transformers, the response changes into the order of

1. Non-transformed properties
2. Transformed properties

If we have another decorator defining the order or maybe just preserve the order the properties are declared in, it'll ensure higher response readability.

[prateekkathal]

@NoNameProvided Bump again.

[NoNameProvided]

This is low prio for me, I still don't see the justification for this. If we can agree on some acceptable design someone can try to implement it, but first we need to agree on the API.

[alexis-y]

+1 to caring about property order. And I have a concrete example:

I have server-side C# classes, and I'm using JSON.NET to move them back and forth over the wire.

Now, that library expects a $type property as the first property of a JSON object to be able to tell which class to deserialize into, particularly when it can't infer it from context. If I have to guess, it's because it's reading the JSON as a stream, and it needs to know which class to instantiate before taking in the rest of the object.

This is very similar to and ties neatly with class-transformer's discriminator. But currently CT's classToPlain is putting it at the end of the object, which I have to work around.

It's not exactly what this issue is about, but it's pretty close.

[boutchitos]

+1 to caring about property order. And I have a concrete example:

I dump data into JSON files which are under git control. Since I started to use plainToInstance, the JSON files are modified only because of properties order. I would like the order to stay the same for speeding up diffing of modifications.

[prateekkathal]

@boutchitos Everyone has a different use-case tbh.

Typestack team - Will be great if we can get something done on this. I have to create customer transformer classes to fix this issue (see below). This is not ideal.

export class UserTransformer implements User {
  id!: string;
  firstName!: string;
  lastName: string;
  name: string;
  email!: string;
  
  @Expose({ groups: ['user.timestamps'] })
  createdAt: Date;

  @Expose({ groups: ['user.timestamps'] })
  updatedAt: Date;

  constructor(partial?: Partial<UserTransformer>) {
    const variablesToAssign = [
      'id',
      'firstName',
      'lastName',
      'name',
      'email',
      'createdAt',
      'updatedAt',
    ];

    variablesToAssign.forEach((variable) => {
      if (!partial[variable]) {
        partial[variable] = null;
      }

      Object.assign(this, { [variable]: partial[variable] });
    });
  }
}

I'd really appreciate if this is prioritized.

CC: @NoNameProvided

[dzikowski]

+1 and I have another example: Private/public key signing. I need to sign my JSON payload with private key and verify the signature with public key. Thus I need to have a way to serialize my payload in a deterministic way. The order of fields should always be the same (in my case they should be sorted alphabetically).

[jrosenbl1]

If it helps anyone: I found if I set excludeExtraneousValues = true in ClassTransformOptions and explicitly @ Expose everything, properties are output in the "correct" order. For my case at least, I think the disorder comes when the array of object keys is concatenated with the array of "exposed properties" in getKeys() in TransformOperationExecutor.js. So with excludeExtraneousValues = true, the object keys are skipped and just the @ Exposes are read in order.
That said, I can see value in an @ Order property/method/accessor decorator that takes a single number (defaulting to 0) and is read in transform() or getKeys().

[yaronEcoPlant]

I'm also experiencing issues with the order. Especially when using the @Type decorator.
When doing the plainToInstance transformation, the property with the @Type decorator is checked before the the discriminator property has been checked, therefore it couldn't find the right type to convert to:

Happens in this area of code:
https://github.com/typestack/class-transformer/blob/develop/src/TransformOperationExecutor.ts#L232