January 6th, 2016 | code quality, editor, es6, javascript, nodejs, react |

This post is an extract of a github repo I’m working on chtefi/react-stack-step-by-step to explain step-by-step from scratch a full reactjs stack

The answer is : by applying some linting on your source code.

Code linting is a set of rules to apply, to enforce some styles and rules into the code, and even check if you’re writing bugs (due to typos mostly).

By applying the same rules on the whole source code, you can, for instance, make sure that everywhere there is no missing semicolons (or that there is not semicolons at all if you don’t like them), that the variables are properly named, that the order of methods to override is fixed, that the constructor is the first method, that the depth of the functions is not more than 4 etc. etc.

Hopefully, we can use some presets created by big tech companies to avoid to set them all manually.
Moreover, if they follow those styles, it’s a good opportunity to follow the same ones.!

Let’s see what is needed in order to apply this linting and configure it as you expect.
Moreoever, we will add some special packages to deal with Reactjs code, because that needs more.

What packages to install to do linting ?

We have multiple choices.

  • JSLint : original project
  • JSHint : fork of JSLint
  • ESLint : new recent alternative (2013), pluggable

We are going to stick with ESLint because it supports Reactjs special linting rules through a plugin eslint-plugin-react.

And because the linting is only necessary for the developers, the npm dependency is installed with --save-dev.

$ npm i -D eslint

How to use it

eslint gives us the command of the same name in ./node_modules/.bin/eslint.
It just takes in parameter a folder or a file on which we want to apply some linting such as :

$ ./node_modules/.bin/eslint src

For instance, if we have some ES6 code in there, doing that could lead to some errors :

src\components\App.js
  1:2  error  Parsing error: Illegal import declaration

src\components\Product.js
  1:2  error  Parsing error: Illegal import declaration

It’s because by default, ESLint does not understand ES6.

Before fixing that, let’s simplify our life, and create a npm script command to run this command quickly.

Add a npm script

To avoid to type the eslint command each time, let’s add a simple npm script :

"scripts": {
  "lint": "eslint src"
  ...

Remember: when npm executes the scripts, it has access to the ./node_modules/.bin folder automatically eslint refers to. No need to add the path in the script.

Now, let’s fix our ESLint.

ESLint + ES6 + JSX

As the documentation states, we need to create a file .eslintrc at the root of the project to set the configuration.

First of all, let’s make it understand imports.

{
  "ecmaFeatures": {
    "modules": true
  }
}
6:2  error  Parsing error: Unexpected token const

Now, it does not understand const. Let’s make it understand ES6.

{
  "ecmaFeatures": {
    "modules": true
  },
+ "env": {
+   "es6": true
+ }
}
25:8  error  Parsing error: Unexpected token <

Now, it does not understand JSX it seems. Let’s make it understand JSX.

{
  "ecmaFeatures": {
+   "jsx": true,
    "modules": true
  },
  "env": {
    "es6": true
  }
}

Boom, it passes without error !
That means it could parse it properly at least.

There is no error, not because the code is already perfect, but because : All rules are disabled by default.

But there are a ton of rules, let’s see how to extend some existing defaults. We are not the first person who want to use it right ?

Extends some default ESLint configuration

It’s recommanded to extend the eslint:recommanded set of rules, to begin with.

But we can also extend some other known ones, such as :

  • : want to work at airbnb ? Learn their styles.
  • : a nice style overriding some properties of eslint:recommanded. I’m not fan because it forbids semicolons, commas on the last array item, all those useless things I like to write.

To extends those rules, npm i them or use the eslint:recommanded one directly :

{
+ "extends": "eslint:recommended",
  "ecmaFeatures": {
    "jsx": true,
    "modules": true
  },
  "env": {
    "es6": true
  }
}
3:8     error  "Toolbar" is defined but never used      no-unused-vars
19:378  error  Unexpected trailing comma                comma-dangle

Now we have some linting issues.
But it seems ESLint does not understand yet this kind of program :

import Toolbar from './Toolbar.js';
...

The variable Toolbar is used by (translated to React.createElement(Toolbar)), so the no-unused-vars error is not a true error.

To make it understand that the imported components are used in JSX, we need to install the plugin eslint-plugin-react and add a special rule jsx-uses-react from this plugin, that will remove this ESLint false error.

$ npm i -D eslint-plugin-react
{
  "extends": "eslint:recommended",
  "ecmaFeatures": {
    "jsx": true,
    "modules": true
  },
  "env": {
    "es6": true
  },
+ "plugins": [
+   "react"
+ ],
+ "rules": {
+   "react/jsx-uses-react": 1
+ }
}

Tada, we are left with some true linting errors such as :

19:378  error  Unexpected trailing comma  comma-dangle

This one states that you have a line finishing by a trailing comma in object literal and that you should not (because you have a rule that forbids it).

You can also see this kind of error :

6:19  error  "document" is not defined  no-undef

Javascript environments

ESLint doesn’t know what is document, it didn’t found it in the scope. By default, it does not assume the environment is a browser (because it can be a pure nodejs program, where document does not exist). Therefore, we have to specify we are dealing with javascript that’s going to be used in the browser, and that will have access to document, window, console.log and so on.

{
  "extends": "eslint:recommended",
  "ecmaFeatures": {
    "jsx": true,
    "modules": true
  },
  "env": {
    "es6": true,
+   "browser": true
  },
  "plugins": [
    "react"
  ],
  "rules": {
    "react/jsx-uses-react": 1,
  }
}

There are a lot of different environments, you can find them here http://eslint.org/docs/user-guide/configuring.html.

Examples :

  • node
  • worker
  • mocha
  • jquery

Each of them exposes certain globals (that ESLint will assume they exist) that you don’t need to specify.
You can find the list here https://github.com/sindresorhus/globals/blob/master/globals.json.

Overriding rules

If I want to allow trailing commas, I can override the rule :

"rules": {
  "react/jsx-uses-react": 1,
+ "comma-dangle": 0
}

For comma-dangle rule :

  • 0 means : you don’t care (disabled).
  • 1 means : you get a warning if that happens, it’s tolerated (ESLint will still succeed)
  • 2 means : ESLint is going to fail if that happens

Some rules accept some options to change their behavior.

For instance, if I want to force trailing commas for multilines, it’s possible :

"rules": {
  "react/jsx-uses-react": 1,
+ "comma-dangle": [ 2, "always-multiline" ]
}

This will generate errors if there is a missing trailing comma on arrays or objects that span multiple lines.

The option has no effect if the code is 0 (disabled).
The available options (if there is) depend on the rule, check http://eslint.org/docs/rules/comma-dangle for instance.

Personally, I like those dangle-commas because that means I can switch the lines order without playing with the end-of-lines.

Anyway, as you saw, it’s very configurable and anybody can match its code style and force it everywhere in it source code.
But that’s not useful only for that, but can help to find bugs before runtime.

Bug finding

The biggest issues when typing Javascript are the typos. Because we often lack a good auto-completion, or we are used to type everything, we do typos. And we find them at runtime, not funny eh?

Linting your code to find those typos is a big win :

38:34  error  "decription" is not defined              no-undef

Typo !

It’s never a good idea to disable the rule no-undef, you can understand why.

More Babel syntax available thanks to babel-eslint

ESLint uses espree to parse ES6.
But we are using Babel, and Babel handles some features such as the spread notation that are not handled by espree :

const obj = { a: 1, ...{ b: 2, c: 3 } };

ESLint won’t be able to parse that :

19:18  error  Parsing error: Unexpected token ..

Meaning we need to plug the Babel parser to make it understand.
Hopefully, it’s planned and pretty straightforward, just install this package :

$ npm i -D 

We install the latest beta because it is using Babel 6

And define Babel as the parser of ESLint (that will be our last update to .eslintrc) :

{
  "extends": "eslint:recommended",
  "ecmaFeatures": {
    "jsx": true,
    "modules": true
  },
  "parser": "babel-eslint",
  "env": {
    "es6": true,
    "browser": true
  },
  "plugins": [
    "react"
  ],
  "rules": {
    "react/jsx-uses-react": 1,
    "comma-dangle": 0
  }
}

No more syntax error.

It’s quite standard to use this plugin nowadays, because most Javascript projects are using Babel, thus, you always want to parse your code source with Babel, for any third-party app working with it.

Now, you have a proper ESLint configuration, you can code properly and invite people to code with you. You are sure they will follow the style and conventions you enforced.

It’s often a good opportunity to check the linting when building or publishing your package, for instance, in package.json‘s "scripts":

  "compile": "npm run lint && webpack",

If an error occurs, webpack won’t be executed.

Some common errors

Let’s quickly go through some classic linting errors :

  • "Toolbar" is defined but never used | no-unused-vars : if you’re using it won’t find it unless you are using react plugin in ESLint.
  • "items" is defined but never used | no-unused-vars : a plain js variable you are not using, remove it
  • Unexpected var, use let or const instead | no-var : var is evil
  • Strings must use singlequote | quotes : prefer ' over "
  • Unexpected trailing comma | comma-dangle : the famous trailing comma at the end of multilines
  • Extra semicolon | semi : if you want or don’t want semicolon at the end of statements

As you understood, the keyword on the right is the code you want to look for to understand what it means or to override it as you wish.

In-code ESLint hints

We only deal with a single file .eslintrc for now, meaning it’s global to all our source code.

But sometimes, you want to make some exception, mostly because you added a hack somewhere.
That generates you a linting warning or error and you just want ESLint to ignore it.

You can add special comment in your code to talk to ESLint :

// eslint-disable-line

/*eslint-disable */
... ugl-, err, hacky code ...
/*eslint-enable */

Your text editor / IDE supports linting on-the-fly

Last but not least, every good text-editors or IDEs have a plugin to automatically apply linting to your code when typing, and display a marker next to the line if something is wrong : because you don’t want to check back your console and re-execute the full linting each time you write some lines.

Check your IDE doc for more info.

  • Sublime Text plugin
  • Atom
  • WebStorm
  • Visual Studio

In my case, I’m using the best text editor aka Sublime Text, you need to install :

This is what you can see in your editor :

Have fun !

Webpack Hot Reloading and React

December 29th, 2015 | hot reloading, javascript, react, webpack |

This post is an extract of a github repo I’m working on chtefi/react-stack-step-by-step to explain step-by-step from scratch a full reactjs stack

– You already use HR ?

If you have a project using webpack, React, you probably have followed some tutorials and blogs to add the Hot Reloading piece.

Here, we are going to explain what’s going on under the hood, and how the HR projects / plugins you installed are working together (webpack HR middlewares, react-transform..).

We are going to use the latest React HR project in date react-transform-hmr and not the older one react-hot-loader which has been sentenced to the maximum penalty : the-death-of-react-hot-loader. I guess it’s still working properly but you know that the Javascript community is always on the bleeding edge side!

– You don’t already use HR ?

If the HR part does not sound familiar to you, that’s fine because I’m going to explain step-by-step why it’s mandatory to use HR nowadays, and what is the way to install and use it into your project.

 

Let’s just start by resuming why everybody is now talking about HR (beyond Javascript).

Why should we enjoy Hot Reloading ?

In one word : productivity.
In another word : DX (Developer eXperience).

Some more explanations :

– you broke your F5 key years ago, you can’t refresh anymore
– you don’t want to develop blindly, then refresh, then try again. It’s a backend thing. We have a UI, it’s alive
– you don’t want to lose your application state (by doing a full refresh) if you just fixed a typo or a color
– that can display your compilation and runtime errors directly in the browser in the exact spot in the UI where it’s used
– you can do HR with Javascript, CSS, anything. We’ll just focus on React components here.
– no caveat

As soon as you put it in place, it will work forever without any modifications, for any of the future files you’re going to add. It’s just some pipes to plug together to make it work and last forever.

2015-12-28: actually there is only one caveat (!) : the React HR plugin we are going to use does not handle the stateless functional components created with the simpler React v0.14 syntax : const App = (props) => {

Hello {props.name}
};.
Refer to comment.

Now, let’s tackle the packages we need to install to use it in a nodejs project.

What packages to install to use HR ?

Let’s suppose you already have a base project using :

webpack to compile your javascript bundle(s)
React for your frontend ofc
– a nodejs server that runs a http server such as expressjs to serve your static content (html, js, css..) while you’re developing

You now want to experiment HR.

webpack to the rescue

webpack is actually the main actor dealing with the HR, it already exposes an API to process some part of the HR pipeline.

We just need to add some wrapper around to use its API, and some more logic to manage the specific React components state : you don’t want to lose the current state of your components when you change something in a js file (a style, some constant, a prop, add a React component inside an existing one etc.).

We need to install 4 packages : 2 for webpack, 2 for React.

webpack-dev-middleware
– a classic expressjs middleware, where requests are passed on
– it automatically watches the sources for changes to recompile the javascript bundle server side if some javascript source have changed
– it always serves the bundle up to date

webpack-hot-middleware
– a classic expressjs middleware, where requests are passed on
– it automatically subscribes to the bundle recompilation events (such as “start”, “done”), to notify the frontend that something has changed and it need to update itself
– it uses SSE to communicate with the frontend

Specific packages for React HR

babel-plugin-react-transform
– it can add any code around React component methods during the Babel compilation ES6+JSX to ES5. You should already have configured your babel loader in webpack, such as :

 module: {
    loaders: [{
      test: /\.js$/,
      loader: 'babel',
      include: path.join(__dirname, 'src'),
    }]
  },

react-transform-hmr
– it is used by babel-plugin-react-transform to add specific code around the React components to properly handle HR and their current state

That gives us :

$ npm install --save-dev webpack-dev-middleware
$ npm install --save-dev webpack-hot-middleware
$ npm install --save-dev babel-plugin-react-transform@beta
$ npm install --save-dev react-transform-hmr
// or for the copy/paste, all together :
$ npm i -D webpack-dev-middleware webpack-hot-middleware babel-plugin-react-transform@beta react-transform-hmr

2015-12-28: we explicitely ask for the beta (>=2.0.0) of babel-plugin-react-transform because for now, the latest published version does not work with Babel 6. But work has been done and is just waiting to be merged.

 

Now that we have installed the necessary packages, it’s time to configure them.

Configure Babel

We need to configure Babel (we are going to use .babelrc) to use babel-plugin-react-transform and react-transform-hmr to add the HR code around them.

The most basic configuration is :

{
  "presets": ["react", "es2015"],
  "env": {
    "development": {
      "plugins": [
        ["react-transform", {
          "transforms": [{
            "transform": "react-transform-hmr",
            "imports": ["react"],
            "locals": ["module"]
          }]
        }]
      ]
    }
  }
}

Basically :
– that adds the transform babel-plugin-react-transform for the development NODE_ENV only
– this transform retrieve all the React components it can find in the source code
– it passes them down to each of its processors defined in "transforms" to let them add their custom code. (in our case, react-transform-hmr will add the HR code)

 

For the record, babel-plugin-react-transform handles as many "transforms" as we want. They are just going to be called right after each other. For instance :

{
  "presets": ["react", "es2015"],
  "env": {
    "development": {
      "plugins": [
        ["react-transform", {
          "transforms": [{
            "transform": "react-transform-hmr",
            "imports": ["react"],
            "locals": ["module"]
          }, {
            "transform": "react-transform-catch-errors",
            "imports": ["react", "redbox-react"]
          }]
        }]
      ]
    }
  }
}

The React component code will pass through react-transform-hmr, then through react-transform-catch-errors.
Each of them will add its code around each components.

FYI, the latter is used to catch errors that are thrown in the render() method of the React components. Then it’s using its "imports" property to redirect the error to a visual React component. Here redbox-react displays a big red screen of the death with the stacktrace for instance. But it could be anything else.

Basically, react-transform-catch-errors just adds try { render() } catch (e) { ... } around the original render() method of your components, and in the catch, it’s returning the React component you gave in "imports". Makes sense right ?

Now, our React code is ready to handle HR.
We now have to make the server communicate to the browser that the code has changed and that it needs to update.

Handle server/client communication to send/receive HR updates

Bundle recompilation on the fly

First, we need to make the server aware that the source code has changed to recompile the bundle, and then notify the browser.
That’s the role of webpack-dev-middleware and webpack-hot-middleware.

webpack-dev-middleware will automatically start to watch the source code for changes and recompile the bundle
webpack-hot-middleware will be notified a new bundle is compiled and will notify the browser

We just need to plug them into expressjs as middlewares to start them :

var express = require('express');
var webpack = require('webpack');
var path = require('path');

var webpackDevMiddleware = require("webpack-dev-middleware");
var webpackHotMiddleware = require("webpack-hot-middleware");
var webpackConfig = require('../webpack.config');

var app = express();

var compiler = webpack(webpackConfig);
app.use(webpackDevMiddleware(compiler));
app.use(webpackHotMiddleware(compiler));
app.use(express.static('src'));

app.listen(3000);

But how is the browser going to handle the updates ? It’s where webpack itself rises.

Browser live update

We need to add some code client-side to deal with it, otherwise, it’s not possible. HR is not browser native or anything.

Therefore, to inject some more code, we will use the webpack bundle entry point in webpack.config.js, to add another entry.
A bundle could have several entry points.
It is just there to say to webpack : “hey, resolve the import dependency (for make the bundle) tree starting from those files!”.

entry: [
  'webpack-hot-middleware/client',
  path.join(__dirname, 'src', 'App.js'),
],

The entrypoint webpack-hot-middleware/client simply refers to the file node_modules/webpack-hot-middleware/client.js.
It is the file that contains the code that will be used in the browser to handle the SSE communication with the server (to intercept the update notifications).

Then we need to add a specific webpack internal plugin HotModuleReplacementPlugin to expose the generic webpack HR API in the browser :

plugins: [
  new webpack.optimize.OccurenceOrderPlugin(), // recommanded by webpack
  new webpack.HotModuleReplacementPlugin(),
  new webpack.NoErrorsPlugin() // recommanded by webpack
]

This API will be used by the code injected from webpack-hot-middleware/client when this one will retrieve some “update” events through its SSE. (specifically, it will call module.hot.apply(..) from HotModuleReplacementPlugin).
You follow ?

 

Nothing more to do, you’re good to go !

See it in action

Process :
– start your nodejs server
– go to your page using the bundle on your browser
– go to your code editor and change some javascript bits
– see the live update !
– if not, check your console in the browser to see some nice error messages

Behind the scene :
– the server automatically recompile the bundle if some javascript code is updated and notify the browser to update itself via SSE
– the bundle used in the browser contains some SSE code to intercept those notifications, some generic HR code to “patch” the javascript, and some custom HR code for the React components to not lose their current state

A boilerplate on github

You can checkout this boilerplate from @dan_abramov https://github.com/gaearon/react-transform-boilerplate to give a try.
It’s very simple and does exactly what we just talked about.
You will see some more options used but nothing fancy.

Its .babelrc is using react-hmre instead of our two transforms packages (babel-plugin-react-transform@beta and react-transform-hmr), but it is exactly the same actually. react-hmre simply encapsulates them.

More bits to learn

Let’s explain some more in-depth some aspects of the code used.

webpack-dev-middleware is optional, but…

Without webpack-dev-middleware, you just need to launch the webpack watch yourself :

// app.use(webpackDevMiddleware(compiler));
// replace the dev-middleware with a simple watch() (args are mandatory)
compiler.watch({}, function(){});
app.use(webpackHotMiddleware(compiler));

Because webpackHotMiddleware subscribes to the bundle compilation events (no matter what started it), it will work.

But you’ll suffer from some consequences : a bunch of .js and .json files in your project will appears each time a compilation occurs.

They contain the delta sent to the client to update itself (webpack only sends the updated chunks, not the whole bundle each time). The advantage of using webpack-dev-middleware is that you won’t see those files. They will be handled in-memory by itself. That’s why you need to install this particular package too.

babel-plugin-react-transform and react-transform-hmr

Without the code added by react-transform-hmr, webpack would not be able to hot update the React components, you would get this in the browser console :

[HMR] bundle rebuilding
[HMR] bundle rebuilt in 160ms
[HMR] Checking for updates on the server...
[HMR] The following modules couldn't be hot updated: (Full reload needed)
[HMR]  - ./src/App.js

What’s inside the SSE ?

1. The browser initializes a SSE request : (thanks to the code webpack-hot-middleware/client.js injected in the bundle) on this specific url : GET localhost:3000/__webpack_hmr (it never returns). It’s handled by the server that knows it’s SSE. (by the webpack-hot-middleware expressjs middleware)

Then if a Javascript file is edited, because webpack-dev-middleware started a watch on the sources, webpack-hot-middleware is notified (because it subscribed to the recompilation events) and notify the frontend via SSE with a new module map (used by webpack), such as :

data: {"action":"building"}

// few ms later ...

data: {"action":"built","time":260,"hash":"6b625811aa23ea1ec259","warnings":[],"errors":[],"modules":{"0":"multi main","1":"./~/fbjs/lib/invariant.js","2":"./~/react/lib/Object.assign.js","3":"./~/fbjs/lib/warning.js","4":"./~/fbjs/lib/ExecutionEnvironment.js","5":"./~/react/lib/ReactMount.js","6":"./~/react/lib/ReactElement.js", ...

Then the frontend asks for those 2 files:
(I guess the hash used in the GET comes from the SSE data ? I didn’t check)

GET localhost:3000/0.0119cbdcd4c2cf8d27c2.hot-update.js

{"h":"6b625811aa23ea1ec259","c":[0]}

GET localhost:3000/0119cbdcd4c2cf8d27c2.hot-update.json

webpackHotUpdate(0,{

/***/ 97:
/***/ function(module, exports, __webpack_require__) {

  /* WEBPACK VAR INJECTION */(function(module) {'use strict';

  ...

Those particular urls are served by webpack-dev-middleware which is keeping those files (*.hot-update.js[on]) in memory and serves them as any classic static file. They are requested by the code injected by webpack.HotModuleReplacementPlugin() that handles the responses and hot-updates the javascript with the new code.

Conclusion

Before I dug into, I was finding that the HR was a bit complicated to understand how it works, who are the actors, how does it communicate, etc. I was never sure what package was used for what exactly, and when. I hope those explanations were clear enough and that now, you know as much as me ! (or more!) Don’t hesitate to add more details or correct me if I’m wrong.

Finally, it’s not that complex but it just need a lot of “pipes” to plug everything together. But it all makes sense.

Unfortunately, there are still some caveats with the way I exposed :
– it doesn’t work for functional stateless React components const App = (props) => {

Hello {props.name}
};
babel-plugin-react-transform is simply an experiment, maybe it will die
– is working on to handle HR at the function level directly, to make it more generic
webpack is an awesome tool

React inline styles VS CSS : benchmark

August 17th, 2015 | javascript, performance, react |

CSS vs Inline

So, I was wondering if there was any performance downside to use React inline styles (I like them!) vs keep the old plain css stylesheets (that we love to override!). Of course there is, but I wanted some numbers!

I think both ways are useful actually, as Michael Chan said at React Europe ():
– the css can be used for the layout (such as the bootstrap layout classes: row-fluid, span*, etc.)
– the inline styles should be used for the “state-styles” (the style that can change according to a state, which is dynamic).

Why stupid

I decided to try something stupid and not truly relevant but anyway :

Generate a big table, one with inline styles, the other (in another page), with the same data, but with css, and then check the performance/size/time of both.

That’s why it’s not relevant because you would not generate a big table in your DOM. You will more likely have some kind of virtual scrolling / lazy rendering.
But, what about a test, just to see if that’s more slow when I scroll or not, and what about the rendering time ?

 
Chrome 45b, React 0.13.3 (debug and production)

Test case

So I generated a

of 1,000 rows with 9 columns, all of them with the same content “”, then I did the same with 10,000 rows to check the trend.

I’m going to test :
– the smoothness when I scroll down the page through Chrome DevTools Timeline
size of the DOM : useful to know for isomorphic universal javascript (server-side rendering)
– time to mount the DOM : I’m going to use componentDidMount, this is where the DOM is available after render is called
– time to be rendered by the browser : I’m going to use requestAnimationFrame to know when the next frame after render is ready

Basically, the skeleton of the React component is :

const createOneInlineStyleRow = (i) => {
  return (
... ); }; export default class AppInline extends React.Component { componentDidMount() { console.timeEnd('didMount'); } render() { console.time('render'); console.time('didMount'); requestAnimationFrame(function() { console.timeEnd('render'); }); const rows = times(NB_ROWS, createOneInlineStyleRow); return (
{rows}
); } }

The style of the :

const style = {
  fontFamily: 'Consolas',
  padding: 10,
  color: "#444",
  border: "3px solid orange",
  position: "relative",
  width: "15%",
  height: "25px",
  letterSpacing: 0,
  overflow: "hidden",
  fontSize: 10,
  fontVariant: "small-caps"
};

And the same in css for the css table :

.tableCss td {
   font-family: Consolas;
   padding: 10px;
   color: #444;
   border: none;
   border: 3px solid orange;
   position: relative;
   width: 15%;
   height: 25px;
   letter-spacing: 0;
   overflow: hidden;
   font-size: 10px;
   font-variant: small-caps;
}

Basically, here is this beautiful design :

Results

Timeline

I found no difference when scrolling, Chrome DevTools timeline supports my perception : no difference, no fps drop.
The fact that the DOM is inline or in a proper css seems to not matter, I guess it’s already in the browser memory when it’s rendered so it does not influence the smoothness.

Size of the DOM

Without surprise, the DOM size is huge with the inline styles and is linearly proportional to the number of rows.

Type 1,000 rows 10,000 rows Ratio
CSS 517,725 chars ~5,177,250 chars x10
Inline 2,283,742 chars ~22,837,420 chars x10
x4.4 x4.4

That’s clearly something to take into account if you do some universal javascript. 2,000,000 chars is 2MB of data. (but who sends a big table anyway?!)

Time to mount the DOM

This is where componentDidMount is useful. We start a timer in the render method and end it when componentDidMount is called.
React has done its job converting the virtual DOM into a proper DOM and has injected it into our mounted node.

I let the times with the development version of React, because I started with and used the production version afterwards. They should not be taken into account, it’s not relevant in our case.

Type 1,000 rows 10,000 rows Ratio
CSS (debug) 650ms-750ms 6,000ms ~x10
Inline (debug) 1,000ms-1100ms 10,000ms ~x10
CSS 310ms 2,300ms ~x7.5
Inline 600ms 4,900ms ~x8
x2 x2.1

Yes, it takes more time to stringify our virtual DOM / mount it into the DOM.
The delta decreases for less rows but it’s still significant: 70ms (css) against 105ms (inline) for 100 rows (x1.5).

Rendering time

The DOM is mounted, the browser needs to render the table now. We can assume it will take longer to render the inline styles, because it has more to parse and store every style attribute of every td.

Type 1,000 rows 10,000 rows Ratio
CSS (debug) 1,100ms-1,200ms 9,500ms ~x10
Inline (debug) 1,500-1,600ms 14,000ms ~x10
CSS 720ms 6,000ms ~x8
Inline 1,080ms 9,400ms ~x8.7
x1.5 x1.56

Still a small overhead. I guess we could see some nice differences according to which browser is tested out!

What about another browser ? Edge !

I gave a try on Edge with 10,000 rows (React production version) :

Type mount time rendering time
CSS 4,115ms 11,591ms
Inline 11,418ms 21,113ms

It’s basically the double of Chrome times. :cry:

We knew that

So yes, we were kinda aware of all these behaviors, but now, we have some numbers !

This global analysis demonstrated that the inline styles take way more size and more time to be handled by the browser, but it has no more impact as soon as it’s rendered.

Compared to all the advantages the inline styles offer, we just have to be aware of those potential performance bottlenecks when thinking about the .

Further

Some plugins exists to extract the inline styles to css such as :
https://github.com/petehunt/jsxstyle : code inline then extract the constants to a stylesheet
https://github.com/js-next/react-style + https://github.com/js-next/react-style-webpack-plugin :

Or if you want the full power of css in javascript (media queries, pseudo-selectors, modifiers, and more!) :
Radium

Générer des classes css avec un nom unique

May 23rd, 2015 | es6, javascript, react, webpack |

A l’heure où l’on parle de micro-services, où on cherche à tout modulariser, et à créer des systèmes à base de dépendances explicites, à ne plus rien mettre dans le scope global et à utiliser le scope local uniquement, histoire de maîtriser ce à quoi on a accès et d’éviter des effets de bord : on utilise encore un moteur CSS où on balance tous les sélecteurs à sa racine, qui utilise donc un scope global. Heureusement, pour ceux qui utilise le shadow DOM, ce problème est résolu. Mais quid de ceux qui ne l’utilise pas ?

Une partie de ce problème peut être évité en adoptant des normes d’écriture et de nommage telle que la norme BEM qui peuvent malgré tout ne pas suffir ou être délicate à utiliser.

Enfin, surtout avec BEM, les noms de classes peuvent être à rallonge, on aimerait bien généraliser le process de minification qu’on utilise sur le contenu des .js et des .css, sur le nom des classes elles-même ! Mais cela oblige à modifier d’une part le nom de la classe dans le fichier .css et également le code js qui l’utilise.

Il est même maintenant possible de complétement se passer de fichier .css et d’utiliser uniquement du style inline (quid des performances ?). Par exemple, avec React, le style peut être défini directement dans les composants javascript, et avec des outils tel que Radium on peut même utiliser les sélecteurs spéciaux css tel que :hover, ou les média queries.

Facebook et le CSS

Facebook a déjà résolu ce problème. Sans doute avez-vous vu la présentation de  où il évoque comment Facebook s’assure qu’il n’y a aucun conflit de nom de classe css, que le scope global n’est pas pollué, et que les développeurs peuvent facilement rajouter du style sans avoir peur d’avoir des effets de bord et de modifier le layout quelque part, sans le savoir.

Ils ont étendu le langage css en rajoutant une syntaxe spéciale pour les sélecteurs : button/container qui ne peut être utilisé que dans le fichier button.css qui a son tour est référence dans un composant React button.js, qui enfin, fait référence à className={cx('button/container')} pour définir la classe d’un élément.

Le process de build vérifie ces références et génére un nom de classe unique à partir de button/container (qui n’est pas valide en CSS) par quelque-chose comme ._f8z qui fera parti du scope css global mais qui n’entrera jamais en conflit avec quoi que ce soit vu que le nom est généré aléatoirement (et est unique), personne ne pouvant le deviner à l’avance. Tout le monde doit donc utiliser ce système pour travailler et styler son contenu.

Moi aussi j’aimerai faire ça. Ca tombe bien, webpack est là.

webpack et css-loader

webpack, et en particulier le plugin css-loader combiné à extract-text-webpack-plugin, permet de former un (ou des) bundle css à partir de fichiers .css .less ou .sass (avec les loaders qui vont bien) qui sont eux-même importés dans des fichiers .js :

import React from 'react';
import './App.less';

export default class extends React.Component {
  render() {
    return 
} }

Avec une configuration webpack de ce genre :

var ExtractTextPlugin = require('extract-text-webpack-plugin');

module.exports = {
  entry: './src/app.js',
  output: {
    path: __dirname + '/dist',
    filename: 'bundle.js'
  },
  loaders: [
     {
       test: /\.js$/,
       exclude: /node_modules/,
       loaders: [ 'babel-loader' ],
     },
     { // we can do: import './Component.css';
       test: /\.css$/,
       loader: ExtractTextPlugin.extract('style-loader', 'css-loader')
     },
     { // we can do: import './Component.less';
       test: /\.less$/,
       loader: ExtractTextPlugin.extract('style-loader', 'css-loader!less-loader')
     }
   ]
 },
 plugins: [
   new ExtractTextPlugin('[name].css')
 ]
};

Ce build permet de créer un bundle css qui contiendra tout le contenu référencé par les imports de fichiers .css ou .less dans les fichiers javascript.

import './App.less';

css-loader local scope

La nouveauté (d’avril 2015) est une nouvelle syntaxe au niveau des fichiers css pas encore transformés, mais prise en compte par css-loader :

:local(.container) {
  font-size: 30px;
}

Se transforme en :

._3ImWIJ65ktg-PxiyA_aFIC {
  font-size: 30px;
}

Cela signifie que vous ne pouvez plus utiliser simplement className="container", cette classe css n’existe plus. Et vous ne pouvez pas mettre className="_3ImWIJ65ktg-PxiyA_aFIC" quand même ! Il faut importer différemment le fichier .css ou .less :

import AppStyles from './App.less';
...

Les classes définies dans le fichier css seront accessibles via leur nom (si :local(.my-class) alors via my-class) dans l’objet importé, qu’on peut alors utiliser pour indiquer la className. Au niveau HTML, on aura ce rendu :

Autre exemple avec un autre sélecteur css à l’intérieur :

:local(.container) {
  font-size: 31px;
  span {
    letter-spacing: 5px;
  }
}

Cela génère bien :

._3ImWIJ65ktg-PxiyA_aFIC {
  font-size: 31px;
}
._3ImWIJ65ktg-PxiyA_aFIC span {
  letter-spacing: 5px;
}

Au niveau du bundle

AppStyles est en fait simplement un dictionnaire généré et injecté à la volée de la forme :

module.exports = {
  "container":"_3ImWIJ65ktg-PxiyA_aFIC"
};

className et pas style

Attention à bien utiliser className={ AppStyle.container } et pas style={ AppStyle.container } sans quoi l’erreur suivante se produirait :

Uncaught Error: Invariant Violation: The `style` prop expects a mapping from style properties to values, not a string. For example, style={{marginRight: spacing + 'em'}} when using JSX.

Le nom des classes générées

On peut modifier la manière dont le nom des classes sont générés. Par défaut, il s’agit d’un hash comme on peut voir, mais on peut le modifier de la sorte (via webpack.config.js) :

css-loader?localIdentName=[hash:base64]
_3ImWIJ65ktg-PxiyA_aFIC
css-loader?localIdentName=[path]-[name]-[local]-[hash:base64:5]
.src--App-container-3ImWI
  • path: le path du fichier javascript
  • name: le nom du fichier javascript
  • local: le nom utilisé dans le fichier css :local(.container)

Il n’y a malheureusement pas de méthodes (pour l’instant) pour générer des noms du genre ._a, ._b, … ._az histoire de rester ultra court et unique (étant un simple compteur).

La gestion de cet identifiant provient du module webpack loader-utils.

Plusieurs imports

Si un fichier Javascript dépend de plusieurs fichiers de styles et qu’un, il faut simplement concaténer le nom des classes provenant des 2 imports :

import AppStyle from './App.less';
import GlobalStyle from './Global.less';
...  
className={GlobalStyle.container + ' ' + AppStyle.container}

Plus loin

D’autres fonctionnalités sont disponibles, comme l’héritage de règles ou la définition de règle globale via :global, je vous conseille donc d’aller lire la page du projet : https://github.com/webpack/css-loader

Tout cela est encore récent et en développement (allant même à provoquer des breaking changes, des changements de syntaxe), ce qui la rend instable à utiliser pour l’instant, attention!

Using react-hot-loader with a webpack-dev-server and a node server

May 14th, 2015 | expressjs, hot reloading, nodejs, react, webpack |

2015-12-31: You should check out my recent post to use the new way of doing HR with webpack, and to have way more details :
Webpack Hot Reloading and React : how ?

Don’t work without hot-reloading

I got a project running its own Node server instance, using expressjs. It’s already bundling its assets with webpack, and it’s using React with the nice ES6 features, all good.

But it lacks of hot reloading. :-(

This is something we must have nowadays when you’re working with webapps and CSS/Javascript. You don’t want to refresh your whole page and lose your current state each time, you are going to lose your time, your patience, and your productivity !

Leave express alone and add webpack-dev-server on top

Thus, I decided to take a look and tried to add it while keeping the express server instance up and working. I didn’t want to replace the whole thing by a webpack-dev-server and reconfigure the public assets paths and all other stuff that my expressjs was providing.

After some tests, some readings here and there, I got a pretty straightforward solution without using any custom proxy code, nor changing my generated html.

The solution

For reference:
– the expressjs server is running on localhost:3000
– the webpack-dev-server is going to run on localhost:3001

Here is a git diff of my changes:

packages.json

+ "react-hot-loader": "^1.2.7",
+ "webpack-dev-server": "^1.8.2"

Just the necessary packages to do the hot reloading. (npm install --save-dev)

webpack.config.js

+var webpack = require('webpack');

- entry: path.resolve(__dirname, '../src/client.js'),
+ entry: [
+   'webpack-dev-server/client?http://0.0.0.0:3001',
+   'webpack/hot/only-dev-server',
+   path.resolve(__dirname, '../src/client.js')
+ ],

modules: {
  loaders: [
    {
-     loader: 'babel-loader'
+     loaders: [ 'react-hot-loader', 'babel-loader' ]
    }
  ]
},

+ plugins: [
+   new webpack.HotModuleReplacementPlugin(),
+   new webpack.NoErrorsPlugin()
+ ]

– we add webpack-dev-server entries into entry
– we add the react-hot-loader loader when processing the .js (it will add some js to magically do the hot reloading)
– we add the plugins for hot reloading.

More details here http://gaearon.github.io/react-hot-loader/getstarted/

server.js

This is the most important part, where we define a new webpack-dev-server instance that will be listen by the browser to process the hot reloading if any js file change.

// existing express server
var app = express();
app.use(...)
app.get(...)
app.listen(3000);

+// we start a webpack-dev-server with our config
+var webpack = require('webpack');
+var WebpackDevServer = require('webpack-dev-server');
+var config = require('./webpack.config.js');

+new WebpackDevServer(webpack(config), {
+   hot: true,
+   historyApiFallback: true,
+   proxy: {
+     "*": "http://localhost:3000"
+   }
+}).listen(3001, 'localhost', function (err, result) {
+   if (err) {
+     console.log(err);
+   }
+
+   console.log('Listening at localhost:3001');
+});

We are only adding a new webpack-dev-server instance without altering at all our expressjs server listening on localhost:3000.

– our webpack-dev-server listens to localhost:3001 and handle the hotness
– every requests (“*”) are redirected to localhost:3000.

This server serves only as a proxy for the hot reloading. More details here http://webpack.github.io/docs/webpack-dev-server.html.

At the end, there is still no hot reloading on http://localhost:3000 (it’s still a pure expressjs server).

But if you browse http://localhost:3001, and more precisely http://localhost:3001/webpack-dev-server/, you will the famous “App ready” hot reloading toolbar and everything will be automatically updated if you change one of your React component.

React server-side with ES6 syntax

February 26th, 2015 | es6, javascript, nodejs, react |

ES6 aka ES.next aka Harmony is already there

Even if it’s not fully standardized (last draft) and should get out mid-2015, ES6 is already there. We can already find several transpilers (a compiler that translates a language to another one) that translate ES6 to ES5 for our browsers or Node to run normally with the old known syntax.

Soon, it will be even useless to transpile with Node because ES6 is already on its way. For instance, Node has already implemented those features :

--harmony_scoping (enable harmony block scoping)
--harmony_modules (enable harmony modules (implies block scoping))
--harmony_proxies (enable harmony proxies)
--harmony_generators (enable harmony generators)
--harmony_numeric_literals (enable harmony numeric literals (0o77, 0b11))
--harmony_strings (enable harmony string)
--harmony_arrays (enable harmony arrays)
--harmony_arrow_functions (enable harmony arrow functions)
--harmony (enable all harmony features (except proxies))

And when using react-tools with the jsx tool (and reactify), you can have access too to some ES6 features.

For instance, with Browserify and Reactify :

browserify('app.jsx').transform({ es6: true }, reactify)

 
If you are not aware of all the new features, or just want to have a look again, check this page that resume clearly with examples what is available in ES6.

Babel FTW

But the best transpiler, the one that implements most of the features is Babel (formerly es5to6, they changed their name because they planned to go further than ES6 certainly, ES7 already being on its way !).

You can take a look at the compatibility table from kangax (awesome job!) to see what are the supported features for all of them : Traceur from Google, Babel, es6-transpiler, jsx.

On the 25/02/2015, Babel is already 78% compatible with the ES6 syntax. That’s pretty neat. Jsx being far at 16% ({harmony: true}), Node at 25% (--harmony).

Let’s not forget about the client side, Chrome being around 50% and Firefox 65%.

Before talking about React with ES6 in Node, I’m going to quickly present the most important and confortable features I think to not revamp our code later (with React at least). You can skip this part if you already know what features ES6 provide.

object literals

var name = "henry";
var phone = "+333456789"
var person = { name, phone };

Just sugar to avoid retyping the variable name and to be consistent.

templates

var what = "awesome";
console.log(`it's so ${what}`);

You just use backquotes and you have a basic template engine where you can evaluate any javascript inside.
No more unreadable “my name is ” + name + ” and I’m ” + yearOld + ” year” + (yearOld > 1 ? “s” : “”) + ” old”.

arrow functions

arr.map(item => item.value)

this being automatically passed to the function, no more need of ugly var self = this;

For instance:

class Math {
multiplyBy(i) { return 2*i; }
compute() { return [1, 2, 3].map(value => { return this.multiplyBy(value); }); }
}

class

class TopBarComponent extends React.Component {
  constructor() {
    super(props); // can be useful sometimes!
    this.state = { value: props.initialValue };
  }
  ...

Finally, a class keyword with its extends. No more prototype to play with and other module pattern, no more React.createClass, no more getInitialState(), you have a true constructor, let’s make some nice OO. No multiple inheritance through. Notice that the React props are now available in the constructor arguments.

short functions notations in classes

render() { return 
No function keyword
; }

And no comma between the functions or that’s not valid.

destructuring

(function({ name, age }) { // auto-associate the args
  console.log(`hi ${name} ${age}`);
})({ age: 12, name: 'henry', phone: '+333456789' });
// auto-associate the function result into the left member
var { name } = (() => { return { name: "toto", age: 30 } })();
console.log(name);

This is super useful and avoid to create manually bunch of variables.

module

import React from 'react';

basically that replaces var React = require('react');
you could also import several items at the same time using the destructuring :

import { React, cx } from 'react';

But it doesn’t work for now in Babel at least.
Those were the most useful features to know, and to run some React in Node.

Check out the others features, such as the promises, the generators, the spread parameters, the default arguments, let, const, symbol, iterators, and the new data structures (Map Set WeakMap, WeakSet), new functions on String, Math, Number…! So much to talk about. You can check out the Babel website to know what it’s all about.

React ES6 style

Let’s focus on React server-side now, using Node. We are going to use Babel to have the latest available features, and because it’s pretty straightforward to make it work.

– Install Babel globally, to have access to the babel executables npm install -g babel.

– Install react. You must have at least react>=0.13 otherwise Babel is going to fail with this error :

TypeError: Super expression must either be null or a function, not undefined

If the 0.13 is not yet available (it’s not yet at this time), force the installation using : npm install

Babel has an executable babel-node, that starts node with all its es6 features: babel-node app.jsx

Here is a program sample full ES6 style that just renders as a string (we are server side!) a component in another file:

App.jsx

import React from 'react';
import MyComponent from './MyComponent.jsx';

console.log(React.renderToString());

MyComponent.jsx

import React from 'react';

export class MyComponent extends React.Component {
  constructor(props) {
    this.state = { value: props.initialValue };
  }
  render() {
    var items = [ 1, , 3 ].map(x => {x * this.state.value});
    return 
{items}
; } }

You will have this result as expected:

3 9

We are already using the class, module, destructuring and arrow features in this tiny example.

So, this is the base template if you want to start playing with React in Node being full ES6 compliant. It took some time for me to find this result. I tested a lot of things, other frameworks and techniques to get my full ES6 working, and I found this one with Babel simple enough. So, it’s time to refactor our stuff now and combine this with some client side !

 

Check out the React post about this version 0.13 for more details: http://facebook.github.io/react/blog/2015/01/27/react-v0.13.0-beta-1.html

 

What does it look like in ES5 ?

Instead of using babel-node, you can use the executable babel to get the transpiled output. It’s pretty interesting to see how Babel translates ES6 to ES5.

For instance, our previous sample, if you do babel app.jsx, that gives us :

"use strict";

var _interopRequire = function (obj) { return obj && obj.__esModule ? obj["default"] : obj; };
var React = _interopRequire(require("react"));
var MyComponent = _interopRequire(require("./MyComponent.jsx"));

console.log(React.renderToString(React.createElement(MyComponent, { initialValue: "3" })));

The import feature is automatically replaced by an _interopRequire + require function. If we babel MyComponent.jsx, that’s WAY more verbose :

"use strict";

var _interopRequire = function (obj) { return obj && obj.__esModule ? obj["default"] : obj; };
var _prototypeProperties = function (child, staticProps, instanceProps) { if (staticProps) Object.defineProperties(child, staticProps); if (instanceProps) Object.defineProperties(child.prototype, instanceProps); };
var _inherits = function (subClass, superClass) { if (typeof superClass !== "function" && superClass !== null) { throw new TypeError("Super expression must either be null or a function, not " + typeof superClass); } subClass.prototype = Object.create(superClass && superClass.prototype, { constructor: { value: subClass, enumerable: false, writable: true, configurable: true } }); if (superClass) subClass.__proto__ = superClass; };
var _classCallCheck = function (instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function"); } };
var React = _interopRequire(require("react"));

var MyComponent = (function (_React$Component) {
        function MyComponent(props) {
                _classCallCheck(this, MyComponent);

                this.state = { value: props.initialValue };
        }

        _inherits(MyComponent, _React$Component);

        _prototypeProperties(MyComponent, null, {
                render: {
                        value: function render() {
                                var _this = this;

                                var items = [1,, 3].map(function (x) {
                                        return React.createElement(
                                                "span",
                                                { key: x },
                                                x * _this.state.value
                                        );
                                });
                                return React.createElement(
                                        "div",
                                        null,
                                        items
                                );
                        },
                        writable: true,
                        configurable: true
                }
        });

        return MyComponent;
})(React.Component);

module.exports = MyComponent;

We can see a bit how it’s translated :

– Class, superclass, and inheritance.
– Everything being a true ES5 object property value/writable/configurable using Object.defineProperties
– module.exports = MyComponent

 

You may have noticed the default keyword when we defined our React component:
export default class MyComponent {

If we omit it, the end of the generated file will be :

Object.defineProperty(exports, "__esModule", {
  value: true
});

instead of module.exports = MyComponent;

But we want this CommonJS syntax to work with Node, so we need this default keyword. If you don’t use it, you will get this error :

Warning: React.createElement: type should not be null or undefined. It should be a string (for DOM elements) or a ReactClass (for composite components).
Warning: Only functions or strings can be mounted as React components.

C:\test\node_modules\react\lib\ReactDefaultInjection.js:53
    tagName: type.toUpperCase(),
                 ^
TypeError: Cannot read property 'toUpperCase' of undefined

ES6 is not enough, we want ES7 !

It’s just getting started but Traceur, Babel and Firefox are already full steam ahead !
Check the kangax table : http://kangax.github.io/compat-table/es7/

You can use babel-node with the experimental flag : babel-node --experimental app.jsx to give a try to the already implemented ES7 features of Babel if you want.

February 12th, 2015 | javascript, react |

If you are not yet confortable with the notion of ownership and parent/child in React, take a look at my previous post.

How to communicate between React components ? That’s a good question, and there are multiple answers. That depends of the relationship between the components, and then, that depends on what you prefer.

I am not talking about data-stores, data-adapters or this kind of data-helpers that gets data from somewhere that you need to dispatch to your components, I’m really just talking about communication between React components only.

 

There are 3 possible relationships: