Thomas Belin

Compiling your TypeScript library (2023 edition)

2023-01-21T00:00:00Z

When we talk about compiling TypeScript projects there are usually two different contexts that are often mixed together: compiling a library vs compiling an application.

Those two contexts have slightly different constraints and need to be considered separately.

Today I'm going to focus on compiling a TypeScript library into a JavaScript package :)

The wishlist

In order to build a nice library that is suited for most projects, we want our package to be:

type-checked when consumed in a TypeScript project;
consumable in both commonjs and esmodule projects.

According to those wishes, we need to:

generate and package the declaration files (.d.ts);
be able to compile for different module targets.

Considered solutions

Today, we are going to benchmark the following solutions:

tsc - the native TypeScript compiler
esbuild - a full-fledged bundler and superfast compiler written in go
swc - a full-fledged bundler and superfast compiler written in rust
tsup - a TypeScript library builder based on esbuild

Side note: I have excluded tools that are only bundlers (webpack, rollup, ...) and babel which was superseded by swc and esbuild.

compiler	`d.ts` generation	multiple module targets
esbuild	❌	❌
swc	❌	❌
tsc	✅	❌
tsup	✅	✅

By comparing features, there is already something that stands out: only tsup can generate declarations files (.d.ts) and target multiple package type out of the box.

This is not a showstopper, though!
Nothing is preventing us from running the compilation twice for different module targets.
And for the d.ts generation, we could rely on tsc --emitDeclarationOnly to generate them for us. (Both are actually what tsup is doing under the hood).
It's worth noting that those processes do not step on each other's toes, so we could run both compilation in parallel :)

Here would be the equivalent commands for all the tools we are going to evaluate:

esbuild

esbuild src/*.ts --format=esm --outdir=./lib/esm &
esbuild src/*.ts --format=cjs --outdir=./lib/cjs &
tsc --emitDeclarationOnly --outDir ./lib/types

tsup

tsup src/*.ts --format esm,cjs --dts -d=./lib

swc

swc -C module.type=es6 src/*.ts -d ./lib/esm &
swc -C module.type=commonjs src/*.ts -d ./lib/cjs &
tsc --emitDeclarationOnly --outDir ./lib/types

tsc

tsc --module esnext --outDir ./lib/esm &
tsc --module commonjs --outDir ./lib/cjs

Benchmark

This benchmark will be all but scientific!
I just tested compiling a library that has a single TypeScript file on GitHub CI. Every compiler is run 30 times, which mean we have very little samples.
This is just to give us a rough idea of how they could perform.
Please take this benchmark with a grain of salt!

(Here are the benchmark sources and the results on Github Actions)

compiler	min	mean	max
esbuild	1704ms	1812ms	2365ms
swc	1794ms	1855ms	1908ms
tsup	2001ms	2034ms	2085ms
tsc	2160ms	2215ms	2420ms

Just to highlight how generating d.ts with tsc is costly, here is the same benchmark in which we skip generating declaration files:

compiler (no `d.ts`)	min	mean	max
esbuild	414ms	427ms	500ms
swc	537ms	550ms	570ms
tsup	559ms	570ms	587ms
tsc	2119ms	2196ms	2783ms

This is an order of magnitude different expect for tsc that seems to yield the same results whether it generates declaration files or not.

There is no obvious winner between swc, esbuild and tsup, but we can see that tsc is constantly outperformed.

Conclusion

One sad realization that I had while putting up together this benchmark is that no matter how fast the compiler is, it's always going to be at least as slow as tsc --emitDeclarationOnly.

My personal benchmark isn't really significant when it comes to performances comparisons... But we can clearly identify that tsc is the loser!

Now, with its built-in support for declaration files generation and multiple targets in my opinion tsup is the winner! It is tailored for building libraries!
Having only a single command to write to compile our libraries means it easier for maintenance and if, in the future, tsup figure out a way to generate d.ts files faster we will benefit from it by upgrading our local version.

Inspiring from React's useEffect to design effective APIs: the cleanup function pattern

2022-12-27T00:00:00Z

React's useEffect forces you to implement a quite powerful pattern: the cleanup function pattern (or teardown function pattern).

Let's see how we could leverage this pattern to provide perfect encapsulation and make deceptive calls impossible.

The cleanup function pattern

The idea is quite simple: A function that triggers a long-lived side effect returns another function to teardown this effect.

The pattern goes as follows:

function effect() {
  // trigger some long lived effect (listening to a websocket, registering DOM event listeners...)
  return function cleanupEffect() {
    // cleanup the long lived effect
  };
}

React developers will immediately recognize the useEffect pattern.

useEffect(() => {
  // trigger some long lived effect
  return () => {
    // cleanup
  };
});

This pattern is not so fancy nor new! It has been around in Reactive Programming libraries for a little while. RxJS' subscribe method follows this pattern, for example.
The main difference between React and RxJS (or others), is that RxJS implements the cleanup function pattern while React requires you to implement the pattern.

Benefits of the cleanup function pattern

There are two main takeaways to this pattern:

it brings perfect encapsulation;
it makes deceptive calls impossible.

Let's take a very common API that could benefit from the cleanup function pattern: the famous (add|remove)EventListener DOM API.

A traditional usage of this API would look something like this:

const sendPayload = () => {
  /*...*/
};
const button = document.getElementById("the-button");

button.addEventListener("click", sendPayload);
// ... later on
button.removeEventListener("click", sendPayload);

How about we try to implement our own addListener function that implements the cleanup function pattern?

function addListener(element, event, callback) {
  element.addEventListener(event, callback);
  return () => {
    element.removeEventListener(event, callback);
  };
}

Perfect encapsulation

One of the problems of the button.addEventListener is that you need to keep track of the DOM element (button), the event name (click) and the callback (sendPayload) in order to be able to remove this listener.
Lose one of those ingredients, and your click listener is here to stay!

Thanks to our custom addListener function that we implemented earlier, a single reference is needed in order to remove the listener:

const sendPayload = () => {
  /*...*/
};
const button = document.getElementById("the-button");

const removeListener = addListener(button, "click", sendPayload);
//    ^ removeListener is the only reference we need to keep
removeListener();

Now, the references to the button, the event name and the callback are encapsulated in the cleanup function. The only thing we need to keep track of is the removeListener function.

So we could even inline everything

const removeListener = addListener(
  document.getElementById("the-button"),
  "click",
  () => {}
);

⚠️ I would not suggest inlining code like the previous code sample. This example is there just to highlight that it is possible.

Preventing deceptive calls

Let's consider the following samples:

const sendPayload = () => {};

button.removeEventListener("click", sendPayload);
// ❌ Useless call, the listener has not been added yet (temporal coupling)

button.addEventListener("click", sendPayload);

button.removeEventListener("click", () => sendPayload());
// ❌ The listener is not removed because the reference to the function has changed

button.removeEventListener("auxclick", sendPayload);
// ❌ this is useless since we never added a `auxclick` listener

Some of those calls are not only useless, they are deceptive. You could feel like you have removed the listener, but in fact it's still there and active.

Those calls are made impossible with the cleanup function pattern!

If you do not have the reference to the cleanupFunction that you first created by triggering the effect, there is nothing you can do!
We are preventing what is called a temporal coupling.

A concrete example: Listening to a WebSocket

Let's implement a naive module that subscribes to WebSocket events and forwards them to the consumer:

let ws;

export function listen(onEvent) {
  ws = new WebSocket("wss://example.com");
  ws.onmessage = onEvent;
}

export function close() {
  if (ws) {
    ws.close();
    ws = undefined;
  }
}

A few things to note:

the close function can be called even if the connection is not active;
the module needs to be stateful and keep track of ws;
we need to perform some checks before we can safely close (if (ws));
if we call listen multiple times there will be instances that cannot be killed anymore, the reference to ws is lost forever.

Now, with our newly discovered pattern

export function listen(onEvent) {
  const ws = new WebSocket("wss://example.com");
  ws.onmessage = onEvent;

  return () => {
    ws.close();
  };
}

With the added benefit that the code is now more concise, everything is isolated, this module doesn't need to keep a local state, and you just cannot close until you have actually opened the connection.

Conclusion

Next time you are dealing with a long-lived effect, try to play with the idea of returning the function that will kill the effect, and see how it works for you.

I lately implemented it for Wire's webapp connection to the WebSocket, and I am totally sold 🚀

flatMap: an alternative to filter + map

2022-12-14T00:00:00Z

Filtering out falsy values or making sure we are dealing with the correct type before mapping are very common scenarios in webapps.
We often tend to use filter(...).map(...) to cover those use-cases.

But if we breakdown the type signature of a filter + map operation, we come to realize that there is an operator that is tailored for this: flatMap.

I'm going to use the notation A[n] to specify the signature of an array of size n of elements of type A

The `filter + map`'s signature

When analyzing the resulting type of a filter + map call, we find this:

filter: A[n] => A'[m] (where A' is a subset of A and m <= n)
map: A'[m] => B[m]

So chained together, a filter + map has this signature: A[n] => B[m]

...Which is exactly what the flatMap operator is about: changing an array in both type and size!

Filter-mapping an array in a single operation

How about we try to avoid this intermediate step and go straight from A[n] to our desired B[m] array?

Consider the following example:

const elements = [16, 20, null, 30, null];

const strings = elements //               (null|number)[5]
  .filter((item) => !!item) //            number[3]
  .map((item) => item.toString("16")); // string[3]

Ultimately, here, we want to transform an array of 5 null|number into an array of 3 string. We want to change both the number of items and the types of the items.

With flatMap we can achieve the same in a single run

const strings = elements.flatMap((item) =>
  !!item ? [item.toString("16")] : []
);

Better TypeScript inference

filter has a rather poor TypeScript integration when it comes to changing types (see this GitHub issue: Type guards in Array.prototype.filter). Filtering an array that contains A|B|... to an array that only contains a subset of those types does not benefit from any type inference.

One very common occurrence of this is to filter out falsy values (undefined, null ...) from an array.

In this case, you need to write a user-defined type guard in order to have TypeScript understanding the type of your resulting array.

const array = [1, 2, "three", "four"];
//    ^ (string|number)[]

const numbers = array.filter((item) => typeof item === "string");
//    ^ (string|number)[] ❌

const numbers = array.filter(
  (item): item is string => typeof item === "string"
);
//    ^ string[] ✅

User-defined type guards are pretty nice, but they have a major flaw: they are user-defined. Meaning, you can actually lie to TypeScript. For example, this is valid TypeScript 🙃:

function isArray(arg: any): arg is string {
  return typeof arg === "number";
}

Now the same filtering with flatMap

const numbers = array.flatMap((item) =>
  typeof item === "string" ? [item] : []
);
//    ^ string[] ✅

Here the TypeScript inference system kicks in and automatically detects the type of your resulting array.

Conclusion

Lately, I got used to replacing all my filter + map with flatMap. My code tend to be a bit more concise, but the main takeaway is the automatic type inference. There is a minor performance boost with flatMap, but not significant enough to make it a solid argument, in my opinion.

One could argue that flatMap is harder to understand. I believe that it's just a matter of getting used to it.

In the end, choosing flatMap over filter + map boils down to personal preferences (and agreement with your team). As long as you maintain consistent convention, it is all fine!

So give a try to flatMap and see for yourself how you feel about it 🙂

Recovering lost commits with git reflog

2022-12-04T00:00:00Z

Once familiar with git, editing code becomes a breeze. Refactorings and deletions feel as natural and safe as adding code. git is always there to back us up if something goes awfully wrong!

But what about editing the git history itself?
Could someone also have our back when we run rebase or reset?

The answer is "yes"! git has just the right for this job: the reflog!

Once you have built your own mental model of reflog, history-modifying commands become as natural and safe as editing code.

Before we actually dive in into what reflog is, we need to understand a key concept in git: the HEAD.

What is `HEAD`?

The HEAD in git is a simple pointer of the commit that is currently checked out in your local work tree.

When digging a little further into the core of git, you realize that pretty much anything is a reference to a commit in git. branches, HEAD, stash are all commit references.

A look into the .git/refs folder will reveal all those references:

.git/refs/heads/<branchname> → points to the latest commit of the branch <branchname>
.git/refs/stash → points to the latest commit on the stash (yes, the changes you stash are commits under the hood)
.git/refs/tags/<tagname> → points to the commit referenced by the tag <tagname>

Along with it, you will find 2 more special commit references in the .git/ folder

.git/HEAD → the reference of the commit that is currently checked out in your local repository
.git/ORIG_HEAD → the reference of the previous position of the HEAD (somewhat deprecated, reflog achieves the same goal and much more)

What is the `reflog`?

The reflog is a quite simple concept, actually! It is a log of all the moves the git HEAD has ever made in your local repository.

As such, reflog is a very personal log that will never be shared with the remote repository. You will share the same commit history with your coworkers (modulus the commits that are not pushed) but your reflog is yours only.

Which commands are moving the `HEAD`?

The rule of thumb is: if you move from one commit to another, then the HEAD is changing and a new entry is appended to the reflog.
To be slightly more exhaustive, let's explain a few git commands with regard to what it does to the HEAD:

git commit → creates a new commit and moves the HEAD to this commit
git checkout <branch> → moves the HEAD from its current commit to the commit referenced by <branch>
git pull → pulls the missing commits from the remote and moves the HEAD to the latest commit
git merge → creates a merge commit and moves HEAD to point to this merge commit
git reset HEAD~1 → moves the HEAD to the previous commit
...

Every single of those moves will be inserted into the reflog.

On the left, you see some git commands being executed. On the right is the live reflog

Let's take a simple example in order to let the concept sink in.
Imagine you are on branch feature and this is the initial state of the history:

A initial commit < (HEAD, feature)

Let's run a bunch of git commands on top of it

git commit -m 'second commit': moves HEAD and feature to the newly created commit

B second commit < (HEAD, feature)
|
A initial commit

git checkout A: moves HEAD to commit A (but feature is still pointing to B)

B second commit < (feature)
|
A initial commit < (HEAD)

git checkout feature: moves HEAD back to the commit referenced by feature

B second commit < (HEAD, feature)
|
A initial commit

git reset A: moves both HEAD and feature to commit A

B second commit
|
A initial commit < (HEAD, feature)

Every single of those moves will be recorded in the reflog.

Real life example: recovering from a `reset`

Let's say you ran the examples commands that we saw earlier. You are in that state

B
|
A < (HEAD, feature)

Both HEAD and feature are pointing to A and you might feel that commit B is lost forever.

Fear not, commit B is all but lost. It has just become unreachable from the branches you have... But it still exists in git!

Unfortunately, commit hashes usually do not look like A but more something like f1fec78c3a05708d7cb55d9e213f1ac51292b52f. This makes it impossible, for a human at least, to just recall that hash and run git reset <commithash>.

That's where the reflog comes into play.

As we said earlier, every single move you make between commits is recorded in the reflog. So, let's have a look at that reflog:

A HEAD@{0}: reset: moving to A
B HEAD@{1}: checkout: moving from A to feature
A HEAD@{2}: checkout: moving from feature to A
B HEAD@{3}: commit: second commit

The entire story of what happened in the previous example is just lying there. We can see everything we did in reverse chronology order (the most recent moves on the top). We can reconstruct the story just by reading this log from bottom to top. Most importantly, we now have the commit hash that we are interested in recovering: B.

So we have a few options to recover our commit:

git reset B # reseting our current branch to the commit hash we want
git reset HEAD@{1} # reset our current branch to the previous state of `HEAD`
git cherry-pick B # create a new commit on top of `feature` with the content of commit `B`
# last option is only if there is a single commit you want to recover

Recovering from a failed rebase is pretty much similar.
It is just a matter of finding the previous top commit of the branch in the reflog and running git reset <previous-top-commit-hash>. You will find all the initial commits exactly as they were before the rebase was initiated.

Conclusion

One thing you can keep in mind is: There are no lost commits in git, only harder-to-reach ones! Once something is committed to git, it is here to stay! A hard-to-reach commit is just a git reflog away!

So, do not fear playing with reset or rebase in your feature branches and enjoy confident history rewritings* 🤓! Git is here to back you up!

*But please in mind that rewriting history of branches shared with coworkers is never a good idea ;)

Get to know your browser's performance profiler

2022-05-05T00:00:00Z

At some point in your career, you might have glanced over the Performance tab in the devtools of your favorite browser. You eventually tried to generate a profile but probably got quickly discouraged by it. The high density of information displayed makes it a little overwhelming and somewhat scary. I have been there, I feel you!

Good news is: the learning curve is not actually that steep!!
Once you have grasped a few concepts it suddenly becomes your most valued tool to tackle performance bottlenecks.

This article will give you a few keys to understand how the profiler works and how to make a good use of it.
Let's completely forget about console.log and console.time, today we are diving into the Performance Profiler!

Side note: I won't go too deep into complex scenarios here but I will eventually do a follow up article about advanced techniques.

The data model

The first step that I took to actually understand how the profiler works was to read the Mozilla documentation about their new performance profiler (This is an excellent doc, go read it).

The first waouh effect that I had was when I got to see the data model that the profiler was using. It's actually pretty simple

In Mozilla's documentation, the data model is represented this way:

A A A
| | |
v v v
B B B
  |
  v
  C

A, B and C are function names and on the X axis we get time. By default Firefox and Chrome's profiler is configured to take a snapshot every 1ms, which means that here every column represents 1ms.

In this example that means that the stack has evolved like this over time

at 0ms A was calling B and B was still running
at 1ms B was calling C and C was still running
at 2ms C had finished its work and we are back in B
at 3ms the stack was empty

What the profiler can deduce from this is that:

A almost instantly called B;
We stayed ~1ms in B before calling C;
C took ~1ms to execute;
B took again ~1 more ms after calling C;
A ended right after calling B

with this model in mind, we can create some profile data

A A A A A A A A A
| | | | | | | | |
V V V V V V V V V
B B B B B B B B B
              |
              V
              C

B is taking a bit of time before and after calling C. We spent ~1ms in C and no time in A

A A A A A A A A A
              | |
              V V
              B B
              |
              V
              C

A is taking a bit of time before calling B. B and C are taking ~1ms

The limits of this model

Since the profiler is only taking 1 sample/ms, it means that a function call that takes less that 1ms has a high chance of not showing up in the generated profile.

Let's imagine the following scenario

function A() {
  B(); // < takes 0.5ms // snapshot #1
  C(); // < takes 0.4ms
  D(); // < takes 0.2ms // snapshot #2
  E(); // < takes 0.5ms
}

The generated profile will, most likely, look something like this

A A
| |
v v
B D

There will be no mention of C or E in this profile.

But, well, we are here to debug long tasks, remember? No need to have those fast executing functions in there. We do not care about them!

self time vs total time

One slightly confusing notion in the profiler is the self and total time.
It's actually a notion that can be quite easily understood, though.

They can be defined this way:

self is the time spent in the function itself
total is the time spent in the function and all the children functions that it calls

To get a feeling for it, here is a concrete example:

function superExpensive() {
  for (let i = 0; i < 1e10; i++) {
    console.log(i);
  }
}
function main() {
  superExpensiveComputation(); // < takes 1000ms
  for (let i = 0; i < 1e6; i++) {
    // ^ takes 5ms
    console.log(i);
  }
}

main will have a self time of 5ms but a total time of 1005ms.
superExpensiveComputation will have a total and self time of 1000ms

The total time helps identify parts of the code that are problematic while self time allows you to narrow down your search to the function that actually requires your attention.

Diving into the UI

With this model in mind, the UI starts making sense. The notions we have seen earlier start to be useful to make good use of the UI.
I am going to focus on the Firefox's profiler here but the same concepts apply to Chrome's profiler as well.

Side note This is an interactive article. When you see a Try me button on the page, feel free to open your Performance tab, start recording and click the button so you can play around with the generated profile. Note that depending on the computer you use it might freeze your browser a bit or be too fast to actually show up in the profile...

Identify long top-level functions: The call tree

Let's take a super simple code sample to get started. Imagine there is a button somewhere and when clicking on it, we trigger the function computeNumber

function generateNumber(nbIterations) {
  let number = 0;
  for (let i = 0; i < nbIterations; i++) {
    number += Math.random();
  }
  return number;
}

function computeNumber() {
  console.log(generateNumber(1e9));
}

This is what we will get in our profiler report:

[1] Since the profiler is actually profiling all the Firefox's processes, we want to make sure we are just inspecting the current web app we are working on
[2] We are web developer here, no need for the browser's internal stack traces, let's only keep JS stack traces
[3] We clearly see that we are spending the most amount of time in the generateNumber function (here the function has appeared in 488 samples, which means it has run for, at least, 488ms)

The call tree will allow you to quickly identify which top level functions are taking time. It's a good overview of where to start digging, but it does not help you quickly identify nested functions that have a long self time.

Identify long nested functions: Inverting the call stack

Now, let's consider the following

function computeMultipleNumbers() {
  let number = 0;
  for (let i = 0; i < 10; i++) {
    const fnName = `gen${Math.round(Math.random() * 100)}`; // We create a function with a random name
    const fn = new Function(`function ${fnName}() {
        return generateNumber(1e7);
      } return ${fnName}`);
    number += fn()();
  }
  result.innerText = number;
}

The particularity of this function is that it generates named functions with random names. Which means that now generateNumber will be called from many different functions.

Let's see what the profile looks like

Here we can see that there are many functions called, but they all have an empty self time. Which means this is not the function where we actually spent time, they were waiting for something else to finish.

Now, if we invert the stack.

Here it becomes clear where we actually spent time: in the generateNumber function :)

The inversion actually sorts the function with the highest self time and flatten them at the root of the tree. It's an excellent way to identify a time-consuming function and you get its call stack right next to it. With this you know exactly which function is a problem and from where it was called.

This call tree

topLevel     // self 0
  first      // self 0
  second     // self 0
    third    // self 10
    fourth   // self 7
      fifth  // self 8

Will give you this inverted call stack

third   //self 10
  second
    topLevel
fifth   // self 8
  fourth
    second
      topLevel
fourth  // self 7
  second
    topLevel

So we can quickly identify that we spent ~10ms in third called from topLevel > second

Conclusion

In this article we have covered the basic functions of the profiler. We have seen how to use the call tree and inverted call stack to quickly identify time consuming functions in your application.

Now those time consuming functions are not necessarily the functions that you need to optimize. The problem could lie on the parent function or even higher in the tree. The inverted call stack gives you a good starting point to walk your way up the problematic part of your app.

We have not covered here what the Flame Graph or Stack Chart are, how to profile async code or advanced techniques like markers. This is something I would love to cover in a follow up article. Feel free to ping me on Twitter if this would interest you ;)

Why React Hooks cannot be conditioned

2021-05-30T00:00:00Z

If you've used React hooks along with the eslint-plugin-react-hooks, you might have encountered the unexpected warning React Hook "useState" is called conditionally..
One can be quite surprised by this warning. At least I was.

Back then I had already seen a similar pattern with knockoutjs and I though it was a pretty bad design flaw. I was puzzled a modern tool, like React, would allow for such a weakness.

So I decided to investigate and deep dive into how React Hooks work and why they cannot be conditioned.

TLDR

the hook system is a quite big stateful machine that records every call to any hook (useEffect, useState ...);
at component's mount time all React hooks must be called so that they are registered against the hook system;
the order at which React hooks are called in a component must be stable through time and renders.

Disclaimer

I ran my investigations against React v17. Other versions might work differently (I am pretty sure it does not).

Also bear in mind that the code you are going to see in the article is not actual code from the React codebase. It's my own interpretation of what I read in there. The names of variables and functions have been changed for the sake of simplicity.

What happens when a hook function is called

Hook functions (useState, useEffect, ...) are rather interesting functions in that they are stateful at two levels:

They mutate values in a global state;
Depending when, in the component's lifecyle, they are called (mount, update, ...) they do not run the same code.

At mount time

Let's take a very simple component as a working example:

function Component() {
  const [first, setFirst] = useState("first");
  const [second, setSecond] = useState("second");
  return /*...*/;
}

When React mounts this component, it will create a state that is associated with the instance of the component. In this state it will store, among other things, a linked list of all the hooks that have been called during the mounting of the component.

So when React executes Component() any call to a use* function will create an entry in the linked list and we will end up with a state that looks like this:

{
  value: "first",
  next: {
    value: "second",
    next: null, // End of the linked list
  },
};

Around a component initialisation, in React, we have code that looks like this:

function render(Component) {
  // global variable that will be mutated by each and every use* call
  global.currentComponentHooks = null;
  // keeps track of the last hook that was mounted
  global.lastMountedHook = null;

  const children = Component();
  // [...]
}

If we try to guess the body of the useState (useEffect would be, somewhat, similar) it should look something like:

function useState(value) {
  // Creates the new entry
  const hook = {
    value: value,
    next: null,
  };
  if (global.currentComponentHooks === null) {
    // If it is the first entry, stores it in the global object
    global.currentComponentHooks = hook;
  } else {
    // Add the current hook to the `next` property
    global.lastMountedHook.next = hook;
  }
  // Keep track that this hook is the last one we mounted
  global.lastMountedHook = hook;
  // [...]
  return [value, updateState]; // finally returns the initial value plus an update function
}

With the component we had earlier this is what the global.currentComponentHooks will look like as lines are executed:

function Component() {
  // null
  const [first, setFirst] = useState("first");
  // {value 'first', next: null}
  const [second, setSecond] = useState("second");
  // {value 'first', next: {value: 'second', next: null}}
  return /*...*/;
}

At update time

Let's imagine something happened on the UI level and setFirst('updated') was called.

I am not going to describe how the setFirst function behaves. Just bear in mind that it is bound to the relevant entry in the linked list and simply mutates the value property. It then triggers a re-rendering on React's side.

At mount time we have stacked our different hooks in a linked list. At update time we are going to traverse our linked list and read each stored value.

On React's side we need to create a pointer that will point to the root of our linked list before we re-render our component.

function update(Component) {
  global.currentHook = global.currentComponentHooks; // {value 'first', next: {value: 'second', next: null}}
  const children = Component();
  // global.currentHook === null
}

It means that the body of the useState function must have changed.

/* note that we do not need the initial value anymore */
function useState(/*value*/) {
  const hook = global.currentHook;
  global.currentHook = hook.next; // we move the pointer to the next hook
  // [...]
  return [hook.value, updateState];
}

And from our component's context this is how the currentHook pointer evolves.

function Component() {
  // {value 'updated', next: {value: 'second', next: null}}
  const [first, setFirst] = useState("first"); // first === 'updated' our mutated state
  // {value 'second', next: null}
  const [second, setSecond] = useState("second"); // second === 'second' the unchanged initial state
  return /*...*/;
}

So... Why can't we condition a hook?

Now that we have seen the internals of how hooks work, let's see what would happen if we conditioned one of them. A (arguably!) valid scenario for conditioning a hook would probably be triggering an effect depending on some props. (Note that, just like useState, useEffect are also added the the linked list of all the hooks of a component)

const Component({doEffect}) {
  const [first, setFirst] = useState(0);
  if (doEffect) {
    useEffect(/*...*/)
  }
  const [second, setSecond] = useState(0);
}

Now let's say that the component will mount with {doEffect: false}. We will end up with that linked list:

{value: 0, next: {value: 0, next: null}}

We only have two elements and the useEffect does not exist in our list.

If ever doEffect switches to true we will now try to access a hook that was not registered

function Component({ doEffect }) {
  // {value: 0, next: {value: 0, next: null}}
  const [first, setFirst] = useState(0);
  if (doEffect) {
    // {value: 0, next: null}
    useEffect(/*...*/); // ⚠️ Wrong hook here
  }
  // null
  const [second, setSecond] = useState(0); // ⚠️ No hook left!!
}

In order to fix this, we just need to move our condition inside the body of the useEffect hook (and not forget to add it in the dependency of the useEffect)

useEffect(() => {
  if (doEffect) {
    // Do your magic
  }
}, [doEffect]);

Conclusion

React Hooks have quite changed how we write React apps. As a React user, I find being able to write only functional components (as opposed to class components) to be very pleasant!

But this comfort comes at a price:

hooks feel like black magic and make the lifecycle of the component hard to grasp (and actually you should probably not think in lifecycles);
we need stricts rules regarding how hooks are called.

I would also add that all those states inside the React codebase make the flow pretty hard to follow and understand. I can not thank enough my debugger for the step-by-step execution. Without it, this article would probably not exist 😅!!

Although the eslint-plugin-react-hooks is almost always included in any React codebase, needing a special eslint rule feels like a somewhat serious design flaw. That being said, and in my humble opinion, this is an acceptable tradeoff though :)

Monitoring: A case study for EventTarget

2021-05-05T00:00:00Z

If you work for a data-driven company chances are you had to implement a tracker at some point.
I often see this step being rushed and written straight into the business code.
A lot of attention is given to having a clean implementation of the feature but little thoughts are given to how the tracking impacts the implementation.

Lately, at Deezer, I have been working on a feature that allows two devices to send messages to each other.
I thought this would be a nice opportunity to document my usual approach to monitoring 🧑‍💻

For this, I set the following contraints:

not a single mention of the tracking mechanism should appear in the business code;
deactivating the tracking feature should be a single-line change.

The business logic

We are going to focus on the method that sends a message to the remote peer. The method sends a message on the connection and waits for the peer to reply with an ack message before resolving the returned Promise.
(The details of how the ack is matched is hidden in the addAckListener method for the sake of simplicity.)

class Connection {
  // ...
  sendMessage(message) {
    const messageId = uuid();
    this.peerConnection.send({ id: uuid(), message });

    return new Promise((resolve, reject) => {
      this.addAckListener(messageId, (error?: number) => {
        return error ? reject(error) : resolve();
      });
    });
  }
}

The metrics we want to monitor are the following:

the number of successful messages;
the number of failed messages;
the time a message needs to do the round trip (between the message being sent and the ack being received).

A naive implementation

Before over-engineering anything I find it useful to start-off with a naive implementation.
It usually helps me clearing up the contraints before extracting them somewhere else.

The first thing that comes to mind is to add the tracking bits directly into the code that actually sends the message... Let's go for it 🤓

class Connection {
  // ...
  sendMessage(message) {
    const messageId = uuid();
    this.peerConnection.send({ id: uuid(), message });
+   const timer = Date.now(); // Keep track of the time the message was sent at

    return new Promise((resolve, reject) => {
      this.addAckListener(messageId, (error?: number) => {
+       const elapsed = Date.now() - timer;
+       trackMetrics('latency', elapsed);
+       if (err) {
+         trackMetrics('message_error', err);
+       } else {
+         trackMetrics('message_success');
+       }
        return error ? reject(error) : resolve();
      });
    });
  }

That is quite a bit of code that pollutes the actual business logic. The responsibility of the sendMessage has been altered. It cannot be described without an "and" in the sentence: It sends messages and tracks metrics.

Pros:

👌 easy to implement (almost a no-brainer)
👌 factorised (monitoring is implemented once and work for every message sent)

Cons:

👎 strong impact on the business logic
👎 not trivial to deactivate (need to comment or condition many lines with the risk of disabling lines of actual business logic)

Moving the tracking logic to the parent

The sendMessage method returns a Promise. This is definitely something we can use!

Along with the value it holds, a Promise also carries around:

the success state of the operation;
the time the operation took to complete (or to fail).

This is exactly the pieces of information we need for our tracker 👌

Let's say the consumer does something like this:

connection
  .sendMessage({ type: "play" /*...*/ })
  .then(() => {
    showSuccess();
  })
  .catch((err) => {
    showError(err);
  });

We could easily plug our tracking mechanism right here:

+const timer = Date.now();
connection
  .sendMessage({ type: "play" /*...*/ })
  .then(() => {
+   trackMetrics('message_success');
    showSuccess();
  })
  .catch((err) => {
+   trackMetrics('message_error', err);
    showError(err);
  })
  .then(() => {
+   const elapsed = Date.now() - timer;
+   trackMetrics('latency', elapsed);
  });

Pros:

👌 easy to implement
👌 non intrusive (the business logic is left untouched)

Cons:

👎 unfactorised (every call to sendMessage need to be modified)
👎 even harder to disable (need to disable all the placed where sendMessage is called)

Extracting the monitoring logic to a separate unit

Our previous version allowed for the pure business logic to be left untouched. This is good. But now it is our view layer that is orchestrating the monitoring.

Maybe we could try to extract this logic somewhere else.

Another property of Promise is that it can be forked.

It is well known that Promise can be chained:

promise.then(doStuff).then(doOtherStuff);

But we often forget that it can also be forked:

promise.then(doStuff);
promise.then(doOtherStuff);

We could use that property to clean our view layer code.

This would be our implementation of our monitoring tool:

function trackMessage(messagePromise) {
  const timer = Date.now();
  messagePromise
    .then(() => {
      trackMetrics("message_success");
    })
    .catch((err) => {
      trackMetrics("message_failed", err);
    })
    .then(() => {
      const elapsed = Date.now() - timer;
      trackMetrics("latency", elapsed);
    });

  return messagePromise;
}

Here we just plug-in some callback to execute after the promise resolve/reject and we return the initial, unmodified, promise.

The TypesScript signature is the following trackMessage(messagePromise: Promise<Payload>): Promise<Payload>.

Now the view layer code looks like this:

-connection.sendMessage({ type: "play" /*...*/ })
+trackMessage(connection.sendMessage({ type: "play" /*...*/ }))
  .then(showSuccess)
  .catch(showError);

Pros:

👌 rather easy to implement
👌 a unit with a well defined responsibility (easy to test)
👌 low impact on the view layer
👌 no impact on the business logic

Cons:

👎 unfactorised (every call to sendMessage need to be wrapped)
👎 hard to disable (every call to sendMessage need to be disabled)

Events to the rescue

What we actually want is something that is completely transversal to our application code. What if we could leave the view layer intact and have very limited impact on the business logic?

Let's do an attempt based on events.

Events are nice for decoupling entirely business and plug-in features (like our tracking).

Let's go back to our Connection class

-class Connection {
+class Connection extends EventTarget {
  //...
  function sendMessage{
    return new Promise((resolve, reject) => {
      const messageId = uuid(); // We generate an id for that message
+     this.dispatchEvent(new CustomEvent('sendmessage', {detail: {id: messageId})));
      peerConnection.send(msg);
      function handleAck({ type, ackId, err }) {
        if (type === "ack" && ackId === messageId) {
+         this.dispatchEvent(new CustomEvent('ackmessage', {detail: {id: messageId, err}}));
          peerConnection.removeMessageListener(handleAck);
          return !err ? resolve() : reject(err);
        }
      }
      peerConnection.addMessageListener(handleAck);
    });
  }
}

Our business code needed a few modifications, that's true, but these are quite generic changes that are unrelated to tracking. You can think of it this way: if you extract this module to an external library, it has no unexpected side effects.

Now we can implement our monitoring module based on the EventTarget contract we just defined (I believe TypeScript will help reading the following):

function monitorConnection(connection: Connection) {
  const timers = new Map<string, number>();

  connection.addEventListener(
    "sendmessage",
    ({ detail }: CustomEvent<{ id: string }>) => {
      timers.set(detail.id, Date.now());
      trackMetrics("latency", Date.now() - timer);
    }
  );

  connection.addEventListener(
    "ackmessage",
    ({ detail }: CustomEvent<{ id: string; err: number }>) => {
      const timer = timers.get(detail.id);
      if (detail.err) {
        trackMetrics("message_error", detail.err);
      } else {
        trackMetrics("message_success", detail.err);
      }
      trackMetrics("latency", Date.now() - timer);
    }
  );
}

Finally we need to plug that code somewhere. This time it is going to be in the glue code that instantiate the Connection.

const connection = new Connection(/*...*/);

+monitorConnection(connection);

//...
connection.sendMessage(message);

Pros:

👌 factorised (all the monitoring logic is in a single place)
👌 a unit with a well defined responsibility (easily testable)
👌 low impact on the business logic
👌 very low impact on the global codebase
👌 trivial to deactivate (can be disabled by commenting/conditioning a single line of the code)

Cons:

👎 slightly harder to implement (the matching of message ids need to be manually done)

Conclusion

Tracking is an excellent use case for EventTarget. It allows for the business code to be very generic and the tracking mechanism to be very distant from your application code.

In general Events are tailored for those kind of scenarios: Having something that work in parallel to something else. The DOM API works this way!
The DOM itself is made to display things but it allows us to hook into events that happen on the presentational layer. With a few addEventListener we can add very complex behaviours on top of the DOM but the DOM never knows about those.

This is the beauty of it, there is a generic contract (eg. 'I will send a click event whenever the user clicks somewhere' or 'I will send a sendmessage event every time a message is being sent') that allows us, web developer, to add behavior on top of it.

Word of caution, though, Events are great but should not be overused. Keep in mind that they can blur the readability of the codebase if used for core behaviours. In those cases coupling is the way to go 🙂

You might not need this

2017-05-30T00:00:00Z

Consider the following beauty:

function compute() {
  //
}

Under the assumption that compute is a pure function (a function which will always return the same value given the same arguments. But not only, see Pure Function on Wikipedia), you can easily deduce an interesting thing from those 3 lines: compute will always return the same value.
compute is, basically, a constant.

In JavaScript, it is very easy to break the purity of a function thus breaking the deduction we made earlier about compute being a constant.

One way to break purity, would be to read some external variable:

function compute() {
  return ext.val // ext is some object defined in a parent scope
}

... And that external variable could be this:

function compute() {
  return this.val
}

We now have a way to change the returned value of compute from outside the function.

const a = {
  val: 1,
  compute: compute
}

a.compute() // 1
a.val = 2
a.compute() // 2 ... so long purity, you will be missed

You might be thinking that, at least, with a method call the bound object is never too far from the call, making it explicit that the returned value depends on that object (maybe?)!
Most of the time, is it true. But it is easy to find a counter example:

const ext = { val: 1 }
// create a function bound to `ext`
const compute = function () { return this.val }.bind(ext)

compute() // 1
ext.val = 2
compute() // 2

The misunderstood `this`

this is probably the most misunderstood concept of the JavaScript language.
People coming from classical Object Oriented Programming languages often mistaken this for an instance of the class the method is in.

A better definition of this in JavaScript would be:

this represents the object which owns the method being called

And, due to the dynamic nature of JavaScript, function ownerships often change at runtime.

Functions are first class citizen in JavaScript, which means you can treat them as any other object: passing them around to functions or returning them.

Due to the asynchronous nature of JavaScript, you actually pass functions around a lot.

fetch("/resource")
  .then(callback) // <- callback is a function

When the functions passed around are actually methods, they lose the binding with their initial object:

const a = {
  callback: function () {
    console.log(this)
  }
}

fetch("/resource")
  .then(a.callback) // <- `this` is undefined

To fix this, you need to manually bind the method to its owning object:

fetch("/resource")
  .then(a.callback.bind(a)) // <- `this` is defined again

this is such a mess for newcomers that TypeScript's documentation has an article dedicated to it.

Functions are about logic, `this` is about state

So we can ask the question: What does this do for us?

Common response:

this allows us to write logic close to our models. After all, this is what OOP is about.

The way I see it:

this allows us to write stateful functions. It's a way to embed some state into a function

In my opinion, functions should be building blocks that take some arguments and return a result depending on those arguments, and only those arguments.
This is what functional programming is about (see Why Functional Programming Matters), and this is where the front-end is heading (Why Learn Functional Programming in JavaScript? (Composing Software), Master the JavaScript Interview: What is Functional Programming?, Ramda, lodash, Redux ...)

The separation of logic and state

Getting rid of this is as easy as replacing every occurrences of this by a new parameter.

function compute() {
  return this.val + 1
}

// becomes

function compute(a) {
  return a.val + 1
}

The second version of compute has some nice benefits:

it is pure (only depends on its inputs)*;
its signature explicitly tells that it depends on some input a.

Of course, to remove this from your functions you will also have to change every function calls. Not the funniest part, I agree.

Getting rid of this might feel a little scary and you might think you will lose powerful features. One nice feature I can think of is "method chaining".

const transformed = "test"
  .replace("t", "")
  .replace("e", "j")
  .toUpperCase()

If you remove this from those methods they become simple functions, and you need to transform that piece of code to:

const transformed = toUpperCase(replace("e", "j", replace("t", "", "test")))

Definitely not as sexy as method chaining, right? And that's where functional programming concepts come handy and Ramda (or Lodash) are very powerful allies.

const R = require("ramda")

const removeT  = R.replace("t", "")
const e2j      = R.replace("e", "j")
const testToJS = R.compose(toUpperCase, e2j, removeT)
//    ^ testToJS is a completly new function created
// from the composition of the removeT, e2j and toUpperCase functions

const transformed = testToJS("test")

Note how this last example has make very nice and clear separation between logic and data. Only the last line is dealing with data (read "state") while all the other lines of code are here to describe logic. The separation of concerns is perfectly respected :)

* not using this inside your functions doesn't imply that they are pure at all. You still need to avoid any side effect in order to achieve purity.

Conclusion

Taking away this from your developer's life is a great opportunity for you to leverage the full power of functions and finally start diving into functional programming.

In the process, you will learn how to write very simple functions and compose them together to create fully functional user interfaces.

I personally don't like this and try to avoid it as much as I can.
But, don't get me wrong, this is not evil and most JavaScript developers know how to deal with it.
Sometime you don't really have the luxury of being able to choose to use it or not. If you use React, for example, any stateful component you will write will have to use this (which make sense when you have in mind that this is about state).

That being said, removing this will allow you to:

make your function signatures more explicit;
isolate your state and models from your logic;
avoid any unexpected behavior due to the misunderstanding of the this concept.

Also, it's seems like a perfect excuse to finally learn to love functions and to dive into functional programming :)

Cycle.js, RxJS and cold observables

2016-05-05T00:00:00Z

Lately, I fell into a pretty tough RxJS beginner trap while playing around with Cycle.js.

Here is the situation I was in:

a parent component that creates a child component depending on a data stream;
a child component that outputs an action$ stream that is used in the parent component (depending on DOM events).

And the symptoms:

the child component renders perfectly;
I get the expected output if I subscribe to the action$ stream from inside the child component;
the action$ stream does not output anything from the parent component.

The reason for that weird behavior: the way cold observables work (and, of course, the fact that I didn't took the time to read and understand the RxJS doc ... :( )

NB: As I am writing this article, Cycle.js is being generalized to work with any stream library (see Cycle.js Diversity) and a stream library, specially designed for Cycle.js, is currently being built: xstream. As xtream will be hot-observable-only, this article won't be relevant any more :)

TLDR

Keep in mind that :

cold observables replay the complete observable chain for each subscriber;
before diving into Cycle.js be sure you know and understand all the different types of observables;
just read this introduction to observables;
also, have a look at this great introduction to reactive programming

The situation

Ok let's go a little deeper into my newbie-trap.

Here is a simplified version of the situation I had.

The child component:

function UserContainer({DOM, user$}) {
    const logAction$ = DOM
        .select(".log")
        .events("click")
        .map(() => "log");

    //this prints an output each time the button is clicked
    logAction$.subscribe(/*log*/);

    return {
        //the DOM output of the component
        DOM: user$.map((user) => div([
            span(".user-name", user.name),
            button(".log", "Log")
        ])),

        //the 'log' stream that is used in the parent
        logAction$: logAction$
    };
}

The main function that creates the child component:

function main({DOM}) {
    const user$ = Observable.just({name: "felix"});

    //we map the user stream to an 'instance' of a UserContainer
    const userContainer$ = user$
      .map(user =>
          //from @cycle/isolate https://github.com/cyclejs/isolate
          isolate(UserContainer)({ DOM, user$: Observable.just(user) })
      )

    //keep a trace of the DOM evolution for the UserContainer component
    const userContainerDOM$ = userContainer$
      .map(container => container.DOM);

    //keep a link to the log action of the UserContainer
    const userContainerLogAction$ = userContainer$
      .flatMapLatest(container => container.logAction$);

    /*
     * /!\ here is the problem, this will never print anything
     * when the button is clicked !!
     */
    userContainerLogAction$.subscribe(/*log*/);

    return {
        DOM: userContainerDOM$
    };
}

If you want to play with it, here is a jsbin I created to reproduce the bug

To summary the symptoms I had:

I had no trouble receiving click events if I subscribe from inside the child component namely UserContainer;
for some reason I could receive any click events from the function where I build the UserContainer component.

The ridiculously simple solution

So – without any more suspense – here is the ridiculously simple solution:

const userContainer$ = user$
  .map(user =>
      //from @cycle/isolate https://github.com/cyclejs/isolate
      isolate(UserContainer)({ DOM, user$: Observable.just(user) })
  )
+ .shareReplay(1)

Explanation

Fixing a bug is a good thing, understanding it is a lot more valuable ;) So here is the explanation for that bug.

The main reason for that behavior is: the way cold observable work in RxJS. In fact a cold observable replays the whole observable sequence for each subscriber it has.

const values$ = Observable
    .just("test") //this is a cold observable
    .do(() => console.log("here I am"))
    .map(() =>
        /* /!\ just for the exemple.
         * always avoid doing non deterministic
         * calls in your app's code
         */
        Math.floor(Math.random() * 10)
    );

value$.subscribe((value) => console.log("first sub: " + value));
value$.subscribe((value) => console.log("second sub: " + value));

/* output:
 * Here I am
 * first sub: 7
 * Here I am
 * second sub: 5
 */

As you can the, the log Here I am is printed twice and the first subscriber doesn't get the same value as the second subscriber (resp 7 and 5).

I my case I have that piece of code that is building the UserContainer component:

const userContainer$ = user$
    .map(user =>
        isolate(UserContainer)({DOM, user$: Observable.just(user)})
    )

And two streams that originate from the userContainer$ stream:

const userContainerDOM$ = userContainer$
    .map(container => container.DOM);

const userContainerLogAction$ = userContainer$
    .flatMapLatest(container => container.logAction$);

So that means:

when userContainerDOM$ is subscribed it creates a new UserContainer component (from the userContainer$);
when userContainerLogAction$ is subscribed it creates a new UserContainer component (from the userContainer$);

Which means that each stream has access to a different "instance" of UserContainer and that the log action we retrieve does not come from the same component as the DOM.
In other words: we subscribe to events of a component that is not displayed on screen and, as such, does not receive any DOM event**.
**this last statement is only true because the UserContainer is isolated (see @cycle/isolate)

Now the shareReplay(1) solution transforms the observable into a hot observable. This means the whole subscription sequence will only be executed once per value produced by the stream user$. We also keep the last produced value for further subscriber to get that value when they subscribe.
Which means that now, we are only creating a single UserContainer per value produced by the user$ stream and that all the underlying subscribers will work on the same "instance" of that UserContainer.

Conclusion

Cycle.js beginners need to overcome a pretty huge obstacle before embracing the power of Cycle.js: RxJS. Don't get me wrong, RxJS is a great library it's just not perfectly suited for the idea behind Cycle.js.

There is very little to learn about Cycle.js, it is more of an idea more than a complete library/framework. Once you get the idea behind Cycle.js (which is pretty easy) what you have to learn is RxJS. Be sure you know the different operators (at least those inside rx.lite.js) and, most importantly, be sure that you understand what are observables by reading this introduction to observables.

One last thing, don't hesitate to ask questions on the Cycle.js's gitter chan ;)

Quelques questions courantes avec Flux

2015-11-08T00:00:00Z

Lors de ma découverte de Flux, je me suis posé un certain nombre de questions. Je voudrais vous les exposer ici, pas simplement parce que vous risquez de vous les poser mais surtout parce que les réponses mettent en valeur les principes de Flux.

Où faire mes requêtes AJAX ?

Réponse courte : dans les créateurs d'actions.

Explication : On pourrait penser que les stores sont responsables des requêtes AJAX, seulement la doc de Flux nous dit que les stores doivent être synchrones. Donc à partir de là on devrait accepter que l'AJAX ne se fait pas dans les stores, mais allons un peu plus loin pour en être complétement convaincu.

On va raisoner par l'absurde pour répondre à cette question. Flux nous dit que les stores représentent un état de l'application à l'instant t. Si on garde en tête qu'un changement d'état de votre application est en réalité une fonction qui prend en paramètres l'état t et une action. Admettons donc qu'une action déclenche une requête AJAX dans l'un de vos stores. Au moment du dispatch de l'action, les données du store sont dans un certain état et changent une fois la requête terminée. Or il n'y a pas eu de nouvelle action déclenchée au moment du retour de la requête donc votre application n'a pas changée d'état alors que les données de votre store si. Ce qui veut dire que à l'instant t de l'application votre store peut être dans deux états différents, ce qui est incohérent avec le postulat de base.

Comment nommer mes actions ?

Réponse courte : il faut se poser la question « Que vient-il de se passer sur mon application ? »

Explication : Il faut voire les actions comme des éléments stupides. elles sont là pour informer de ce qu'il se passe et, en aucun cas, décider de ce qu'il faut faire quand quelque chose se produit. Il faut considérer qu'elles ne connaissent rien de l'application dans laquelle elles évoluent et n'ont aucune idée de ce qu'il va se passer quand elle vont émettre un évènement.

Les actions doivent donc pas ressembler à SHOW_TODOS mais plutôt TODOS_RECEIVED. De manière générale construire ses noms d'actions au passé aide ;)

Comment choisir entre un composant statefull ou un nouveau store ?

La réponse par défaut est : faites un store. Selon mon opinion, le seul cas de figure ou un composant statefull est envisageable serait pour un composant très gérénique qui n'a aucune logique métier liée à votre application et que vous pouriez utiliser sur un projet qui n'a rien à voir.

Par exemple, si vous faites un date picker générique, à mon sens il est plutôt conseillé de faire un composant statefull. En revanche le composant métier qui utilisera votre date picker devra avoir son store.

Le point faible de cette réponse est qu'elle rentre en contradiction avec la réponse à la première question. A l'ouverture de votre date picker l'état change visuellement sans qu'il y ai eu changement d'état de l'application.
On peut répondre à ça que ça n'est pas un changement d'état de l'application puisque les objets métier n'ont pas changés. Au même titre qu'on ne stocke pas dans un store l'état du scroll du user ou encore la position de sa souris.

À vous

Bref voila les quelques questions qui m'ont fait réfléchir en me penchant sur Flux. J'espère qu'elles vous seront utiles et qu'elles vous permettrons de mieux penser en Flux.
N'hésitez pas à partager les questions qui vont ont fait cogiter et à rebondir sur les réponses que j'apporte ici.

A bon entendeur ;)

Le guide que j'aurais aimé avoir quand j'ai commencé Flux

2015-10-19T00:00:00Z

En commençant Flux, j'avoue avoir eu beaucoup de moments de confusion et questions inutiles qui me sont venus à l'esprit. La majorité des questions que je me posais venaient de la confusion qu'il est facile de faire entre la présentation de Flux et le Github de Flux.

Je vous propose donc de revenir un peu sur la source de ma confusion puis de reprendre, avec les idées au clair, les concepts de Flux emsemble.

Pourquoi j'ai été confus par Flux

La majeure partie de ma confusion venait du fait que je n'avais pas bien compris de quoi la doc traitait.
Le souci c'est qu'une partie de la doc parle du concept de Flux en montrant des exemple de code (c'est le cas du sempiternel exemple de la TODO list) alors que d'autres parties de la doc parlent de l'implémentation que Facebook utilise et dont on trouve le code sur Github.

Je n'arrivais pas à voir que Flux n'était pas un framework ni une librairie mais juste un concept. Aussi je prenais la doc comme si c'était la documentation de leur implémentation de Flux, or pas uniquement. Seulement, quand vous lisez cette doc dans cet état d'esprit, vous voyez des incohérences partout et vous finissez par vous enerver.

Du coup, pour lire la suite de cet article mettez vous bien en tête que :

Flux n'est pas du code mais un concept ;
les exemples de code ici n'utilisent aucune implémentation de Flux particulière.

Sachez qu'il existe un grand nombre d'implémentations de Flux qui se baladent avec de solides documentations. Je vous invite à consulter ce site qui vous montrera un peu les tendances d'utilisation des différentes implémentations : Which Flux implementation should I use?.

le problème que résout Flux

Dans le modèle MVC classique, vous avez votre modèle (les données brutes) vos contrôleurs (qui passent les données aux vues et qui récupèrent les actions des vues pour mettre à jour le modèle) et vos vues (qui s'occupent simplement d'afficher les donnés calculées dans un template et d'envoyer des évènements aux contrôleurs). Le souci de ce schéma est que vos contrôleurs font beaucoup trop de choses dans votre application. Les vrais problèmes commencent à apparaitre quand vous commencez à avoir un contrôleur qui gère un type de données et plusieurs vues qui affichent cette même donnée.

La petite histoire que raconte Facebook pour expliquer le problème que résout Flux parle du chat.
La première version n'est qu'un petit panel en bas de page, c'est tout. À ce moment là, c'est simplement un petit composant MVC et dispose de son contrôleur. Ce contrôleur s'occupe de recevoir les messages et récupère les évènements du panel pour envoyer les messages. Si on devait écrire, de façon très synthétique, la méthode de contrôleur qui gère les nouveaux messages on aurait sûrement quelque chose comme ça :

function onMessage(message) {
    var chatPanel = getChatPanel(message.thread);
    chatPanel.append(message);
}

Puis est arrivé le bandeau de notification en topbar de Facebook, celle-ci indique (entre autres) le nombre de messages non lus dans le chat. Le code du contrôleur se complexifie alors un peu pour devenir.

function onMessage(message) {
    var chatPanel = getChatPanel(message.thread);
    chatPanel.append(message);
    chatNotif.increase(1);

    if (chatPanel.hasFocus()) {
        //si le chat a le focus, on peut décrémenter la notif
        chatNotif.decrease(1);
    }
}

Enfin est arrivé la page de chat dédiée, sur laquelle les deux précédents composants peuvent bien sûr être présents. Notre nouveau code ressemble maintenant à :

function onMessage(message) {
    var chatPanel = getChatPanel(message.thread);
    chatPanel.append(message);
    chatNotif.increase(1);
    if (chatPage.currentThread === message.thread) {
        //si la page de chat est ouverte sur la conversation
        //on ajoute le message
        chatPage.append(message);
    }

    if (chatPanel.hasFocus() || chatPage.currentThread === message.thread) {
        chatNotif.decrease(1);
    }
}

Bon je pense que vous voyez l'idée, plus on rajoute de vues associées à ces données, plus on va rendre nos contrôleurs complexes. Ce qui veut dire un code plus dur à maintenir et à comprendre.
Notez que vous avez aussi à traiter tous les événements qui peuvent être liés à cette messagerie (focus sur chacune des vues et quand l'utilisateur répond par exemple).

Le problème de fond est : le contrôleur est responsable de beaucoup trop de choses

Flux répond à ça en deux points assez simples :

un flux d'actions unidirectionnel ;
la fin de la séparation des vues et contrôleurs au profit de controller-views responsables de transformer les données qu'ils affichent.

Flux

La principale idée de flux est de faire passer le moindre évènement de votre application au travers d'une boucle qui va parcourir tous vos stores (les éléments qui contiennent les données de votre application, nous reviendrons dessus juste après).
Si vous allez voire le code de Flux vous vous rendrez compte qu'il ne se compose en fait que d'un dispatcher (et de quelques helpers). Car en réalité Flux n'est pas du code mais plutôt une nouvelle façon de penser son code.

Avec Flux votre codebase va se décomposer de la façon suivante :

des stores qui sont l'endroit où votre modèle va être contenu ;
des actions qui représente toutes les choses que votre appli peut faire ;
un (et un seul) dispatcher qui notifie les stores des actions effectuées ;
des controller-views qui vont transformer et afficher les données qu'on leur donne.

Les stores

C'est ici que tout vos modèles vont vivre. Les stores sont en fait une représentation complète de l'état, à un instant t, de votre application. Il ne doit y avoir aucun de vos modèles qui vit en dehors d'un store.
Si vous vous pliez à cette règle, il vous suffira de faire une sauvegarde des données de vos stores et la recharger plus tard pour pouvoir retrouver l'application dans l'état exact dans laquelle vous l'aviez laissée.

Les stores se comportent comme un modèle observable (il dispose de getters et d'une méthode addListener) à la différence près qu'il n'a pas de setter. Et cela nous mène à une autre idée très importante dans Flux : seul le store peut mettre à jour ses propres données

À ce stade vous vous demandez donc normalement comment faire pour pouvoir changer l'état de l'application si on a aucun setter dans notre entité qui contient tous les modèles de l'application. C'est à ce moment là que le dispatcher entre en jeux.

Le dispatcher

Le dispatcher est là pour faire transiter absolument tout ce qu'il se passe sur l'application par vos stores. Quand je parle de tout ce qui se passe, je parle bien sûr des évènements. Les évènements c'est par exemple :

« l'utilisateur a cliqué sur le bouton de suppression »
« l'utilisateur a soumit tel formulaire »
mais aussi « le serveur a envoyé telle donnée »
ou encore « le serveur a indiqué que les identifiants de connexion sont faux ».

Bref, quand je dis tout ce qu'il se passe, c'est tout.

Dans le bootstrap de votre application tous vos stores devront donc être enregistrés auprès de ce dispatcher unique qui les préviendra alors dès qu'il se passe quelque chose sur l'applications.
Le dispatcher est là pour crier bêtement à tous les stores « hey les gars il s'est passé ceci, faites en ce que vous en voulez ». Son rôle s'arrête là.

Par la suite, vos stores eux choisissent de réagir, ou non, aux évènements qu'ils reçoivent. Pour ça, votre store va donner un callback à votre dispatcher qui sera appelé à chaque évènement. Souvent ce callback sera composé d'un switch qui va traiter uniquement les cas qui l’intéresse.

Allez, un peu de concret avec un petit bout de code pour illustrer tout ça. Imaginons un store qui garde bien au chaud en mémoire une liste de ... TODOS (et merde, je m'étais juré que je ne prendrais pas cet exemple … :/ )

On dispose d'un côté d'une liste d'évènements sous forme de constantes

var events = {
    //quand l'application reçoit une liste de todos du serveur (ou d'ailleurs)
    RECEIVED_TODOS: "RECEIVED_TODOS",

    //quand l'utilisateur ajoute un nouveau todo
    TODO_ADDED: "TODO_ADDED",

    //quand les todos ont été sauvegardés sur le serveur
    TODOS_SAVED: "TODOS_SAVED"
    //[...] plein d'autres évènements que nous ne traiterons pas ici
};

module.exports = events;

et de notre store qui gère les todos :

//l'instance unique de notre dispatcher de l'application
var appDispatcher = require("../dispatcher/appDispatcher"),
    //les évènements définis précédemment
    events = require("./events");

//nos todos. inaccessibles depuis l'extérieur et vide pour le moment
//c'est une action qui viendra remplir tout ça
var todos = [];

var TodosStore = {
    //l'unique méthode accessible depuis l'extérieur
    //qui nous retourne simplement les todos
    get: function () {
        return todos;
    }

    //ps il faut rajouter ici les méthodes d'ajout/suppresion
    //d'event listeners (addListener/removeListener)
    //qui serviront pour prévenir les vues que quelque chose
    //a changé
});

//c'est ici que la magie s’opère. On enregistre un callback qui sera appelé dès que quelque chose se passe
appDispatcher.register(function (payload) {
    //dans le payload on a tous les détails de l'évènement (type et données qui va avec)
    var action = payload.actionType,
        data = payload.data;

    //on répond uniquement aux évènements qui nous intéressent
    switch (action) {
        //quand on reçoit les todos, on remplace simplement nos todos
        //par les todos reçus
        case events.RECEIVED_TODOS:
            todos = data.todos;
            this.emitChange(); //stay tuned, on parle de ça bientôt
            break;

        //quand un todo est créé sur le serveur on l'ajoute dans notre 
        //liste de todos
        case events.TODO_ADDED:
            todos.push(data.todo); //on ajoute la nouvelle todo dans la liste
            this.emitChange(); //stay tuned, on parle de ça bientôt
            break;

        //par défaut, on ne fait rien
        //vous noterez par exemple qu'on ne répond pas ici 
        //à l'évènement TODOS_SAVED car il n'aurait aucune influence
        //sur les données brute de ce store
        default:
            break;
    }
}.bind(todosStore));

module.exports = todosStore;

Ça y est nous avons de quoi stocker nos données dans l'application mais rien ni pour les afficher ni pour les remplir. Je vous propose donc de parler des vues avant de finir sur les actions.

Les vues

Allez maintenant qu'on sait comment stocker nos données, voyons un peu comment les afficher. Pour ça, on va utiliser les controller-views.
L'idée principale du controller-view est de regrouper ensemble le contrôleur et sa vue associée. Ainsi on se débarrasse d'une partie du problème qu'introduit Facebook avec son chat : le contrôleur responsable de beaucoup de vues.
Facebook distingue tout de même deux type de vues différentes dans Flux : les views simples et les containers.

Dans la suite de ce paragraphe, je vais considérer qu'on utilise React pour faire nos vues, et que vous avez une connaissance des concepts de base de React. Sachez que rien ne vous oblige à utiliser React pour vos vues.

les containers

Les containers sont des controller-views un peu spéciaux : ils écoutent les changements d'un store.
L'idée du container est de centraliser les données relatives à une partie de votre application à un seul endroit. Le container passera ensuite ces données à ses enfants pour affichage.
Pour reprendre le cas de notre application de TODOS on va avoir envie d'avoir un container qui à accès à l'utilisateur loggé et un autre qui s'occupe des TODOS. Ils écouteront respectivement les userStore et todosStore.

Vous l’aviez peut-être vu dans le callback passé au dispatcher dans mon exemple précédent, on voit le todosStore appeler la méthode emitChange. En réalité, c’est cette méthode qui va permettre aux stores de prévenir les vues que des choses ont changées chez eux. Aussi quand vous créez un nouveau container, vous devez enregistrer un callback auprès des stores dont il dépend (et ne pas oublier de le détruire quand le composant est détruit). Avec React on fait ça dans le componentWillMount ce qui nous donne

React.createClass({
    //...
    componentWillMount: function () {
         // à la création du composant, on enregistre le listener
         userStore.addListener(this.onChange);
    },

    componentWillUnmount: function () {
         // à la suppression du composant, on retire le listener
        userStore.removeListener(this.onChange);
    },

    //ce callback est appelé à chaque fois que le userStore change
    onChange: function () {
        this.setState({
            user: userStore.get()
        });
    },

    render: function () {
        //on a ici la dernière valeur du user
        return (<App user={this.state.user}/>);
    }
});

Comme son nom l'indique, le container ne fait que contenir des données. Et, à ce titre, comme vous pouvez le voir dans le code précédent, la méthode render est la plus simple possible. Elle délègue simplement le rendu à un composant de vue … Et c’est tout !

Ainsi, vos container ne sont responsables que d'une seule chose : mettre à jour les données pour tout le reste des composants. On respecte bien le fameux Single Responsability Principle et le débug ne s'en porte que mieux.

Les controller-views

Les controller-views ne sont là que pour transformer vos données brutes et les afficher comme vous le voulez. Il reçoivent donc toutes leurs données via des propriétés et sont censés être complètement stateless.
On retrouve, avec les vues, un concept propre à la programmation fonctionnelle : une fonction retournera toujours le même résultat si on lui donne les mêmes paramètres. On appelle ça les fonctions pures.
D'ailleurs avec la nouvelle syntaxe de composant que React v0.14 a introduit récemment, vous pouvez déclarer un composant comme étant une simple fonction qui prend en paramètre des props et retourne du JSX. Avec cette syntaxe, pas de state et on est alors obligé de faire un composant stateless.

Pour reprendre notre application de TODOS qu'on a commencé plus tôt, voila à quoi pourrait ressembler notre composant App :

var App = function (props) {
    var user = props.user;
    return (
        <div className="header">
            <span>{user.firstname}</span>
            <span>{user.lastname}</span>
            <LogoutButton user={user} />
        </div>
        <TodoContainer />
    );
}

Note : les composant-fonctions sont les composants les plus simples qu'on puisse trouver. Pas d'event handler dedans, de mixin ni de réécriture de méthode du cycle de vie du composant (comme componentWillMount par exemple). Ne vous sentez donc pas obligé de n'utiliser que des composant-fonctions. Utilisez les dès que vous pouvez.

Les actions

Ok si on récapitule on a donc les vues qui récupèrent leurs données depuis les stores qui eux modifient leurs données selon les informations du dispatcher, la question qui réside est : qui donc fait appel au dispatcher ? La réponse est, bien sûr, les actions.

C'est dans les actions que la magie opère. C'est elles qui sont à l'origine de tout ce qui peut changer l'état de l'application (ajout/suppression/édition d'un TODO, récupérations des TODOs sur le serveur ...).
Les actions sont donc les éléments qui vont utiliser le dispatcher pour lancer des évènements que les stores vont interpréter.

Le code des actions est souvent très simple. Je vais distinguer deux types d'actions :

les actions qui n'ont d'effets que sur les données locales qui sont souvent synchrones ;
les actions qui ont un effets sur des données externes (typiquement qui viennent d'une API) qui sont souvent asynchrones.

Le premier type d'action est vraiment très simple, il ne fait qu'appeler le dispatcher un point c'est tout.
Considérons ce scénario d'ajout de TODO :

l'utilisateur édite son TODO tout frais ;
quand il a fini, il ajoute son TODO dans la liste ;
il peut en ajouter plein d'autres ;
une fois qu'il est content de sa liste de TODOs il peut la sauvegarder sur le serveur.

Dans ce scénario, il y a les deux type d'actions dont je vous ai parlé.

addTodo qui ajoute en local un nouveau TODO ;
saveTodos qui prend tous les nouveaux TODOs et les sauvegarde via une requête AJAX sur le serveur.

si on voulait implémenter ces deux actions, ça nous donnerait quelque chose comme ça :

var todoActions = {
    addTodo: function (todo) {
        //"Bon allez ça ça part chez les stores qui savent quoi faire de ce truc"
        dispatcher.dispatch({
            actionType: "TODO_ADDED",
            todo: todo
        });
        //my job here is done
    },

    saveTodos: function (todos) {
        //"OK j'envoie ça au serveur et ensuite je file ça aux stores
        api
            .saveTodos(todos)
            .success(function (response) {
                //OK c'est bon les enfants
                dispatcher.dispatch({
                    actionType: "TODOS_SAVED",
                    todos: response.todos
                });
            })
            .catch(function (response) {
                //oh merde les gars ça a pas marché
                dispatcher.dispatch({
                    actionType: "TODOS_SAVE_FAILED",
                    todos: todos
                });
            });
    }
}

Notez que les évènements dispatchés par les actions décrivent des choses qui se sont passées et pas ce que doit faire l'application par rapport à cette action. Pour illustrer mon propos voila un exemple qu'on pourrait être tenté de faire.
Prenons le cas où la sauvegarde sur le serveur s'est mal passée (donc on passe dans le catch), on pourrait avoir envie de dispatcher un "SHOW_NOTIFICATION_TODOS_SAVE_FAIL". En faisant ça, on donne à l'action une connaissance de ce que l'application peut faire.
Or une action ne doit faire que constater ce qu'il se passe et le transmettre.

Flux en résumé

Pour résumer un peu voila les idées qui sortent de Flux :

les stores contiennent toutes les données brutes de l'app ;
les stores représentent l'état de l'application à l'instant t et sont donc complètement synchrone ;
seuls les stores peuvent modifier leurs données ;
les stores réagissent aux évènements du dispatcher ;
les stores sont comme un modèle observable mais sans setter ;
les vues écoutent les changements d'un (ou plusieurs) store(s) et se rendent en fonction ;
une vue qui est reliée à un store est appelée "container" et doit avoir une méthode render simplissime ;
le dispatcher est les yeux des stores vis à vis de l'application (il dit au stores tout ce qu'il se passe) ;
les actions sont là pour appeler le dispatcher et éventuellement des services externes (API, localStorage ...) ;
pour nommer un évènement que doit dispatcher une action il faut se poser la question « Que vient-il de se passer dans mon application ? » et pas « Que devrait faire mon application face à ça ? »

Et le petit graphique qui résume très bien les interactions entre les composants :

(ps: Pourquoi ce schéma n'apparait que sur le github et nulle part sur la doc alors qu'il résume bien mieux Flux que les schéma qu'on peut trouver ici)

On pourrait représenter une application Flux comme une fonction qui prend en paramètre un état à un instant t et une action et qui retourne l'état à l'état t+1 :

application(state1, action) => state2

Si on considère que cette fonction est pure (qu'elle ne fait que retourner un nouvel état sans rien modifier en mémoire pour faire simple), alors tous les états de cette application sont déterministes (une même action ne pourra pas donner deux résultats différents) et vous pouvez par exemple facilement mettre en oeuvre du undo/redo (la doc de Redux explique ça très bien).

Conclusion

Je trouve l'idée qu'a eu Facebook d'implémenter le concept de Flux entièrement dans sa doc très bonne. C'est un peu comme ces articles qui réimplémente une techno populaire (eg. Make your own Angular) pour l'expliquer. C'est très didactique et permet de vraiment comprendre ce qu'il se passe sous la capuche (comme disent les américains) des outils qu'on utilise tous les jours (ou presque).
En revanche je trouve dommage qu'ils n'aient pas plus séparé le concept et l'implémentation dans leur doc. Je reconnais avec le recul que j'aurais pu comprendre ça plus tôt. Je suis surement parti trop vite dans le code sans lire à fond le concept d'abord, mais je pense que je ne suis pas le seul à avoir pris ce chemin.

Outre ça, le concept de Flux est génial et a vraiment changé ma façon de faire mes applications.
Alors si je peux vous donner un conseil, c'est trouvez vous une implémentation de Flux qui vous va (ou faites la vous même) et lancez vous :)

Hackerbeach : Organiser mon temps

2015-01-18T00:00:00Z

Comme expliqué dans mon précédent billet (Hackerbeach : Coder sur la plage ... en hiver), je suis parti pour (presque) tout le mois de janvier en Dominique pour y travailler.
Ce n'est pas vraiment le genre d’environnement de travail auquel je suis habitué et ça serait dommage de ne pas profiter de ce cadre de rêve !
La question est donc : comment m'organiser pour, à la fois, profiter à fond de la Dominique tout en bossant efficacement ?

Vivre avec le soleil

Voila ce que j'ai en tête pour la gestion de mon temps : ne perdre aucune minute de la journée. Pour arriver à ça il va falloir se synchroniser avec le soleil. Ce qui veut dire lever 6h15. Ca me permettra comme ça de pouvoir me libérer une bonne partie de la journée pour visiter, nager, marcher ...
N'étant pas vraiment un lève tôt, je vous avoue que ça ne me parait pas facile à tenir. Cela dit, après 4 jours de travail ici, je trouve le réveil avec le soleil vraiment facile. Voyons si j'arrive à tenir ce rythme...

Travailler n'importe où

Quitte à partir là bas, je compte bien sortir complètement de mes habitudes vélo / boulot / dodo. Et ça, ça commence par ne pas savoir où je vais bosser en me levant.
Pas de bureaux ici, nous sommes en itinérance complète. L'idée c'est vraiment de bouger le plus possible : voir plein de lieux, essayer de bosser dans des restaurants ou des bars.
Nous avons une connexion dans notre appartement et, si nous pouvons nous autoriser quelques demi journées de travail à domicile, il est hors de question de faire des journées entières sans bouger !

Les autres gars de Hackerbeach vivent dans une ville voisine à la notre (à 3 ou 4 km pas plus) aussi, comme bon hacker qui se respecte, on se synchronise via IRC (#hackerbeach sur freenode si vous voulez suivre nos pérégrinations ;)). Aller les rejoindre est une motivation supplémentaire pour sortir de chez nous !

Travailler n'importe quand

Si me lever tôt fait partie de mes plans, rien ne dit que je vais nécessairement bosser dès le matin. Rien ne m'empêche de faire un petit bain de mer au réveil puis retour au boulot puis petit restaurant dans la ville, coder quelques heures dans un bar, prendre un pot avec l'équipe, reprendre mon boulot arrivé chez moi.

Dans une journée j'ai des périodes hyper productives qu'il ne faut surtout pas que je casse et des périodes où je me sens complètement inutile face à mon code. Si je suis dans une phase de créativité intensive, je sais parfaitement que je ne voudrai pas en sortir, quitte à annuler une activité que j'avais prévue. En revanche sur les phases de travail inefficaces une petite heure dans l'eau et c'est reparti !

J'aime mon boulot et faire avancer DoYouBuzz me tient beaucoup à coeur, aussi je n'ai aucune crainte quant à une éventuelle perte de motivation. Je suis, avant tout, là pour bosser !

Sortir de sa zone de confort

Je veux dire, déjà cette organisation me change complètement de mon cadre de travail habituel, mais travailler en itinérance pousse encore l'expérience un peu plus loin.
Pour vous faire un petit topo de mon installation habituelle : Dual screen (15" et 20"), souris + clavier, un bureau et un fauteuil inclinable.
Evidemment, j'ai du dire au revoir à tout ce confort. Fini le débuggeur sur un écran et le code sur l'autre en plein écran.
J'ai troqué mon MacBook 15" pour mon portable perso de 13". Je vais donc devoir m'habituer à splitter un peu mon écran et à réorganiser mon workflow de travail.

Pour tout vous dire j'avais déjà commencé à travailler comme ça la semaine avant mon départ. Je me suis forcé à ne pas allumer mon deuxième écran et à utiliser mon 13" pour le boulot. Et il s'avère que finalement, mon deuxième écran ne me manque pas tant que ça !

Pour ce qui est du confort global, c'est pareil, c'est très fluctuant. On va aussi bien pouvoir se trouver dans des fauteuils agréables dans un bar comme sur des simples chaises en bois. Je pense me mettre à travailler un peu debout de temps en temps pour alterner.

Jusque là, je n'ai pas vraiment expérimenté de gros soucis avec la connexion internet. Elle est clairement beaucoup moins bonne qu'en France mais tout à fait suffisante pour ce que je fais. Il arrive qu'un git pull avec de nouvelles images puisse prendre un peu de temps, mais le temps de commander un jus de fruit de la passion est c'est bon :)

You are awesome

Il y a plusieurs choses qui ont rendue l'aventure possible. Je partais complètement à l'aventure en venant en Dominique. Je ne savais pas vraiment comment j'allais pouvoir bosser là bas. Mais j'ai la chance d'avoir une copine en or qui ne m'a jamais freiné dans mon projet, des potes qui étaient motivés pour partir avec moi et surtout une boite qui m'a entièrement soutenue dans mon aventure.

Depuis le Reboot DoYouBuzz, on avait déjà commencé à travailler un peu de chez nous et à des heures un peu décalées. Mais il est vrai qu'on préfère, bien souvent, être tous ensembles à déconner que chez nous ou dans un bar. C'est donc la première vraie aventure dans notre histoire d'entreprise libérée et, franchement, je suis vraiment excité à l'idée d'y participer :) Si l'informatique permet ce genre d'extravagance, je ne pense pas que beaucoup de gens ont l'opportunité de se lancer dans ce genre de projets !

En bref je remercie tous ceux qui m'ont permis de réaliser ça !

Je vous fait un petit débrief de toute cette aventure une fois rentré en France :)

Hackerbeach : Coder sur la plage ... en hiver

2015-01-14T00:00:00Z

Nous sommes en Octobre, j'avais déjà entendu parler de Hackerbeach par @XioNoXfr (qui avait déjà fait l'édition 2014 et qui était motivé pour la 2015) et là je tombe sur ce tweet :

It's official now: Hacker Beach is going to Dominica!
— Hacker Beach (@hackerbeach) 9 Octobre 2014

Ni une ni deux je parle un peu de ça autour de moi, et notamment à @GildasQ qui n'hésite pas une seule seconde et me dit : Banco on y va !

Bref nous voilà donc tous les trois partis dans les Caraïbes pour l'édition 2015 de Hackerbeach.

Cette démarche s'inscrivait aussi parfaitement dans le reboot de DoYouBuzz qu'on a fait récemment (cf. DoYouBuzz Reboot). Aussi, quand j'ai parlé aux gars de l'idée de partir là bas, ils trouvaient le concept génial. C'est un bon moyen de mettre à l'épreuve notre capacité à travailler en remote et à valider notre modèle d'entreprise libérée :)

Cet article a pour but de présenter brièvement l'idée derrière Hackerbeach et mes impressions sur l'île jusque là. Je ferai, par la suite, un article qui parlera plus de mon organisation personnelle vis à vis de mon travail / rythme de vie.

Hackerbeach qu'est ce que ça ?

L'initiative

Hackerbeach c'est une bande de potes qui se sont dit, il y a trois ans : "bordel, pourquoi on s'oblige à bosser en Europe en hiver par 0°C alors qu'on pourrait bosser en sirotant des cocktails sur des plages paradisiaques ?".
Quand on sais que pour bosser on a juste besoin d'un portable et d'une connexion internet décente, la question est tout à fait légitime !
Sur ce principe là, ils se sont mis en quête d'endroits rêvés pour exercer leur art.

L'édition 2013 était à Phu Quoc (une île au large du Vietnam) ;
L'édition 2014 à Lamu (une île au Kenya) ;
et cette année : en Dominique.

Ils ont rendu l'évènement public et chacun est libre de venir les rejoindre pour passer du bon temps entre hackers tout en ayant une vraie ambiance de taf.
Après trois jours de boulot avec eux, je peux vous dire que ces mecs sont des bosseurs. Dès qu'ils ont 5 min et une connexion à proximité, ils dégainent leurs ordi pour descendre du bug ou juste avancer un petit bout de code en suspens.

L'édition 2015

Cette année on est 11 sur l'île (mais je n'ai pas encore eu l’occasion de les rencontrer tous). C'est génial de voir que pas mal de monde s'est motivé pour venir. Il y a des gens qui viennent d'Allemagne, de France et de République Tchèque.

Si l'idée principale est, bien sûr, de coder, il est hors de question de chômer en dehors des heures de boulot. On s'est notamment inscrit pour passer notre premier niveau de plongée :)
Pas besoin de préciser que randos, baignades, visites et autres activités touristiques en tout genre sont au programme ;)

La Dominique

Ca fait tout juste 5 jours que je suis arrivé en Dominique et s'il y a bien une chose que je peux dire, c'est que les gens sont vraiment gentils.
Autant dans la capitale, Roseau, les locaux savent bien repérer les touristes et font tout pour leur faire cracher quelques dollars, autant dans notre coin, Portsmouth, les gens sont juste adorables.
Notre hôte, par exemple, nous avait commandé des pizzas un peu avant qu'on arrive car il savait qu'on aurait faim ! Dans la rue, tout le monde vous dit bonjour et en quelques jours, on a déjà l'impression de connaitre tout le quartier. En bref, on se sent chez soi très rapidement.

Un autre point avec la Dominique, il ne faut jamais être trop pressé. Globalement les gens n'ont pas l'air de se mettre une quelconque pression pour quoi que ce soit. Exemple amusant : on avait besoin d'acheter une bouteille de gaz dans un supermarché, seulement il pleuvait ce jour là. Le gars qui tenais la caisse n'avait pas vraiment envie de se mouiller, qu'est-ce qu'il a fait alors ? Il a patiemment attendu que la pluie s'arrête avant d'aller chercher la bouteille. Ca a bien duré 10 minutes et il y avait des clients derrière qui faisaient la queue mais personne n'avait l'air de vouloir bouger pour faire avancer la situation.

Let's Hack

Pour l'instant nous n'avons que trois jours de hack au compteur, donc pas vraiment de retour d'expérience significatif à partager. Mais je compte faire un autre article qui s'orientera plus sur mon organisation (boulot, activités, rythme de vie ...). Je ferai sûrement ça à la fin de ma première semaine de boulot remote.

So stay tuned :)

Regex : tips and tricks

2014-09-05T00:00:00Z

Allez comme je sais que vous adorez les Expressions Régulières, voila quelques tricks sympas :).
Attention, ces techniques ne sont pas disponibles sur tous les moteurs d'expressions régulières. Pour savoir si les astuces dont je parle dans cet article sont disponibles dans votre langage préféré, je vous invite à consulter ce tableau Comparison of Regular Expression engines.

la répétition "ungreedy"

Par défault la répétition va essayer de matcher le plus de caractères possibles. Par exemple (en JavaScript) :

var reg = /<.*>/,
    str = "a piece of html: <html><head></head></html>";

console.log(str.match(reg)[0]);
//print : "<html><head></head></html>"

Mais souvent vous voulez limiter la portée de votre répétition pour ne matcher que la plus petite chaine. Dans ce cas là, on va utiliser la répétition "ungreedy" en utilisant le symbole ? après la répétition. Ce qui nous donne donc :

var reg = /<.*?>/,
    str = "a piece of html: <html><head></head></html>";

console.log(str.match(reg)[0]);
//print : "<html>"

Une autre solution pour arriver à ce résultat serait :

var reg = /<[^>]*>/;

Moins sexy tout de même :)

Vous pouvez utiliser cette astuce avec tous les types de répétitions (le *, le +, les {.,.} et le ?).

le lookahead

Parfois, avez besoin de faire des vérifications dans votre chaine de caractères, sans pour autant vous déplacer dedans.
Exemple typique, vérifier que différentes conditions sont présentes dans la chaine, sans savoir dans quel ordre elles seront.
Admettons que vous voulez trouver toutes les phrases ou apparaissent à la fois Felix et stratosphere dans la chaîne suivante :

I heard Felix is going to jump from the stratosphere.  
I know he's going to do it.  
Felix is the best.  
The stratosphere isn't far enough for Felix.

On va alors utiliser un lookahead pour vérifier que les mots Felix et stratosphere sont présents dans la chaine sans faire attention à leur position. Pour cela il serait idéal de lire la chaine mais sans ce déplacer dedans ! C'est justement le but du lookahead qui permet de simplement regarder sans faire avancer le pointeur de lecture de votre regex.

L'idée est donc d'aller regarder si stratosphere est dans la chaine, puis si Felix est dans cette même chaine (en partant toujours du début) et si ces deux conditions sont réunies alors commencer le matching.

Le lookahead (positif) s'écrit (?=regex) (il existe également le lookup négatif qui cherche quelque chose qui ne doit pas exister qui s'écrit (?!regex))

Voila la solution au problème précédent (toujours en JavaScript :)) :

var reg = /(?=.*stratosphere)(?=.*Felix).*?\./g;
    str = "I heard Felix is going to jump from the stratosphere.\n I know he's going to do it.\n Felix is the best.\n The stratosphere isn't far enough for Felix.";

console.log(str.match(reg)); //[ "I heard Felix is going to jump from the stratosphere.", " The stratosphere isn't far enough for Felix." ]

Une solution possible sans utiliser les lookahead serait :

var reg = /.*(Felix.*stratosphere|stratosphere.*Felix).*/g;

Vous saisissez l'idée : on vérifie que on trouve :

soit Felix puis stratosphere ;
soit stratosphere puis Felix.

Encore une fois, un petit manque de sexy :)

Un bon use case de cette technique serait par exemple de vérifier qu'un password dispose d'au moins une majuscule et d'un digit. (Je vous laisse ça en exercice ;))

Voila n'hésitez pas à laisser d'autres techniques pratiques que vous utilisez avec nos chères amies les regex.

Penser comme Vim

2014-08-05T00:00:00Z

Ca fait maintenant 3 ans que je n'utilise plus que Vim comme éditeur de textes. Ca fait aussi longtemps que je pensais écrire un article dessus et, allez, aujourd'hui, je me lance :)

Pourquoi j'adore Vim

Bon soyons franc, je pense que le premier contact avec Vim ça se passe souvent comme ça :

"Outch ! Qu'est ce que je dois faire de ça moi ?" ;
"Oh bordel, on ne peut pas éditer ! si j'avais voulu lancer less j'aurais tapé less !" ;
et après quelques minutes de rage contenue, le fameux "Putain comment on quitte ce bousin !".

Après cette expérience, il y a deux types de personnes, les apt-get purge vim et ceux qui se disent "ça ressemble à un défi pour moi !" (et qui ont un peu de temps devant eux :) ).

Admettons le, il faut être un peu maso pour relancer la commande vim :). Personnellement j'adore les défis, je me suis donc rangé dans la seconde catégorie de personnes.

Contrairement à beaucoup d'IDE qui vous donnent accès à toutes les commandes possibles à portée de souris, Vim vous parachute directement à poil en pleine jungle. Mais c'est là que vous allez progresser le plus. Vous allez devoir beaucoup mobiliser votre mémoire et faire un gros effort de compréhension/adaptation avant de pouvoir vous faire plaisir avec Vim.

Quand vous commencerez à maîtriser la bête, vous ne vous direz pas que vous avez trouvé un éditeur qui défonce, mais plutôt que vous êtes un demi-dieux de l'édition de code. Après tout c'est peut-être simplement ça que j'aime dans Vim, il flatte tout simplement mon égo !

Gardons les pieds sur terre

Voila quelques arguments un peu plus formels en faveur de Vim :

Il est quasi universel (installé par défaut sur la majorité des systèmes UNIX) ;
Il est parfait pour l'édition sur un serveur distant ;
Il consomme très peu de ressources ;
Il est facilement extensible ;
Il est très facilement personnalisable ;
Il vous aboli complètement du dictat de la souris ;
Pas d'interface graphique qui vous distrait, simplement votre code (une belle occasion de faire la part belle au code) ;
Vous pouvez exécuter n'importe quelle commande bash directement depuis Vim.

Vous remarquerez que je ne parle pas ici d'amélioration de votre productivité (comme certains peuvent l'affirmer) parce que je ne pense vraiment pas que Vim y change grand chose. Certes vous gagnez un peu de temps en vous libérant de votre souris. Cependant, face aux temps de compilation / rechargements de page / temps de réflexion / pauses café ... Je ne pense vraiment pas que ça soit significatif.

Comprendre Vim

Il y a deux choses à avoir en tête quand vous utilisez Vim : il y a plusieurs états et les commandes sont une suite d'instructions atomiques.

Les états

Dans Vim, il y a 3 états distincts : l'édition (le mode normal), l'insertion (le mode insert) et le visuel (le mode visual).

Insert. Le mode insertion, est le plus facile à comprendre. C'est en fait le mode par défaut de la majorité des éditeurs de textes. En bref, quand vous appuyez sur une touche, le caractère sur cette touche vient s'imprimer dans votre éditeur. Oui c'est ce qu'on attend d'un éditeur de texte et non ça n'est pas le mode par défaut ! Pour accéder à ce mode, tapez i (entre autres comme a, o ...) quand vous êtes en mode normal.

Visual. Le mode visuel va vous permettre de sélectionner du texte (à l'instar de la sélection via la souris) pour en faire ce que vous voulez (le copier, le supprimer, l'encadrer avec des balises ...). Pour mettre Vim en mode visual il vous suffit de taper v quand vous êtes en mode normal.

Normal. Le mode normal est le mode qui est de loin le plus intéressant de Vim, et c'est celui par défaut quand vous lancez Vim. C'est avec ce mode que vous allez pouvoir titiller la bête et vous amuser avec les commandes. Il ne faut plus voir votre clavier comme un ensemble de caractères, mais plutôt comme un ensemble de raccourcis vers des commandes de modification de texte. Pour l'activer appuyez simplement sur la touche esc.

C'est intéressant de constater la séparation de ses trois modes. Alors que la plupart des éditeurs n'ont qu'un seul mode (un mélange des trois de Vim), Vim se laisse une place toute particulière pour les commandes d'édition. En normal tout le clavier est entièrement disponible pour accueillir les commandes, je vous laisse imaginer le nombre de possibilités à portées d'un seul caractère ;)

Du fait d'avoir trois modes différents, vous devrez faire une petite gymnastique mentale pour savoir comment reconnaitre en quel mode vous êtes (par exemple le curseur change de style en fonction du mode) ou mieux vous rappeler en quel mode vous avez laissé votre Vim :). Assez souvent, ce sont surtout des automatismes qui se mettent en place tout seul. Par exemple j'ai pris le réflexe de toujours revenir en mode normal dès que j'ai finir de taper ce que j'avais en tête.

Les commandes

Vous l'aurez compris, pour accéder à la toute puissance de Vim (les commandes), il faudra vous mettre en mode normal. La clé pour comprendre la suite des opérations est de se rentrer en tête que Vim ne fait que des traitements très atomiques sur votre texte. C'est à vous de combiner les opérations atomiques pour faire ce que vous voulez sur votre texte.

Pour ça vous avez trois types de commandes vim :

les déplacements ;
les actions ;
les opérateurs.

L'idée est donc d'aller combiner les différentes commandes pour faire ce que vous voulez. A part quelques cas particuliers, les commandes sont assez simples à retenir puisque, bien souvent, il s'agit de la première lettre du mot en anglais qui défini l'action faite par la commande. Quelques exemples :

d (pour delete) va supprimer du texte ;
r (pour replace) va en remplacer ;
i (pour insert) va se mettre en mode normal en gardant la position du curseur ;
a (pour after) va se mettre en insertion en déplaçant le curseur sur le caractère après sa position actuelle ;
...

A partir de ça il ne vous reste plus qu'a faire des phrases pour expliquer à Vim ce que vous voulez faire. dt. (pour delete till .) va supprimer le texte entre votre curseur et le prochain caractère ., ci" (pour change inside ") va supprimer ce qu'il y a entre les " et vous mettre en mode insertion à l'intérieur.

Libre à vous de répéter plusieurs fois une commande en ajoutant un nombre dans votre phrase :

d2w (delete 2 words) va supprimer les deux prochains mots ;
y2{ (pour yanc 2 paragraph) copie les deux prochain paragraphes ;
2p (pour two pastes) colle deux fois le contenu du presse papier.

Normalement, si vous avez bien compris ça, vous allez être à même de déchiffrer la fameuse cheat sheet de Vim.

Je vous conseille de la garder près de vous surtout au début.

Les mots de la fin

La philosophie de Vim est de vous économiser un maximum de déplacement de mains sur votre clavier. Aussi, même si c'est un peu dur au début, essayer de vous forcer à utiliser h, j, k et l (en mode normal) pour vous déplacer caractère par caractère au lieux d'utiliser les flèches (ou pire la souris). Avec l'habitude vous aurez même tendance à ne vous déplacer que par recherche (avec /, ?, t, T, f et F article à lire absolument sur le sujet Learning Vim in 2014: Search) ou par positions spéciales comme $ (fin de la ligne) ou ^ (début de la ligne). C'est aussi l’occasion d'apprendre à bien placer et à bien utiliser tous ses doigts sur le clavier ;)

Vous verrez ensuite que beaucoup de services utilisent ce système de déplacement et de commandes mappées sur des touches (j'ai en tête Github, Gmail et beaucoup de services Google d'ailleurs, Bitbucket, Jira, Feedly. Essayez donc d'appuyer sur ? sur ces sites ;) ). Une fois que vous vous serez bien adapté à Vim, vous n'aurez pas de mal à utiliser les raccourcis de ses services.

Même si Vim est très fonctionnel de base sans aucune configuration, il est important que vous personnalisiez votre environnement (coloration syntaxique, espace vs tabs ...). Pour ça je vous invite à aller voir ma configuration pour la mettre à votre sauce.

Un petit conseil, pour vous y mettre doucement est de commencer par le tutoriel proposé par Vim directement. Pour ça tapez simplement vimtutor dans votre terminal et laissez vous guider ;)

Faire la part belle au code

2013-10-08T00:00:00Z

Mon expérience de développeur est relativement jeune (cela fait maintenant 1 an que j'ai commencé mon premier job chez DoYouBuzz), mais s'il y a bien quelque chose que j'ai compris sur le code c'est qu'il est, avant tout, personnel. Grammaires de langage, conventions, algorithmes, snippets de code et linters sont autant d'outils qui cadrent l'écriture de code, et pourtant il reste une infinité de liberté. Vous pouvez suivre toutes les conventions de codage que vous voulez, il y aura toujours une petite partie de vous dans votre code. Mais s'il vous appartient, vous en êtes aussi responsable. Il est de votre devoir de développeur de prendre soin de votre code.

L'écriture de code c'est de la poésie. Vous avez à votre disposition toutes les figures de style que vous voulez pour transformer une partition de caractères ASCII ennuyeux en poème. Vous pouvez tout à fait vous laisser aller à quelques Yoda Conditions. Vous êtes libres de concentrer votre code ou au contraire opter pour la légèreté et les retours à la lignes. Vous serez peut-être un amateur des return et en placerez dès que vous pouvez dans vos fonctions. Inversement vous vous lancerez dans une mise en abîme de if imbriqués. C'est à vous de choisir si vous préférez une approche fonctionnelle ou plutôt impérative. Dans tous les cas votre code vous appartient.

Construisez vous votre environnement de création. Ce n'est pas avec l'application que vous créez mais bien avec votre éditeur de texte que vous passerez le plus clair de votre temps. Tout comme le poète a besoin d'un cadre stimulant et d'une plume avec laquelle il est à l'aise, vous vous devez de trouver l'éditeur qui vous convient le mieux. Certain préféreront un Eclipse bien configuré avec toutes les fonctionnalités dont ils ont besoin à portée de souris. D'autres préféreront l'élégance du code pur et le confort du clavier et choisiront plutôt un Vim avec quelques plugins et toutes les commandes utiles en tête.

Soyez conscient. Vous êtes libres de faire ce que vous voulez de votre code, cependant, vous devez impérativement être conscient des conséquences de vos choix. Apprenez à fond les langages que vous manipulez et adaptez votre style au langage et à la plateforme pour laquelle vous écrivez. Sachez, par exemple, qu'une approche fonctionnelle va être globalement plus couteuse en mémoire qu'une approche impérative. Comprenez que vos collègues n'apprécieront pas forcement de relire des yoda conditions. Votre code peut être original, mais jamais au détriments des performances ou de la relecture.

N'ayez pas peur de la suppression. Supprimer des bouts de code est peut-être le sentiment le plus grisant du code. Supprimer du code, ça peut vouloir dire deux choses : soit la fonctionnalité est enlevée, soit vous avez réussi à factoriser la fonctionnalité en question. Dans les deux cas votre application ne s'en portera que mieux et votre code également. Dans le code, et tout particulièrement pour le web, moins de code veut dire un temps de chargement plus faible et moins de bugs potentiels. Je pense vraiment qu'une des choses qui qualifient un bon développeur et de pouvoir faire autant avec moins. Ne soyez plus ce collégien qui essaye absolument de remplir ses 5 pages de dissertation parce que la prof a dit "entre 5 et 10 pages" (oui, j'ai fait ça !).

Relisez et remaniez. Ne laissez jamais un bout de code dormir trop longtemps. Personne ne fait les choses parfaitement du premier coup. allez relire régulièrement du code que vous avez fait hier, la semaine dernière, le mois dernier ou encore l'année dernière. Vous pourrez être surpris par ce que vous lirez. Vous vous direz surement que vous avez bien changé depuis. C'est bon signe : c'est que vous progressez :) N'hésitez pas, à ce moment là, à réécrire ce qui vous choque. Dans mes projets persos, qui n'ont donc pas de deadlines (ce blog par exemple), je prends souvent le temps de refaire une fonctionnalité de A à Z. Assez régulièrement je me rends compte que je pouvais la faire bien plus simplement.

Réfléchissez. On sais tous qu'il ne faut pas attaquer un problème de plein fouet sans y avoir réfléchi un minimum. C'est très vrai, mais il y a une réflexion dont on parle moins : la réflexion à posteriori. Quand vous pensez le code avant de l'attaquer, vous savez ce qu'il doit faire mais pas ce qu'il va faire. Une fois le développement fini, vous avez précisément en tête les mécanismes de votre code ainsi que les détails de la fonctionnalité. C'est à ce moment que vous pourrez opérer suppression de code et remaniement. J'ai souvent entendu dire que lorsqu'on créé un bout de code, il ne faut pas penser optimisation dans un premier temps. Il est préférable de coder de façon (presque) naïve une première fois, puis ensuite d'identifier les bouts de code qui peuvent être factorisés/supprimés. Faire le contraire risque de vous embrouiller l'esprit au point de ne plus avoir en tête la fonctionnalité que vous développez. Les tests sont également là pour vous aider à préciser votre idée et surtout à valider vos futurs réécritures, utilisez les !

Soyez curieux. Une dernière chose, et pas des moindre : la curiosité. Quand quelque chose vous intrigue, que vous vous demandez comment ça marche, voyez y une opportunité de creusez plus loin, de progresser. L'Open Source (sous la forme de github par exemple) est une source d'informations et d'inspirations infinie ! Allez voir, par exemple, comment jQuery a réussi à abstraire et unifier les apis du DOM des différents navigateurs. C'est en lisant le code d'autres personnes que vous trouverez de l'inspiration et des façon de faire complétement différentes des vôtres. Apprenez d'autres langages de programmation qui n'ont rien à voir avec ce que vous faites, ça vous rendra plus intelligent. A mon avis, la curiosité est ce qui fait/fera d'un bon développeur, un excellent développeur.

Les quelques points que je traites dans cet article sont des réflexions qui me sont propres et qui me sont chères. Je n'ai aucune prétention de diffuser une quelconque doctrine du bon petit développeur, je n'ai clairement pas assez d'expérience pour pouvoir en faire autant. Cependant si un seul de ces points peut vous offrir une piste de réflexion si minime soit elle, alors ma mission est réussie.

Alors prenez bien soin de votre code et n'hésitez pas à réagir ;)

Javascript : Single-threaded et asynchrone

2013-06-01T00:00:00Z

Javascript est single-threaded, c'est quelque chose qui est rentré dans la tête de la plupart des développeurs front-end. Cependant ce à quoi on ne réfléchit pas assez c'est : comment est-il possible d'être à la fois single-threaded et de gérer du code asynchrone.

Les conséquences du thread unique

Bon c'est bien beau de savoir que Javascript ne dispose que d'un seul thread mais commençons par voir ce que ça implique ?

Les bons côtés :

jamais d'accès concurrents aux données ;
Le debuggage est nettement simplifié.

Les mauvais côtés :

Vous pouvez bloquer votre application avec du code un peu trop gourmand ;
On ne peut pas faire confiance aux timers (setTimeout et setInterval) qui ont une précision approximative.

Pour se convaincre à la fois des bons et des mauvais côtés voici un petit bout de code qui va l'illustrer. Considérez le code suivant :

var a = "start";

window.setTimeout(function () {
    a = "done";
    importantThingToDo();
    console.log(a); // -> "done"
}, 100);

timeConsumingFunction();

console.log(a); // -> "start"

Dans ce code, je suis sûr et certain que ma console affichera "start" en premier même si l'exécution de timeConsumingFunction() prend bien plus de 100ms. Si setTimeout avait créé un nouveau thread, je n'aurais pas pu prédire si ma console allait afficher "start" puis "done" ou le contraire. Autre chose à prendre en compte, si l'exécution de timeConsumingFunction prend plus que 100ms, importantThingToDo sera retardée. Si vous ajoutez à ça des interactions utilisateurs, vous pourrez encore retarder un peu son exécution.

Les timers

Les timers (setTimeout et setInterval) sont nos outils pour faire du code asynchrone avec Javascript. On se donnerait presque l'impression qu'on créé des threads et pourtant ... En réalité il ne faut pas voir les timers comme des fonctions asynchrones mais plutôt comme des gestionnaires de queue. Et oui, la fonction principale des timers est d'empiler des fonctions qui seront exécutées séquentiellement et au plus tôt n millisecondes plus tard. Le paramètre de temps prend alors une signification un peu différente de celle à laquelle on pourrait penser. Au lieu de :

"Exécute cette fonction dans n millisecondes"

il faut plutôt avoir en tête :

"Dès que tu es dispo après n millisecondes, exécute cette fonction"

D'où la faible fiabilité des timers Javascript.

Pour une explication un peu plus complète sur le fonctionnement des timers de Javascript, je vous invite à lire l'article How JavaScript Timers Work de John Resig dont je me suis beaucoup inspiré pour mon article.

Les événements, le secret des opérations asynchrones

Vous avez dû souvent aussi entendre que Javascript était Event Driven et en effet, si vous y regardez de plus près, l'exécution de code Javascript se fait toujours dans le cadre d'un événement envoyé par le navigateur (load, click, mouseover, progress ...). Ensuite c'est à vous, développeur, de définir ce qu'il va se passer en fonction de ces événements.

Je disais dans la section sur les timers que les timers empilaient des fonctions Javascript, en réalité c'est le navigateur qui s'occupe de cette tâche. Le navigateur va utiliser un timer interne (qui lui est précis) et enregistrer votre callback sur l'événement de fin de timer. Au bout des n que vous aurez définit, il va ajouter dans la pile d'exécution du moteur Javascript la fonction que vous aurez affecter au timer. Dès que le moteur Javascript sera libre, il s'occupera alors de votre callback.

Ce schéma se retrouve pour tous les événements qui se produisent dans le navigateur. Prenons l'exemple du clic, voici ce qui se passe quand l'utilisateur clique sur un élément :

le navigateur intercepte le clic ;
il vérifie les listeners que vous aurez définis ;
il les ajoute dans la pile d'exécution de Javascript ;
quand le moteur est disponible, il exécute chacun des listeners ;
à la fin de chaque listener le navigateur joue l'action par défaut (par exemple naviguer lors d'un clic sur un lien) si aucun des listeners n'a joué preventDefault() sur l'événement.

Toutes les actions asynchrones de Javascript fonctionnent sur ce modèle. Par exemple les requêtes XMLHttpRequest laissent au navigateur le soin de faire la requête puis de prévenir le moteur JS une fois que la requête est finie. Seulement contrairement aux timers, vous ne pourrez jamais prédire quand une requête AJAX sera finie. Par exemple le code suivant :

var request = new XMLHttpRequest();
request.open('GET', '/url');
request.onload = function () {
    console.log('request done');
};
request.send();

window.setTimeout(function () {
    console.log('timeout ended');
}, 10);

Vous ne pourrez pas dire si votre console va vous afficher "request done" puis "timeout ended" ou le contraire puisque vous n'avez aucune idée de quand l'événement load sera lancé.

Conclusion

Je pense qu'il est important de bien comprendre le fonctionnement interne des technologies que nous utilisons afin de bien les utiliser. Pour Javascript, S'il y a bien quelque chose à retenir c'est que Javascript n'éxécute qu'un seul morceau de code à la fois ! En gardant bien ça en tête vous verrez que certains comportements que vous ne vous expliquiez pas deviendrons clair.

Et juste pour voir si vous avez bien compris, que donnera l'exécution de ce bout de code ? (Pas le droit d'utiliser sa console hein ;) )

var a = '',
    i;

window.setTimeout(function () {
    a += 'Batman';
    console.log(a);
}, 0);

for (i = 0; i < 15; i ++) {
    a += 'nan ';
}
console.log(a);

NB : Sachez tout de même qu'il existe maintenant les web workers qui permettent de créer des threads sur lesquels vous avez la main.

Thomas Belin

Compiling your TypeScript library (2023 edition)

The wishlist

Considered solutions

Benchmark

Conclusion

Inspiring from React's useEffect to design effective APIs: the cleanup function pattern

The cleanup function pattern

Benefits of the cleanup function pattern

Perfect encapsulation

Preventing deceptive calls

A concrete example: Listening to a WebSocket

Conclusion

flatMap: an alternative to filter + map

The filter + map's signature

Filter-mapping an array in a single operation

Better TypeScript inference

Conclusion

Recovering lost commits with git reflog

What is HEAD?

What is the reflog?

Which commands are moving the HEAD?

Real life example: recovering from a reset

Conclusion

Get to know your browser's performance profiler

The data model

The limits of this model

self time vs total time

Diving into the UI

Identify long top-level functions: The call tree

Identify long nested functions: Inverting the call stack

Conclusion

Why React Hooks cannot be conditioned

TLDR

Disclaimer

What happens when a hook function is called

At mount time

At update time

So... Why can't we condition a hook?

Conclusion

Monitoring: A case study for EventTarget

The business logic

A naive implementation

Moving the tracking logic to the parent

Extracting the monitoring logic to a separate unit

Events to the rescue

Conclusion

You might not need this

The misunderstood this

Functions are about logic, this is about state

The separation of logic and state

Conclusion

Cycle.js, RxJS and cold observables

TLDR

The situation

The ridiculously simple solution

Explanation

Conclusion

Quelques questions courantes avec Flux

Où faire mes requêtes AJAX ?

Comment nommer mes actions ?

Comment choisir entre un composant statefull ou un nouveau store ?

À vous

Le guide que j'aurais aimé avoir quand j'ai commencé Flux

Pourquoi j'ai été confus par Flux

le problème que résout Flux

Flux

Les stores

Le dispatcher

Les vues

les containers

Les controller-views

Les actions

Flux en résumé

Conclusion

Hackerbeach : Organiser mon temps

Vivre avec le soleil

Travailler n'importe où

Travailler n'importe quand

Sortir de sa zone de confort

The `filter + map`'s signature

What is `HEAD`?

What is the `reflog`?

Which commands are moving the `HEAD`?

Real life example: recovering from a `reset`

The misunderstood `this`

Functions are about logic, `this` is about state