layout | title | description | hide_description |
---|---|---|---|
page |
Advanced |
This chapter covers advanced topics, such as offline support and custom JS builds. Codings skills are recommended.
|
true |
This chapter covers advanced topics, such as offline support and custom JS builds. Codings skills are recommended.
{:.no_toc} 0. this unordered seed list will be replaced by toc as unordered list {:toc}
Hydejack v8 introduces experimental "cache as you go" offline support. This is implemented via the Service Worker API, a new browser standard that is now supported in the latest versions of all major browsers. However, it is a very powerful feature and should be used with a lot of care.
Enabling this feature requires that your content meets the following criteria:
- Content doesn't change between between deploys (e.g. manually adding things to
_site
etc.) - All assets in
assets
are immutable, i.e. they never change (when changing a file in assets, it needs to have a new name and links need to point to the new file). - The site is mostly self-contained, i.e. assets are served from the same domain (offline support will not download assets form external sites by default)
- The site is served via HTTPS (this is a Service Worker requirement)
To enable this feature, create the sw.js
file in the root of your project and add the following content:
---
---
importScripts("{\{ '/assets/js/sw.js' | relative_url }\}?t={\{ site.time | date_to_xmlschema }\}");
NOTE: You have to remove the \
after each {
and before each }
! Alternatively, you can just copy the file from here.
{:.message}
This will load the main service worker script from Hydejack's assets. The site.time
part is necessary to make the service worker "byte different" every time you create a new build of your site, which triggers an update.
In your config.yml
under the hydejack
key, add the following:
offline:
enabled: true
cache_version: 1
The current implementation does not cache resources from external domains. There is now way of knowing if external sites conform to the conditions mentioned above, hence caching can be problematic and result in unexpected behavior.
For example, Google Analytics uses GET requests to send page views, each of which would be cached by the service worker without this policy. Frequently updating images, such as badges would never change.
However, if you include resources that are hosted on another domain and don't change, you can add the sw-cache
query parameter to the URL, e.g.
https://upload.wikimedia.org/wikipedia/commons/b/b1/57_Chevy_210.jpg?sw-cache
This will cause them to be cached like resources from the assets folder.
Hydejack's custom service worker implementation stores files for offline use on three different levels:
Shell
: The shell files are the core Hydejack files (CSS, JS) that only change between version updates.
If you made changes to any of these after enabling offline support, you must force an update by bumping the cache_version
number in the config file.
Assets
: These are presumed to be immutable. In other words, every file is cached indefinitely. E.g.: If you want to update an image after enabling offline support, add the image under a different name and change the link in the content. Alternatively, you can bump the cache_version
, but this will remove all other cached files from the asset cache.
Content : The content cache exploits the fact that your content can't change between builds, so that it can be stored for offline use until you upload a new build. For now, the entire content cache is discarded every time you publish new content (future versions could cache them based on last modified dates).
Other things to note are that the implementation will always cache the pages listed under legal
, as well as the 404.html
page, which will be shown when the user is offline.
Hydejack includes a number of social media icons by default (in fact, everything that is provided by IcoMoon), but since the landscape is always changing, it is likely that a platform that is important to you will be missing at some point.
NOTE: You can add any platform by simply providing a complete URL. However, a fallback icon will be used. {:.message}
In order to add a custom social media icon you have to use the IcoMoon App (free) to create a custom icon webfont. However, it is important that the generated font include all icons already in use by Hydejack. For this purpose, find the selection.json
in assets/icomoon/selection.json
and upload it to the app via "Import Icons".
Then, use the app to add your icon(s).
Consult the IcoMoon docs for additional help.
Once you've created and downloaded the icon font form IconMoon, replace the icomoon
folder in assets
in its entirety. Keep in mind that future updates of Hydejack will override this folder.
For the second step it is necessary to add the network's metadata to _data/social.yml
.
An entry looks like:
deviantart:
name: DeviantArt
icon: icon-deviantart
prepend: "https://"
append: ".deviantart.com"
name
: The name of the network. Used for for the title attribute and screen readers.
icon
: The icon CSS class. Can be chosen during the IcoMoon creation process.
prepend
: Optional. A string that is prepended to the username to form the link to the profile. If the final URL should be https://<username>.deviantart.com
, this would be https://
append
: Optional. A string that is appended to the username to form the link to the profile. If the final URL should be https://<username>.deviantart.com
, this would be .deviantart.com
.
Hydejack takes a quite unique approach to CSS, which is motivated by the ability to
inline essential CSS rules in a style
tag in the <head/>
of a page (to increase the loading speed),
while serving the rest in a separate file.
The styles are written in SCSS and are located in the _sass
folder, which looks like
├── hydejack
│ ├── __inline__
│ ├── __link__
│ ├── _base.pre.scss
│ ├── ...
│ └── _social.pre.scss
├── pooleparty
│ ├── __inline__
│ ├── __link__
│ ├── _base.pre.scss
│ ├── ...
│ └── _type.pre.scss
├── mixins.scss
├── my-inline.scss
├── my-style.scss
├── syntax.scss
└── variables.scss
The style rules are organized alongside components (or rather, topics) like "sidebar" and "footer". Further, there are two separate frameworks, "pooleparty" and "hydejack", which grew out of the original Poole and Hyde projects. Poole/party contains more general style rules, while Hyde/jack contains those that more are specific to the theme. However, this separation has blurred over time.
Inside those folders, you will notice the __inline__
and __link__
folders.
The unfriendly names are intentional, because their contents are generated by a script and shouldn't be modified directly.
The source files are located in the same folder and end with .pre.scss
.
They are fully valid SCSS files, but contain comments that mark which lines should be inlined and which should be fetched asynchronously.
The rules are as follows:
- Every line between
// <<< inline
and// >>>
will be inlined - Every line between
// <<< link
and// >>>
will be linked - Every line that isn't contained in a block and ends with
// inline
will be inlined - Every line that isn't contained in a block and ends with
// link
will be linked - Every line for which none of the above applies will be included in both.
The actual splitting happen with the _scripts/build-css.sh
script (requires node.js 8+).
You can run the script once by using
$ npm run build:css
or rebuild the CSS on every file change
$ npm run watch:css
Note that my-inline.scss
and my-style.scss
are not affected by this.
Also, since all files are valid SCSS, the splitting part is entirely optional.
If you would like to build just one regular CSS file, add
hydejack:
no_inline_css: true
to your config file.
In order to build the JavaScript you need to have node.js installed. Specifically, the npm
command needs to be available, which is part of node.js.
NOTE: Building the JavaScript is optional! Hydejack comes with a pre-built, minified hydejack.js
file
that you can find in part of the theme's assets
.
{:.message}
Before you start, make sure you've copied the following files:
_js/
package.json
package-lock.json
.babelrc
.eslintignore
.eslintrc
When building for the first time (and after each update of Hydejack) you have to run
$ npm install
to fetch all dependencies (and put them in a local folder node_modules
), lint the code and write the bundled and minified script into assets/js/hydejack.js
.
You can re-build it with
$ npm run build:js
If you want to actively develop the scripts, it is better to run
$ npm run watch:js
which will build a non-minified version of assets/js/hydejack.js
after each filechange.
*[FLIP]: First Last Invert Play