Feature: Add new load paths to load only if data has not previously been loaded

[jrista]

When loading entities with any of the existing load actions, the loads will always occur and will always call the API. There may be times, such as when loading lookup tables, when the load should only occur if data has not been loaded previously.

This proposal recommends introducing a new set of actions for loads, alongside the existing actions, that would only actually be dispatched if no data has been previously loaded for the specified entity.

A new set of actions is proposed to maintain backwards compatibility and function, method and constructor signature standard with existing actions. Modifying existing load actions would be possible by adding a new parameter to allow the developer to flag whether they want to load only if data has not been previously loaded. That would introduce a breaking signature change to all of the load actions and related facade methods. A new set of actions ensures the new functionality can be introduced without breaking any existing use cases.

The proposed actions:

LoadIfMissing
LoadAllIfMissing
LoadManyIfMissing

Only initiating actions should be necessary, as these new actions would be filtered in the corresponding effects if the loadedAt timestamp for the given entity is not nullish, thus preventing the load from actually occurring. Further, these new actions should in turn dispatch their corresponding sibling actions, rather than calling the entity service directly. This will ensure that the existing load flows will be utilized if the loadedAt timestamps are indeed nullish.

[jrista]

After diving into an initial implementation of this, I think expansion of the feature is appropriate. Instead of just loading data if it is missing, which doesn't quite work as simplistically as it sounds for anything other than LoadAll, I think a it should be re-termed *IfNecessary, with necessity being based on more than simply if a loadedAt timestamp or data exists in state for the given entity.

Each of the loads would need to be tuned uniquely for the kind of data being loaded. Data would only be loaded if necessary when each of the necessary criteria for a given type of load had been verified:

LoadAllIfNecessary:

• loadedAt timestamp in state is null or past configurable threshold
• potentially: specified criteria does not exist in state (new tracking data required)

LoadIfNecessary:

• entity with given key does not exist in state;
• potentially: loadedAt for that entity null or past configurable threshold (new tracking data required)

LoadManyIfNecessary:

• loadedAt timestamp in state is null or past configurable threshold
• entities loaded with specified criteria do not exist in state (new tracking data required)

LoadPageIfNecessary:

• loadedAt timestamp in state is null or past configurable threshold
• current page info in state is either non-existent, or does not match current page info

LoadRangeIfNecessary:

• loadedAt timestamp in state is null or past configurable threshold
• current range info in state is either non-existent, or does not intersect range being loaded

[jrista]

To support dynamic loading based on the loadedAt timestamp, each of the IfNecessary actions would also allow a maxAge to be passed, which would check if the loadedAt timestamp plus the specified maxAge is in the past. If so, then the load would be issued, otherwise it would be stopped.

Additionally, for each entity, a defaultMaxAge could be specified on the @Entity decorator to configure a default age for each entity.