The JavaScript blog.






libraries dom react browser

Relae, ClassNameBuilder

Posted on .


Relä (GitHub: joakimbeng/relae, License: MIT, npm: relae) by Joakim Carlstein is a library for fetching data from RESTful servers using React components. It can fetch data from a base URL, but can also filter data.

If you've already injected JSON into the initial page load, then you can bootstrap it with Relae.bootstrap(data).

To use Relä, you need to wrap a React component with Relae.createContainer. This is where you pass the REST API URL and filtering options:

Relae.createContainer(YourComponent, relaeOptions);  

This project is based on React Relay -- you can compare the API from the Relay Newsfeed blog post. The author has planned more features, but has already implemented some cool stuff like caching.


If you find yourself generating lists of class names (often done in React projects), then have you ever wondered if there's a better way to do it? Luke William Westby has a suggestion: ClassNameBuilder (GitHub: lukewestby/class-name-builder, License: MIT, npm: class-name-builder). This library offers a chainable API for manipulating class name strings. It supports conditional expressions and merging instances together:

const classNames = ClassNameBuilder  
  .always('example awesome-example')
  .if(condition, 'condition')
  .if(otherCondition, 'other-condition')
  .else(['not-other-condition', 'array'])

I'd usually do something like this with fragmentary bits of strings and logic. The advantage of this API is encapsulating the treatment of class names to generate more consistent output.


database libraries modules


Posted on .


Mesh (GitHub: mojo-js/mesh.js, License: MIT, npm: mesh) by Craig Condon is a data synchronisation library that caters for server-side and client-side requirements. The author has pitched it as the "underscore of data", meaning it's a highly focused library that you can drop in to existing applications.

It covers both storage and transit. For example, in the browser you could use localStorage, and Socket.IO to broadcast data to other clients. The supported databases are in-memory, localStorage, and MongoDB. If you want to use Mesh with a database that isn't supported, then you can write a new database adapter based on a CRUD API.

The API is based on CRUD operations and Node-like streams. Let's say you want to store data to local storage:

var mesh = require('mesh');  
var storage = require('mesh-local-storage');  
var bus = storage();  

You can now insert data (persisted to local storage) like this:

  name: 'insert',
  collection: 'messages',
  data: { text: 'hello world' }

But what if you wanted to also send data over Socket.IO to a server? All you need is a suitable adapter, and to wire it up with one of Mesh's stream merging methods:

var realtime = require('mesh-socket.io');  
var mergedBus = mesh.parallel(  
  realtime({ channel: 'operations' }, bus)

  name: 'insert',
  collection: 'messages',
  data: { text: 'hello everyone' }

The main motivation behind this library is to make data sources interoperable with one another, so I'd like to see what this looks like with a React application in the client, and a MongoDB-based REST API on the server.


node npm

npm 3

Posted on .

npm's job is to keep you out of dependency hell, not put you in it.

The beta of npm 3 has been released, and I'm running it right now:

$ npm --version

If you want to try it, use npm install -g npm@3.0-latest but be careful: not only is it a beta, but you can also break your npm installation if the global install fails. How do I know? My permissions were messed up on /usr/local/bin/npm, so when I tried to upgrade I saw "Error: EACCES, unlink ... node_modules/npm/.eslintrc". From that point npm was no longer in my $PATH... I actually reinstalled my current version of Node to fix it quickly, but I can imagine people getting very confused and frustrated about seeing command not found: npm.

If you're wondering what npm 3 will do for you, then a big thing is actually the UI: installation has a different appearance (it's more like npm ls), and npm outdated has changed. The "location" column shows which module required a dependency rather than where it is on disk.

Big projects should feel a little saner thanks to less nesting:

Your dependencies will now be installed maximally flat. Insofar as is possible, all of your dependencies, and their dependencies, and THEIR dependencies will be installed in your project's node_modules folder with no nesting.

If you make use of peerDependencies for modules that you distribute, you should be aware that they don't install dependencies anymore. Instead the user is warned about an unmet dependency.

This shifts the responsibility for fulfilling peer dependencies from library framework / plugin maintainers to application authors, and is intended to get users out of the dependency hell caused by conflicting peerDependency constraints. npm's job is to keep you out of dependency hell, not put you in it.

npm 3 is considered a rewrite by the authors. The level of redevelopment means we'll hopefully see some rich new features in the near future for front-end developers. If you're like me and you use Node for lightweight server-side apps, with rich client-side logic, then this will appeal to you.

The changelog for version 3 is actually very good and you really should read the full thing if you manage Node projects or distribute modules with npm.


java runtimes vert.x nashorn reactive oracle

Vert.x 3.0

Posted on .

Paulo Lopes wrote in with the news that Vert.x 3.0 is out (License: Eclipse/Apache 2.0). Vert.x is a JVM-based toolkit for building applications that supports multiple languages, including JavaScript. It's event driven and non-blocking, so it originally received interest from Node programmers, but it currently seems more popular in the Java community.

Here's an example of a Vert.x web server:

  .requestHandler(function (req) {
      .putHeader('content-type', 'text/plain')
      .end('Hello from Vert.x!');

Version 3 has a new API designed specifically for building web applications. It's called Vert.x-Web, and it supports routing, body and cookie parsing, authentication, static files, and it has an event bus bridge.

The routing API looks like many other server-side JavaScript web frameworks:

var route = router.route('POST', '/catalogue/products/:productype/:productid/');

route.handler(function(routingContext) {  
  var productType = routingContext.request().getParam('producttype');
  var productID = routingContext.request().getParam('productid');

  // Do something with them...

Vert.x 3 has support for MongoDB, Redis, and JDBC. It also supports reactive streams, and it has RxJava style APIs if you want to avoid using too many nested callbacks. The reactive API supports things like converting readable streams to observables (Rx.Observable.fromReadStream), and asynchronous future objects (Rx.observableFuture). Vert.x pushes reactive programming pretty hard, so if reactive programming is your thing then you might want to try it out.

Vert.x's JavaScript engine is Oracle's Nashorn. As far as I know, most of the ES6 features that you'd actually want (like classes) are not yet supported. Nashorn gets updated when the JDK gets updated, so it might be a while before several key ES6 features are ready. I couldn't get Babel working with it, but it seems likely that it could be adapted to work. Someone in the Vert.x community may have already ported an ES6 transpiler.

If you want to read more about Vert.x 3 and Nashorn, I found a recent interview with Tim Fox, the creator of Vert.x, and there's an official Nashorn blog.


modules events conferences iojs libraries node npm

Node Roundup: 0.12.5, 0.10.39, io.js 2.3.1, NodeDay, Apey Eye

Posted on .

Node 0.12.5, 0.10.39, io.js 2.3.1

Two new releases of Node just came out. Both releases fix OpenSSL security issues, but 0.12.5 also includes updates for uv and npm.

io.js 2.3.1 was also released this week. One of the big changes in this release is performance improvements for require:

module: The number of syscalls made during a require() have been significantly reduced again (see #1801 from v2.2.0 for previous work), which should lead to a performance improvement (Pierre Inglebert) #1920.

This sounds very nice for large projects.



NodeDay is a conference being held in London on 26th June (this Friday), for free! Speakers include Lin Clark, who writes npm's excellent blog posts, and programmers from the BBC, Red Hat, and other companies that are using Node for interesting things.

nodeday is a Node.js conference by the enterprise, for the enterprise. Now in its second year, this one-day industry conference brings together people from companies that have adopted or are planning to adopt Node.js, and focuses on the issues that these companies face. It gives participants a forum to discuss and share their experiences with Node.js, share advice, tips and tricks, and drive forward both the technology and the community.

I apologise for not writing about this sooner, but I only just found out about it! If you have conferences you want me to cover on DailyJS, you can use the contact forms or message me on Twitter (@alex_young).

I really wanted to go to NodeDay but I can't make it this time.

Apey Eye

Filipe Sousa sent in Apey Eye (GitHub: https://github.com/glazedSolutions/apey-eye, License: MIT, npm: apey-eye):

Apey Eye is an Object-Resource Mapping Node.js API framework that uses next-generation JavaScript features that can be used today, like Classes, Decorators and async/await for maximum expressiveness.

This is a framework for building data layers that map directly to REST APIs. It's a bit like ORM for HTTP. It comes with base classes for routing, REST resources, models, and validation, and the models can serialise data to RethinkDB. To talk to other databases a new base model class would have to be written.

Thanks to ES6, the model syntax is very clean:

let Model = ApeyEye.Model;

class MyModel extends Model {  
    constructor() {
        super(async function() { (...) });

    static async fetch() { (...) }
    static async fetchOne() { (...) }
    async put() { (...) }
    async patch() { (...) }
    async delete() { (...) }

To me this looks like C# without the extra syntax for strong typing. The validation API looks similar to what you might have seen before with modules like Mongoose.

I like the idea of object-resource mapping at the HTTP level. In Node web apps we seem to spend a lot of time thinking about HTTP servers and APIs, so this feels like it could reduce the amount of boilerplate required to interface from that step to the database layer.