HOT module replacement for your Drupal behaviors.
Every behavior has to be in its own file. The naming scheme is [name].behavior.js. The loader will use the [name] and attach it to the global Drupal.behaviors object.
Your behavior file should export an object. Ideally it provides an attach
and also
a detach
function.
The loader will generate and inject code that makes 'hot module replacement' possible.
When a module replacement is going to happen, it will first call the detach
function,
where it's the job of the beahvior to remove any event listeners or 'clean up'.
Then webpack will replace the behavior with the new one. The injected code then calls
attach
again. No page refresh required and only the behavior actually changed will be
reattached.
It's really important to remove event listeners and destroy instantiated classes that might have altered the document in any way. Otherwise it might lead to some unexpected behavior.
{
test: /\.behavior.js$/,
exclude: /node_modules/,
options: {
enableHmr: true
},
loader: 'drupal-behaviors-loader'
}
behaviors/thing.behavior.js
import Thing from '@/components/thing'
export default {
_thing: null,
_button: null,
_handleClick (e) {
console.log('Hello!')
},
attach (context, settings) {
this._thing = new Thing()
this._button = document.getElementById('my-little-button')
if (this._button) {
this._button.addEventListener('click', this._handleClick)
}
},
detach () {
this._thing.destroy()
this._button.removeEventListener('click', this._handleClick)
}
}
main.js
// Import behavior
import '@/behaviors/thing.behavior'
// Import component style.
import '@/styles/components/thing.scss'
When using the webpack dev server the files are not written to the filesystem, but kept in memory only. They are accessible via the dev server, e.g. http://localhost:8080/main.js. This means for local development you need to "attach" this script instead of the built file.
Drupal allows to include external libraries. So let's make use of that:
mytheme.libraries.yml
main-build:
js:
dist/js/chunk-vendors.js: { minified: true, preprocess: false, scope: footer }
dist/js/main.js: { minified: true, preprocess: false, scope: footer }
main-dev:
js:
http://localhost:8080/main.js: { type: external, minified: true, preprocess: false }
So for every webpack entry you will need two libraries: One for the production build and one for local development. You have to manually attach the correct library depending on the environment:
mytheme.theme
$environment = getenv_default('ENV', 'local');
if ($environment === 'local') {
$variables['#attached']['library'][] = 'mytheme/main-dev';
} else {
$variables['#attached']['library'][] = 'mytheme/main-build';
}
Depending on your setup you will probably also need to set the headers option of the webpack dev server:
headers: {
'Access-Control-Allow-Origin': '*'
}
After that you should be able to enjoy HMR on your local Drupal site! Or do you...?! Because the hot module stuff from webpack checks for its update.json file using a relative path and you're accessing it from mydrupalsite.local, you will have to setup some kind of proxying...
Or you can just do it like I did and set the publicPath option of webpack to literally itself. Which will result in this lovely URL when starting the webpack orchestra:
App running at:
- Local: http://localhost:8080/http://localhost:8080
- Network: http://10.20.1.1:8080/http://localhost:8080
How fantastic!
I created a simple webpack setup for a Drupal theme, which also uses this loader. https://github.com/dulnan/drupal-webpack-setup-example