Boyleing Point

7/11 was an inside job

The latest version of local-storage-manager has had the internal interface greatly improved for tidiness and best practice, and now has the new Namespace feature. Traditionally, you would have to store your data like so:

const appState = {
key1: {...},
key2: {...}

and set the data like this:

localStorageManager.set('appData', appState);

The issue with this is you may not want key1 and key2 to be grouped together but don't want them to be tossed straight into the local storage. With namespaces you can do this:

localStorageManager.set('key1', key1, 'myAppState');
localStorageManager.set('key2', key2, 'myAppState');

This makes it easier to access all of your data at once while still keeping those keys theoretically separate. When accessing the namespaced data, you simply add the namespace as the second arg like so:

localStorageManager.get('key1', 'myAppState');

The app is now more robust internally and can handle cases of missing data better. It also uses the getItem and setItem methods internally instead of accessing the localStorage directly. To get started, install via npm with npm install @lukeboyle/local-storage-manager See the npm page with documentation and in depth instructions at -

A quick-start guide for running Karma tests for Chrome in Travis CI. When you run Travis on a Node.js project, Travis will - by default - run npm install and then npm test. I first ran into the issue in an Angular project that had tests triggered in the prepublish command. My CI build failed and I decided to remove the prepublish hook and change the name of my test script until I had the time to come back. For months I've been avoiding the issue, but I have finally solved it. The Karma docs suggest that you can run the tests in Firefox with the --browsers flag (see Travis has since updated so that Chrome can be loaded into the environment. For this to work, you'll need to make changes to your travis.yml file and your karma config file.


Note that I'm using only latest node as that is the requirement for me

language: node_js
- "node"
- export CHROME_BIN=chromium-browser
- export DISPLAY=:99.0
- sh -e /etc/init.d/xvfb start

The before_script is the special part, which points travis in the right direction for running Chrome. The last two lines are addressed in the karma docs linked above. Personally, I am using a separate karma config file, and I want to make the changes within that config file to keep my test script clean. My test script is:

"test": "karma start karma.config.js"


const configuration = {
files: [
{pattern: 'tests/**/**/**.*', watched: true}
customLaunchers: {
chromeTravisCi: {
base: 'Chrome',
flags: ['--no-sandbox']
frameworks: ['mocha'],
browsers: ['Chrome'],
failOnEmptyTestSuite: true,
singleRun: true
if (process.env.TRAVIS) {
configuration.browsers = ['chromeTravisCi']
module.exports = function (config) {

Luckily, Travis sets the process env to TRAVIS and if we check for this, we set the configuration browsers to ['chromeTravisCi'] which is defined in the customLaunchers. Have whatever pre-processors you need in the configuration object and it should work fine when you deploy.

I've recently been experimenting with using jsx in Vue, the Vue jsx plugin for babel and using that instead of the standard template pattern. Since there are really not any official docs for the plugin, I'm going to run through a quick usage guide.

Getting Started

For my project I'm using Webpack and just default npm scripts. Whatever your choice for build process the important part is what you have configured your babel config or .babelrc with.

plugins: [
presets: ['es2015']

That's the basic requirement for getting started. To install those, run:

  • npm install -D babel-plugin-transform-runtime
  • npm install -D babel-plugin-transform-vue-jsx babel-helper-vue-jsx-merge-props babel-plugin-syntax-jsx
  • npm install -D babel-preset-es2015

The official repo for the Vue jsx is located here: The interesting part about VueJsx in my opinion is that it follows the Angular pattern for registering components. Whereas in React you just import a function that returns jsx and you can name it whatever, in Vue jsx you must declare the name and register the component globally. Vue has a component method that takes a name and an object with all relevant data. The difference being is that instead of a template entry, there's a render function which returns jsx.

Vue.component('jsx-example', {
render (h) { // <-- h must be in scope
return <div id="foo">bar</div>
// Usage

h is the shorthand for the Vue instance $createElement method so you have to make sure that h is in the scope of your components, like so:

const pageView = new Vue({
el: '#root',
data: {},
methods: {},
render () {
const h = this.$createElement;
return (

From the get go it seems to me like we've lost some of the versatility that jsx provides by having to integrate it into the normal Vue component pattern.

return (
// event listeners are prefixed with on- or nativeOn-


There's a strange thing where on-change on a form input seems to be naturally debounced, and the nativeOn-change doesn't seem to be any different. The behaviour doesn't seem to be the same as the React class where you can refer to an element with this.refs, you need to use this.$refs which follows the usual Vue convention. Since there's no documentation surrounding the jsx, I'm assuming the rest of the behaviour follows the standard Vue component pattern, but instead of a template, there's a render function. The jsx doesn't support the normal vue directives so you'll have to do any of those things programmatically.

After much frustration with this issue, I found this section in the react material-ui documentation - React-Tap-Event-Plugin. The custom components like the select field don't work well with the traditional onClick listener, so as a temporary fix, the react-tap-event-plugin must be included in your react project. The dependency is supposedly a temporary fix. See the repo here: