Open LFDM opened 6 years ago
This feature would definitely make a lot of sense!
I'd try to keep the definition footprint a bit more "idiomatic" and smaller, e.g. like so:
{
user: {
api: userApi
},
userSettings: {
api: userSettingsApi,
linkedEntities: {
user: {
idFrom: (userSettings) => userSettings.userId
}
}
}
}
At least this way the associated entity user
"looks" a bit more like its own definition further above. I'd also favor a wording like "linkedEntities", "relatedEntities" or maybe even something like "invalidatesFrom"? But those are just details then!
Important details though, because changing the syntax after the fact is typically not so cool 😊 But good point about following the definition practice from elsewhere. That's also what some plugins do for example (denormalizer)
Just a small detail, rather than "following" the definition, we should be inspired by good examples ;)
Do you think it is enough to always invalidate the associated entity? Or do we need rules that control when to invalidate? I'm afraid that people end up invalidating their entities to often, and then we introduced complexity without really knowing/strongly believing that it will speed up things and reduce how much data is sent over the wire in the end.
Let's consider having an entity called
User
and an entity calledUserSettings
. Each user has exactly one user settings object. AUserSettings
object has a reference id to its user object in a field calleduserId
.The goal is to get more clever invalidations. Right now we can only say, that a change to a
User
should invalidate allUserSettings
objects we have in our cache. By defining an association between these two entities, we could automatically do more fine grained invalidations. Only when the user with idx
changes, the settings object with a reference id ofx
is invalidated.The configuration for this could live in the regular config object, passed to
build
:Alternatively several such associations could be defined:
Does this sound like a legitimate and valuable use case?