- Posted on November 20, 2015
Not everybody can use Node.js on the server side to be able to craft truly universal JavaScript applications. Still, one might want to set up server-side rendering to enhance React's performances, and of course allow JS-uncapable clients to use their app seamlessly (at least regarding navigation).

In a previous article, I quickly demonstrated how to render React code with PHP's v8js extension. We will now see how to handle the routing with Silex and react-router.

You can see I used the same hack as in my previous article to tell apart client and server-side rendering routines. You can also see that on the server, the matched location used for routing comes from a variable named uri, that wasn't declared anywhere. To understand this, we must jump to index.php:

You can then try out server-side rendering by commenting out the script tag in your template, in order to notice your React code truly is rendered by PHP! Navigate to /other and you will see the alternative content show up.

- Posted on November 16, 2015
Once you're done with the development of your Flux application, it is time to deploy it to your staging and/or production environment. But what if the app relies on configuration values that need to be specific to these environments? We will see how to address such a concern with Gulp.

We are going to store our configuration in JSON files. Values will be defined as environment variables, which can be set upon packaging your app with a continuous integration tool, and will be applied by a good ol' Bash script with regard to default values used for development. I assume all files, including gulpfile.js, are located at the project's root. We will begin by writing a sample configuration file, named (for example) config.json.dist:

Note: the ['config'] thing should make gulp run the config task prior to this one; however, I sometimes have encountered race conditions forcing me to make the shell sleep before actually running the script. It's a dirty hack though, so if you have had the same issue and found a better way to work around it, I'm interested!

After running gulp envify, you should see a config.json file with the following contents:

You can thus do the same in your CI job, and that's how you get environment-specific configuration in a Flux application. Stay tuned!

I would like to seize this opportunity to say that all my affection goes to victims of terrorism, from Paris last friday to other places in the world where such atrocities happen frequently, such as Beirut. Remember freedom and love cannot be killed; stay strong together and support each other in the hope of brighter days.

- Posted on October 27, 2015Flux is an architecture methodology for React applications proposed by Facebook to support its own UI library. It is designed to help inject data from the server (or any other data source) into the React components and the other way around.

React components are pieces of knowledge that should deal with themselves and nothing else, to respect the separation of concerns principle that comes with the object-oriented programming paradigm. When using such an architecture, one might wonder how to handle JavaScript events happening outside of a component's scope, but still affecting it; a good example could be a dropdown menu that needs to be closed whenever the user clicks anywhere on the page, outside of it. Flux is actually able to answer such a problematic: let's figure out how!

We need to catch clicks happening throughout our app (which we assume lives in a Root component) and let Dropdown know when they happen, so it can call its own toggle to close itself up. In order to do so, we will simply follow the Flux pattern, and start by defining a constant for the click event in a browserConstants module:

Now, clicking anywhere will close any open instance of this component! Messing around with the Flux pattern in such a way might prove itself useful in other contexts, feel free to leave a comment if you have anything to share on the subject.

- Posted on October 13, 2015
At a time when modules are becoming a de facto architectural solution for any serious front-end JavaScript codebase, and ES6 is at our doorstep, one may wonder if a systematic use of IIFEs and explicit strict mode declaration (using 'use strict';) is still relevant. This short note is thus designed to answer these questions.

Note: if you aren't using modules yet (should it be with CommonJS or the native ES6 syntax supported by Babel), you should really begin to! In both cases, Browserify is the way to go. Other solutions exist, of course, but these two respectively are the current (at least in the node.js world) and upcoming standard, and are the most broadly used.

Here we go:

A module's code does not need to be wrapped in an IIFE, as it is already in isolation anyway

'use strict'; is still needed in CommonJS modules, nothing new here; on the contrary, it is implied in ES6 modules

'use strict'; is needed in your code's entry point, which thus must also be wrapped in an IIFE to prevent concatenation side-effects

I hope this helped you know what you still have to do to keep your JS tidy as of today.

- Posted on October 5, 2015
Earlier today, I stumbled upon a tweet promoting Facebook's very own React rendering library, based on PHP's v8js, already more than a year and a half of age and surprisingly unpopular - although its poor architecture and flexibility may be a good start in a quest for reasons.

It indeed is designed to spit out, separately, the markup rendered from your root component, and the JavaScript code required to bootstrap the application clientside. The fact it writes the latter itself requires React to be declared in the global scope; however, the major PITA is the fact it needs to be fed React's source and your own separately. Both of these make it utterly incompatible with modern JS build tools and their use of module systems - in my case, native ES6 modules transpiled by Babelify.

I thus decided to bypass it and see how difficult it would be to mimic its behaviour, but in a much simpler way, by simply feeding V8js my bundled, plain-old-ES5 code, with its own bootstrap code using the module syntax - the clientside code, actually.