Skip to content
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

Feature: Support nest @Key decorators #96

Open
schuchard opened this issue Feb 24, 2020 · 6 comments
Open

Feature: Support nest @Key decorators #96

schuchard opened this issue Feb 24, 2020 · 6 comments
Assignees
Labels
approved Approved for Implementation enhancement New feature or request
Milestone

Comments

@schuchard
Copy link
Contributor

Sometimes the unique identifier is not at the root of an entity. Adding support for nested decoration would be nice.

class Order {
	name: 'Food Order'
	metadata: {
		@Key id: 12345, 
	}
}
@jrista jrista added enhancement New feature or request proposal Proposal for New Feature/Functionality under review Currently under merit/design review and removed proposal Proposal for New Feature/Functionality labels Feb 24, 2020
@jrista
Copy link
Contributor

jrista commented Feb 28, 2020

I looked into this more. I'm not sure our original idea of simply decorating a nested property with @Key is going to work. There is no standardized way to get the parent object of an object in JS. There are ways to get the parent prototype, but for most arbitrary objects, even nested ones, that will be Object.prototype and not the parent object instance.

I think the only way to support more complex and arbitrary keys, is going to be through the @Entity decorator. Something like:

@Entity({
    modelName: 'Order',
    key: 'metadata.id'
})
class Order {
    name: 'Food Order',
    metadata: {
        id: 12345
    }
}

We could also support an array of strings for simple composite keys, as well as a function, allowing very flexible and powerful key generation. For backwards compatibility of course, the current @Key decorator would remain in tact as it currently works, but the key property of @Entity would be an alternative way of configuring the key for entities.

@jrista
Copy link
Contributor

jrista commented Feb 28, 2020

Composite key with array notation:

@Entity({
    modelName: 'Order',
    key: ['purchaseOrderNo', 'metadata.id']
})
class Order {
    purchaseOrderNo: 'FO_C1',
    name: 'Food Order',
    metadata: {
        id: 12345
    }
}

Functional option:

@Entity({
    modelName: 'Order',
    key: order => order.metadata.id
})
class Order {
    name: 'Food Order',
    metadata: {
        id: 12345
    }
}

@schuchard
Copy link
Contributor Author

i like both of those options

@jrista jrista added this to the 0.7.0 Alpha 1 milestone Aug 3, 2020
@jrista jrista added approved Approved for Implementation and removed under review Currently under merit/design review labels Aug 8, 2020
@jrista
Copy link
Contributor

jrista commented Jan 25, 2022

After some contemplation, I think I am going to go with only the functional option, to keep things simple and consistent:

@Entity({
    modelName: 'Order',
    key: order => order.metadata.id
})
class Order {
    name: 'Food Order',
    metadata: {
        id: 12345
    }
}

@jrista
Copy link
Contributor

jrista commented May 4, 2022

This will be the final feature for NgRx Auto-Entity before its final v12 (to align with Angular v12 back to v9) release. This feature will touch a number of key locations in the code, so I'll release it as a beta initially, but once this feature is done final work can begin on converting the library over to use angular 13 and up (which switches to RxJs v7).

@jrista
Copy link
Contributor

jrista commented May 5, 2022

Looks like this change will have to be fairly extensive, and most likely breaking. For now, I'm going to shelve this issue. Will address at a later date, as being able to specify a custom key retrieval function would be very useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Approved for Implementation enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants