Beagle v1.7 is no longer actively maintained. The documented version you are viewing may contain deprecated functionality. For up-to-date documentation, see the latest version .
Beagle Web offers some cache strategies, one of them is the Beagle’s default cache protocol guided by the backed.
Other strategies you are able to use:
beagle-with-fallback-to-cache
beagle-cache-only
network-with-fallback-to-cache
cache-with-fallback-to-network
network-only
cache-first
On the web, the cache data are stored in the browser.
You have two strategy possibilities on Beagle: the ones that are compatible with the cache protocol and the others that are independent. You will see next how each works:
Standard strategy that implements:
Here, it is locally saved on the storage the tree and the related cache protocol metadata (beagle-hash
, max-age
and a time identifier that shows the time the request has been sent).
This strategy allows you to use a fallback to return a tree, even in some error cases. When this happens, the fallback returns a tree that has already been locally saved before (if it exists), even if it is not updated.
It is important to make it clear, this configuration will only work if the backend has the cache enabled.
Beagle Web only extracts the header information from the requests. If they are not available, the request will always be sent and even with the stored cache, it won’t be used, the exception is the for a fallback.
If you backend is with disabled cache, the payload from the tree will be saved on the storage and it will not be used.
This strategy only implements Beagle’s cache protocol. This means that, it works the same way the standard one, but without the fallback.
When you enable this strategy, the tree that is on cache it is only used if there is a valid max-age or if it receives a 304 status from the backend.
In case the request fails, the view will not be displayed and it can not exhibit the error component, according to the config definition.
This strategy starts the request on backend to bring as a result what it is saved on cache. This cache will only be used in case the request fails, working as fallback.
If the request fails and the data is on cache, you will be able to make the return correctly. In case this does not happens, the error component is (or not) displayed according the to the config definition.
This one starts the request on cache to return the tree that it is rendered in this cache. If nothing is found, the fallback will make a request to search the tree.
This way, the request is only triggered if the data is not found on cache.
This strategy makes exclusive backend requests. On this case, you will always send a request to search the trees to be rendered.
If the request fails, there isn’t a fallback to display (or not) the error component.
This one sends the view after searching on cache, even if it doesn’t find the request that it is looking for.
If the tree is found on cache, it is used to render the view. When the request returns, the view is updated with the request result. In case it returns an error, the displayed view is kept with the cache information.
To change the cache strategy, you have to use the strategy
parameter with the strategy name chosen inside Beagle’s config.
On the configs below, you will find an example on how to alter the strategy to network-only
:
@BeagleModule({
baseUrl: 'yourBackendUrlGoesHere',
module: {
path: './beagle-components.module',
name: 'BeagleComponentsModule',
},
components: {
// Associate every beagle component to your angular component.
},
strategy: 'network-only'
})
export class Beagle { }
export default createBeagleUIService({
baseUrl: "",
components: {},
strategy: 'network-only'
})
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.