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 frontend 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.
The react-translate-component library provides a component, which is fed a translation key and yields a span with the translated string in return. When switching locales through a menu in your app as demonstrated in the docs, labels are updated accordingly. The problem is that you cannot use a component inside of a HTML attribute, for example; directly using Counterpart, the framework-agnostic library underneath the former, works on page load but the automatic update effect is lost, as its translate method is not called again.
The solution is quite simple: force this method to be called again by triggering a state change throughout the app. All we have to do is listen to Counterpart's events in our root component, pretty much like we would with a Flux store:
var React = require('react'),
Counterpart = require('counterpart');
Strings directly processed by Counterpart will now be reevaluated when the locale changes without any extra code.
I am still unsure whether this could become a performance pitfall on a large scale, please feel free to comment about that, or anything else for that matter!