Beagle v1.6 não é mais mantida ativamente. A versão documentada que você está visualizando pode conter funcionalidades depreciadas. Para obter as funcionalidades mais recentes, consulte a nossa última versão .
O Beagle Web oferece algumas estratégias de cache, entre elas o protocolo de cache padrão do Beagle guiado pelo backend.
Outras estratégias que você pode usar são:
beagle-with-fallback-to-cache
beagle-cache-only
network-with-fallback-to-cache
cache-with-fallback-to-network
network-only
cache-first
No framework para Web, os dados de cache são armazenados no local storage do navegador.
No Beagle, você tem duas possibilidades de estratégia: as que são compatíveis com o protocolo de cache e as que são independentes. A seguir, você verá como funciona cada uma delas:
Estratégia padrão que implementa:
Nela, é salvo de forma local no storage tanto a árvore quanto os metadados relacionados ao protocolo de cache (beagle-hash
, max-age
e um identificador da hora em que a chamada foi enviada).
Essa estratégia permite que você use o fallback para retornar uma árvore, mesmo em casos de erro. Quando isso acontece, o fallback retorna a árvore que já tenha sido salva localmente antes (se existir), mesmo que ela esteja desatualizada.
Importante deixar claro que essa configuração só funcionará se o backend estiver com cache habilitado.
Isso porque o Beagle Web só extrai as informações do header das requisições. Se elas não estiverem disponíveis, as requisições serão sempre enviadas e, mesmo com o cache armazenado, ele não será utilizado, a não ser para o fallback.
Se o seu backend estiver com cache desabilitado, os payloads da árvore serão salvos no storage e não serão utilizados.
Estratégia que implementa apenas no caso do protocolo de cache do Beagle. Isso significa que ela funciona igual à estratégia padrão, mas sem o fallback.
Quando você habilita essa estratégia, a árvore que está no cache só é utilizada se tiver um max-age válido ou se receber o status de 304 do backend.
Caso a requisição falhe, a view não vai ser exibida e pode não exibir o componente de erro, de acordo com a definição da config.
Estratégia que inicia a chamada no backend para trazer como resultado o que estiver salvo no cache. Esse cache só será usado em casos de falha na requisição, funcionando como fallback.
Se a requisição falhar e o dado estiver no cache, você conseguirá fazer o retorno corretamente. Caso isso não aconteça, o componente de erro é (ou não) exibido de acordo com a definição da config.
Estratégia que inicia a chamada no cache para retornar a árvore que estiver renderizada nesse cache. Se não for encontrado nada, o fallback é realizar a chamada para buscar a árvore.
Desta forma, a chamada só é disparada se o dado não for encontrado no cache.
Estratégia que busca fazer chamadas exclusivamente do backend. Nesse caso, você sempre enviará a requisição para buscar as árvores a serem renderizadas.
Se a requisição falhar, não existe fallback para exibir (ou não) o componente de erro.
Estratégia que envia a view depois de fazer a busca no cache, mesmo que não encontre a requisição que estiver procurando.
Se a árvore é encontrada no cache, ela é utilizada para renderizar a view. Quando a requisição retorna, a view é atualizada com o resultado da requisição. No caso de retornar algum erro, é mantida a view exibida com a informação do cache.
Para mudar a estratégia de cache, você deve utilizar o parâmetro strategy
com o nome da estratégia escolhida dentro no config do Beagle.
Nas configs abaixo, você encontra um exemplo de como alterar a estratégia paranetwork-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.