Skip to content

Alias names / Different keynames after serialization #121

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
weeco opened this issue Jan 11, 2018 · 5 comments · May be fixed by #1192
Open

Alias names / Different keynames after serialization #121

weeco opened this issue Jan 11, 2018 · 5 comments · May be fixed by #1192
Labels
comp: decorators Changes affecting the decorators. type: feature Issues related to new features.

Comments

@weeco
Copy link

weeco commented Jan 11, 2018

The use case:
I use this library for a REST API wrapper where I map the returned JSON responses to my classes. I am struggling with just one specific case.

The REST Api returns a cardName, but unfortunately no cardId which could be used to retrieve the cardName. However I can resolve the cardId by a given cardName and I highly prefer to store cardIds instead of the cardNames in my database.

The code:

function cardResolver(cardNameOrId: string | number): number {
  // If we serialize a previously deserialized object we will already get the cardId instead of a name
  if (typeof cardNameOrId === 'number') {
    return <number>cardNameOrId;
  }

  return CardHelper.getCardByName(cardNameOrId).id;
}

@Exclude()
export class BaseCard {
  @Transform(cardResolver)
  @Expose({ name: 'name' })
  public id: number;
}

The problem:
This requirement is a challenge though, because now the library is supposed to handle two different schemas. One is the REST Api which returns the cardName and the other is my database which returns the cardId.

While my @Transform function is not an issue (it can handle both json inputs and recognizes the difference using the type), I need some sort of alias, since the input json can be either:

{ cardName: 'Goblin Barrel' }

or

{ cardId: 260000013 }

My question:

Can I achieve this with the given library features or does it make sense to add an alias feature?

@weeco weeco changed the title Alias names / Different serialized keynames Alias names / Different keynames after serialization Jan 11, 2018
@NoNameProvided
Copy link
Member

Hi @weeco!

Thanks for the detailed report!

In your example, you use id but then you reference your inputs as cardId and cardName.
Is this correct?

Based on your description, I would expect the inputs being id and cardName and you want to add something like an @Alias decorator, what checks if there is an id property on the object and if not, it tries to add it from the cardName property? Like:

@Alias({ from: 'cardName' }, { toClassOnly: true })
@Transform(cardResolver)
public id: number;

Effect:

// input => value
{ id: 342 } => { id: 342 }
// input => value (via alias then transform)
{ cardName: 'name-of-car' } => { id: 342 }

Did I understand you correctly? If this is your desired goal, there is no way of doing this at the moment.

However, this request makes sense and there is already a similar request in #99. So this can be implemented, but later, first I want to finish class-validator and move to class-transformer after.

@weeco
Copy link
Author

weeco commented Jan 11, 2018

Yes you understood it perfectly well, that's exactly the desired behaviour.

@NoNameProvided NoNameProvided added type: feature Issues related to new features. comp: decorators Changes affecting the decorators. labels Oct 26, 2018
@byhoratiss
Copy link

Hi, is this @alias decorator available?
I've the same situation, an API exposes an attribute "@id" but I would like to use as "id" attribute within my Class.
Am I missing something?

Thank you!!

@ghost
Copy link

ghost commented Jun 13, 2020

Wonder if this can be done, 2 years pasted and it feels like it'd be a handy feature :)

@NoNameProvided
Copy link
Member

Posting on issues asking whether it will be added will never make the process faster. Today I spent 10 hours answering questions which at least a third of them doesn't even take the time to read the documentation. So if you want to make this feature get implemented faster, you can always

  • implement it yourself
  • answer questions so I actually have any time to code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
comp: decorators Changes affecting the decorators. type: feature Issues related to new features.
Development

Successfully merging a pull request may close this issue.

3 participants