Skip to content

feat: add typeKey option to preserve resource type in deserialized objects#258

Open
SBoudrias wants to merge 1 commit into
andersondanilo:masterfrom
SBoudrias:feat/type-key-option
Open

feat: add typeKey option to preserve resource type in deserialized objects#258
SBoudrias wants to merge 1 commit into
andersondanilo:masterfrom
SBoudrias:feat/type-key-option

Conversation

@SBoudrias
Copy link
Copy Markdown

Summary

This PR adds a typeKey option that allows preserving the JSON:API resource type in deserialized objects. This is useful when you need to know the original type of a resource after deserialization, especially when dealing with polymorphic relationships.

Deserialization

When typeKey is specified, the resource type is included in the output using the specified key name:

import { deserialize } from 'jsonapi-fractal'

const response = {
  data: {
    type: 'users',
    id: '1',
    attributes: { firstName: 'Joe' }
  }
}

deserialize(response, { typeKey: 'type' })
// Returns: { type: 'users', id: '1', firstName: 'Joe' }

This works for:

  • Main resources
  • Array of resources
  • Included relationships
  • Relationships not in the included array (returns { id, [typeKey]: type })

Serialization

When serializing with typeKey:

  • The typeKey attribute is automatically removed from the output (so it doesn't appear in attributes)
  • Validates that idKey and typeKey are different
  • Validates that the typeKey value matches the specified type (if present in entity)
import { serialize } from 'jsonapi-fractal'

const entity = { id: '1', type: 'users', firstName: 'Joe' }

serialize(entity, 'users', { typeKey: 'type' })
// Returns: { data: { type: 'users', id: '1', attributes: { firstName: 'Joe' } } }
// Note: 'type' is stripped from attributes

Test plan

  • Added tests for deserialization with typeKey
  • Added tests for serialization with typeKey
  • Added tests for error cases (idKey === typeKey, mismatched type values)
  • All existing tests pass
  • Lint passes
  • Build passes

…jects

This adds a `typeKey` option that allows preserving the JSON:API resource
type in deserialized objects. This is useful when you need to know the
original type of a resource after deserialization, especially when dealing
with polymorphic relationships.

When deserializing:
- If `typeKey` is specified, the resource type is included in the output
  using the specified key name
- Works for both the main resource and relationships (included or not)

When serializing:
- The `typeKey` attribute is automatically removed from the output
- Validates that `idKey` and `typeKey` are different
- Validates that the `typeKey` value matches the specified type (if present)

Example:
```ts
deserialize(response, { typeKey: 'type' })
// { type: 'users', id: '1', firstName: 'Joe' }

serialize(entity, 'users', { typeKey: 'type' })
// Strips 'type' from attributes
```
@github-actions
Copy link
Copy Markdown

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 15 days.

@github-actions github-actions Bot added the Stale label Mar 21, 2026
@SBoudrias
Copy link
Copy Markdown
Author

SBoudrias commented Mar 24, 2026

I can't remove the label myself. Would really like to see this get in. Let me know if you want me to change anything.

That being said, I understand it's not been modified in 6 months. Hoping the project isn't dead.

@github-actions github-actions Bot removed the Stale label Mar 25, 2026
@github-actions
Copy link
Copy Markdown

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 15 days.

@github-actions github-actions Bot added the Stale label May 24, 2026
@SBoudrias
Copy link
Copy Markdown
Author

Still would like to get this in 🥹

@github-actions github-actions Bot removed the Stale label May 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant