Strategies
Barba implement modern browser strategies to keep your site run as fast as possible.
Summary
Cache
cacheIgnore
Allows Barba to cache your pages.
Saving pages in the cache results in less bandwidth usage and less server-side load: no more XMLHttpRequest
are made for pages that have already been visited.
Value | Description |
---|---|
false (default) |
Cache all |
true |
Ignore all |
String | String[] |
Ignore route pattern(s) |
Use it like this:
1 | barba.init({ |
Cache lifetime is restricted to Barba instance and will be cleared when leaving the site.
cacheFirstPage
Allows Barba to cache the first rendered page.
In some situations it is useful to cache that page, but most time it is worse to cache the rendered HTML, because it may be modified by other scripts and those scripts have to deal with the cached page later.
Value | Description |
---|---|
false (default) |
Do not cache the first rendered page |
true |
Cache the first rendered page |
Use it like this:
1 | barba.init({ |
barba.cache
When cache is enabled, Barba internally use a cache instance to store cache data of all pages.
Cache data
Using the internal cache.get(url)
method, you can easily retrieve cache informations for a specified URL.
Useful in some situations when you need to know request status and progression during a page transition.
It returns a ICacheData
object:
Property | Type | Description |
---|---|---|
action |
String 'init' |
Page has been cached on init |
String 'enter' |
Page has been cached on mouseover regarding the prefetchIgnore strategy |
|
String 'click' |
Page has been cached with a user click | |
String 'prefetch' |
Page has been cached with a programmatic prefetch or the @barba/prefetch plugin |
|
request |
Object Promise |
Request associated to the page |
status |
String 'pending' |
Request has started and Promise is pending |
String 'fulfilled' |
Request has been fulfilled | |
String 'rejected' |
Request has been rejected (an error occured) | |
target |
String | Target URL stored in the cache |
See
Cache
module API documentation to learn more.
Cache target
The cache target
contains the targetted URL of the page.
In case of 301
redirection, Barba cares of keeping in the cache the server reseponseURL
instead of the requested one. In addition, the browser URL will be properly updated.
Note that if you start prefetching a URL that have a 301 redirection, cache
target
will be set based on the requested URL since cachestatus
is in “pending” mode. After cachestatus
switch to “fulfilled”, the cachetarget
will contain the final response URL.
Prefetch
prefetchIgnore
Allows Barba to prefetch your pages on mouseover
or touchstart
events.
Since there is a 100-300ms delay during the user hover and the click, Barba use this time to start prefetching the next page. Most of time, this is enough to get the next page ready.
Value | Description |
---|---|
false (default) |
Prefetch all |
true |
Ignore all |
String | String[] |
Ignore route pattern(s) |
Use it like this:
1 | barba.init({ |
To prefetch all eligible links that enter the viewport, use the @barba/prefetch plugin.
Prefetch URL
You can programmatically prefetch some URLs using the barba.prefetch
code method:
1 | barba.prefetch('about.html'); |
Note that all prefetched URLs are stored absolute in the barba.cache: if you prefetch
about.html
, it will be stored in the cache ashttps://localhost/about.html
instead. This prevent caching twice the same page if you omit to prefix your URLs in the output.
Prevent
preventRunning
Tells Barba to prevent page “force reload” when the user clicks on an eligible link during a transition is running.
This option is useful if you don’t want your users to break running transitions, especially if they are long.
1 | barba.init({ |
You can also programmatically check if a transition is running using
barba.transitions.isRunning
whenever you want in your code.
prevent
Allows you to add a custom “prevent” test on eligible links.
If this function returns true
, Barba will be disable for links that pass the test.
Argument | Description |
---|---|
el |
Clicked element |
event |
Triggered event |
href |
Next page href |
1 | barba.init({ |
Note that you can prevent a link from using Barba with the
data-barba-prevent
attribute:
data-barba-prevent
ordata-barba-prevent="self"
prevents the current linkdata-barba-prevent="all"
prevents all children links in a container (div
,p
, etc.)
History
barba.history
While browsing the website, Barba stores useful navigation informations into the history
property. You can access those informations at any time in your application.
history.previous|current
The most useful are the previous
and current
history attributes. It allows you to access the page namespace
, the window scroll
position and the page url
. For example, if you want to restore scroll position between pages, have a look at the scroll position recipe.
They both shares the same set of properties.
Property | Type | Description |
---|---|---|
ns |
String | Namespace of the page |
scroll |
Object | x / y positions of the scroll |
url |
String | URL of the history position |
data |
Object | Custom data for the current page |
Be careful,
barba.history.previous
object equalsnull
when your application is starting.
history.add
This method bring the ability to programmatically push or replace history entries to easily keep the history up to date in your application based on user interaction.
Argument | Type | Description |
---|---|---|
url |
String | URL of the page you want to push/replace in the history |
trigger |
Object Trigger |
The element that triggers the history action |
String 'barba' |
Programmatic trigger | |
action |
String 'push' (default) |
Push a new entry in the history |
String 'replace' |
Replace the current entry in the history |
1 | // push a new entry in the history |
See
History
utility API documentation to learn more.
history.store
In some situation, you may need to store custom information based on user navigation and access them later in your code. Barba now offer a way of doing this with ease using the barba.history.store
method.
1 | barba.history.store({ |
Be careful, data will be overwritten if you call twice the
store
method with the same data attribute.
Then later in the code, after a page transition, you can access your custom data from the previous page:
1 | const id = barba.history.previous.data.id; |
As it’s using replaceState
API under the hood, data are automatically rolled within the history, meaning if you call the store
method before a page transition, the custom data will be stored inside history.current
, then after a page transition, data will be available inside history.previous
while history.current
stay empty until you put something inside it.
data-barba-history
Sometimes, you may want to “alter” the browser history by replacing the current entry without having to push a new one. This can easily be done with the data-barba-history="replace"
attribute.
In the example below, if you come from the index
page and click on black
link, the barba.history.previous
will equal index
while barba.history.current
will equal black
. Clicking on white
will replace the current black
entry with the white
one, while the previous entry remains intact and equal to index
.
1 | <a href="/theme?color=black" data-barba-history="replace">black</a> |
The default Barba behavior for history is
push
, so you don’t have to manually writedata-barba-history="push"
on all your links.