Features

Hash drivers

Deep-link syncing rides the Navigation API where the browser has it, same URLs, cleaner history.

The hash plugin keeps the URL in sync with the open gallery (#lg=galleryId&slide=n), so slides can be deep-linked and the back button closes the gallery. In v3, the URL engine behind that syncing is pluggable:

lightGallery(el, {
    plugins: [lgHash],
    galleryId: 'nature',
    hashDriver: 'auto', // the default
});

The hash demo shows deep links in action, and the settings reference carries the generated description.

ValueEngine
'auto' (default)The Navigation API where the browser supports it, the History API everywhere else
'history'Force the classic engine: history.replaceState + hashchange
'navigation'Force the Navigation API; quietly falls back to 'history' where unsupported

Guarantees, whichever engine runs:

  • The URL format is identical, deep links produced by one engine open correctly under the other. Nothing about your links changes.
  • All updates use replace semantics, so stepping through slides never floods the browser history.
  • Traversing history entries (back/forward) moves the gallery to the matching slide, and removing the lg= marker closes it.
  • The enhancement is never load-bearing: an explicit 'navigation' preference on a browser without the API simply runs the history engine.

The behavior is identical in all four packages; the frameworks take the settings in the Hash plugin’s options object:

<LightGallery slides={slides} plugins={[Hash]} hash={{ galleryId: 'nature' }} />
<LightGallery :slides="slides" :plugins="[Hash]" :hash="{ galleryId: 'nature' }" />
<lg-gallery [slides]="slides" [features]="[withHash({ galleryId: 'nature' })]" />

Settings

SettingDefaultDescription
hashtrueEnable URL syncing
hashDriver'auto'URL engine: 'auto', 'history' or 'navigation'
galleryId'1'Unique id per gallery, mandatory with multiple galleries on one page
customSlideNamefalseUse the item’s slideName in the URL instead of the index

Edit this page on GitHub