which will invalidate based on what is specified in an entity config. For eg. calling _notifyRead in { invalidates: ['user'], invalidatesOn: ['READ'], api: apiFns } would invalidate "user".
Usage: api.user._notifyCreate() // as if a normal create operation was called, but cache is untouched.
This allows the users to model their invalidation logic in Ladda and use it before they use Ladda for all API calls. A possible next step would be to allow the users to override the notify functions with their own implementations, that can also be configured on an API function level (eg. invalidate another api function). This might not be necessary though, since most of the time NO_OPERATION can be used for this.
Coverage decreased (-0.6%) to 98.638% when pulling 476fa94d87df56cef92b4da450007b9c39419072 on feat/notify-from-outside into 1f579db4b4abcf826ab5d7b6f994fbc1b5354a32 on master.
Coverage decreased (-0.3%) to 98.938% when pulling 3c8b0c587e14ddab0d8e2d804ad10538529c708b on feat/notify-from-outside into 1f579db4b4abcf826ab5d7b6f994fbc1b5354a32 on master.
Coverage decreased (-0.3%) to 98.938% when pulling cda69c94aabc9e86d94f3dadb91e040b4a646cca on feat/notify-from-outside into 1f579db4b4abcf826ab5d7b6f994fbc1b5354a32 on master.
Coverage decreased (-0.3%) to 98.938% when pulling cda69c94aabc9e86d94f3dadb91e040b4a646cca on feat/notify-from-outside into 1f579db4b4abcf826ab5d7b6f994fbc1b5354a32 on master.
Coverage increased (+0.2%) to 99.388% when pulling 2b56bd118c1b4aaee06a6ef58548b6253bbf2ac7 on feat/notify-from-outside into 1f579db4b4abcf826ab5d7b6f994fbc1b5354a32 on master.
Adds notifier functions, functions that do not modify the cache, but can be used to trigger invalidation.
_notifyCreate _notifyRead _notifyUpdate _notifyDelete
which will invalidate based on what is specified in an entity config. For eg. calling _notifyRead in { invalidates: ['user'], invalidatesOn: ['READ'], api: apiFns } would invalidate "user".
Usage: api.user._notifyCreate() // as if a normal create operation was called, but cache is untouched.
This allows the users to model their invalidation logic in Ladda and use it before they use Ladda for all API calls. A possible next step would be to allow the users to override the notify functions with their own implementations, that can also be configured on an API function level (eg. invalidate another api function). This might not be necessary though, since most of the time NO_OPERATION can be used for this.