Hello there! It's been a while since I posted anything, but today I'd like to take a moment to tell you about a simple yet quite efficient pattern we've been using at my current job regarding Vue.js applications.
As with any front-end framework, Vue.js isn't really opinionated regarding how you're supposed to inject configuration into your SPA, assuming this configuration comes from your back-end service. A common pattern in this era of API-centric services is to dedicate a JSON endpoint to configuration that your JavaScript code will fetch immediately upon boot. This allows us to keep all back-end considerations aside, but has several disadvantages as well:
limited flexibility if the network or your back-end itself fail (the more you can provide for an offline and/or degraded experience, the better)
somewhat extraneous network round-trip for something you could have provided locally to begin with
your JS code still needs to know which URL to request, which is already configuration; how do you provide that?
For all these reasons, we have began to experiment with a little something we like to call the widget pattern. Nothing crazy here: we essentially wrap the new Vue declaration inside a build function, which is then called from public/index.html:
We then use its second argument in src/main.js to inject config into our app, which we can variabilize depending on the environment if we need to, by swapping wildcards with environment variables from Docker for example:
import Vue from "vue";
import App from "./components/App";
export default App; // more on that later
export function build(el, config) {
new Vue({
el,
render: h => h(App, props: { /* ... */}),
});
}
All we need to do to make this work is to expose our root module in vue.config.js:
This gives us the flexibility we need, and forces us to reflect on our app's root component's input, as its props are used to receive the aforementioned configuration values. We thus also made an habit of exporting this root component as default, which means we can use our app on its own as before or use it as a "widget" (hence the "pattern" name) in a larger Vue.js codebase or a legacy application.
If you're using something similar or have something to say about this way of doing things, use the comment section below!
The latest major version of Node.js's package manager introduces a breaking change regarding the peerDependencies section of the package.json file. With NPM 2, these dependencies were installed in the root node_modules folder; this is NPM 3's default behaviour, and peerDependencies are no longer fetched by npm install. Instead, the tool will simply warn you if these dependencies are unmet. But what if you relied on this feature and have to support both versions?
Looking for an answer to this question, I stumbled upon this article that proposes a simple solution: duplicate peerDependencies as dependencies, which will result in installing the right stuff at the right place no matter the NPM version in use. This works, but has a few drawbacks, the most important in my eyes being the obvious code configuration duplication, which often rhymes with maintenance pain.
I therefore put up a Bash workaround, that will play nicely with Jenkins jobs and other install scripts:
# Install dependencies once, just to fetch packages with peerDependencies
npm install
# Check for current NPM version
NPM_MAJOR_VERSION=`npm -v | cut -d \. -f 1`
if [ "$NPM_MAJOR_VERSION" == "3" ]
then
# Turn peerDependencies into dependencies for relevant packages
sed -i 's/peerDependencies/dependencies/g' ./node_modules/package-with-peer-deps/package.json
# Install again, for real this time
npm install
fi
# Do stuff...
Kinda dirty, but it works with no need to think about it. Feel free to discuss this solution and propose something better in the comments!
Note: using npm shrinkwrap also seems to work around this once dependencies have been correctly installed at least once, which could cancel the need to perform the above trick on a regular basis.
If you are using react-router, the odds are that you have already tried react-breadcrumbs to handle breadcrumbs based on your routing configuration, which can come in handy.
But what if your application is not a SPA and part of your routing (and your breadcrumb) happens server-side? This is what we will achieve today with some dirty DOM magic.
First, let's consider our HTML page:
<!DOCTYPE html>
<html>
<head>
<!-- ... -->
</head>
<body>
<div class="breadcrumb"><!-- server-side breadcrumb --></div>
<div id="react"><!-- React app will be rendered here --></div>
<!-- scripts, etc. -->
</body>
And here is our root component:
'use strict';
let React = require('react'),
Breadcrumb = require('react-breadcrumbs');
The BreadcrumbJSX tag will be rendered as our client-side breadcrumb; what we rather want is to have both breadcrumbs concatenated in our div.breadcrumb.
Let's make some additions to the root component:
'use strict';
let React = require('react'),
Breadcrumb = require('react-breadcrumbs');
module.exports = React.createClass({
/**
* Maintains breadcrumb up-to-date with dynamic, react-router-powered part
*
* The actual breadcrumb is outside React's scope, so we basically render
* a hidden breadcrumb with the aforementioned part and copy its contents
* at the end of it after wiping it clean, all through DOM manipulation.
*/
updateBreadcrumb: function() {
let breadcrumb = document.querySelector('.breadcrumb');
// We use React's own specific HTML attributes to clear the breadcrumb from previous additions
Array.prototype.slice.call(document.querySelectorAll('.breadcrumb > [data-reactid]')).forEach(function(toRemove) {
breadcrumb.removeChild(toRemove);
}, 0);
/**
* @return {Object}
*/
render: function() {
return (
<div className="container">
{/* Hide client-side breadcrumb and prevent it from explicitly displaying missing segments, if any */}
<Breadcrumb routes={this.props.routes} customClass="breadcrumbHolder hide" displayMissing={false} />
{this.props.children}
</div>
);
}
});
And it works! This is a total hack, but React's very own philosophy prevents us from more interaction with a preexistant DOM, at least for now. Stay tuned!
Today's post isn't quite of the strictly-technical kind I usually write, but rather a response to some late trend about JavaScript that has gone on for far too long.
This year's beginning has been scattered with ranting articles bearing overdramatic titles, such as this one and that one, coming from developers who have come to hate the modern JS ecosystem. As a strong believer in the opposite point of view, I will hereby review their concerns one by one.
"Node.js is immature": yeah, right, that must be why PayPal has been using it in production for two years now. Oh, and by the way, the whole fork story has come to an end, the most obvious proof of that being the fact node's versioning has jumped from v0.x to v4.x, to account for io.js's own three stable major versions. However, apart from build systems (such as Grunt) running on the developer's machine, what does it ever have to do with front-end code? Those build systems could be running Ruby for that matter, it doesn't change a thing.
"Maintaining a project / a development environment is hard": maybe you bet on the wrong horse. I chose to use gulp a while ago (as in "several years", actually not long after it came out in the first place) as it seemed to be the tool that best suited my needs. It hasn't changed since, nor have I switched it for anything else. I read up on webpack and other solutions, but didn't change just because they were newer: gulp kept being ideal for me while remaining relevant in the market (as in "used at all"). This leads me to the next item...
"There is no predominant solution": oh no, now we have to think about what we're doing! The JS ecosystem indeed is in its teenage phase, as tools are blooming everywhere all the time. But in the end, only a few will survive: the ones that are solidly maintained, that managed to gather a community around them and, the most important thing, do what they claim to do, and do it right. It's just like any other programming ecosystem around here, the only difference being there are more different choices. Intelligence is all it takes to choose the right tool for the right job, if that job needs any tool in the first place, and wiseness is all it takes to check which tools will last in the long run, and which of these are of interest to you: these are the ones you want to go on with. You know what? I brag about React a lot, but I haven't even tried any Flux implementation around (like Redux) yet, and thank you, I feel quite fine.
"Everyone uses JS for everything, even when it's wrong": yes, some people do that. It doesn't mean everyone does that. Not everyone fires up React for any static page. Stop thinking what you read and remember is everything that exists. Who's going to write an article just to say they built an app without a JS framework and a build system, just to keep people like you happy and confident in their own denial?
JavaScript is a messy language, but it's getting better: ES6 is great and ES7 will be, too. React is great. Node is great. You are not supposed to love them three (or anything else). If you do, you will probably build great stuff with them. If you don't, it's no big deal, but don't ruin the party for everyone. Stop thinking you know better and bring up one actually constructive argument to begin with. Target specifics, instead of just concluding everything is turning to shit, because you just sound alike.
What I'm going to demonstrate today is more of an interesting concept than a technical achievement. Have you ever wanted to respond to store data changes in your Flux application, but in a way that is totally unrelated to, say, React?
Well, you probably already have some components doing it, so it shouldn't be hard. Let's try it out by saying we would like to do something upon authentication when the app boots:
// src/listeners/loginListener.js
'use strict';
let userStore = require('../stores/userStore');
module.exports = userStore.addChangeListener.bind(
userStore,
function() {
let user = userStore.getUser();
console.log(user);
}
);
Binding is pretty easy, too; just do something like the following in your entry point:
Repeating this pattern brings you a basic form of standalone store event listeners that you can use throughout your app, avoiding polluting view components with stuff that doesn't really belong in them.