Forem: Yann

From imperative to declarative JavaScript

Yann — Thu, 06 Aug 2020 16:52:07 +0000

Introduction

In this post, I will explain why declarative code is better than imperative code.

Then I will list some techniques to convert imperative JavaScript to a declarative one in common situations, defining key terms along the way.

Why declarative ?

First, let's define what declarative and imperative mean.

Declarative code is one that highlights the intent of what it's doing.

It favors the "what" over the "how".

In other words, the exact implementations actually doing the work (aka the "how") are hidden in order to convey what that work actually is (aka the "what").

At the opposite, imperative code is one that favors the "how" over the "what".

Let's see an example:

The snippet below perform two things: it computes the square of x, then check if the result is even or not.

// imperative way

const x = 5;

const xSquared = x * x;

let isEven;

if (xSquared % 2 === 0) {
  isEven = true;
} else {
  isEven = false;
}

Here, we can see that we finally get isEven after several steps that we must follow in order.

These steps describe "how" we arrive to know if the square of x is even, but that's not obvious.

If you take a non-programmer and show him this, he might have a hard time deciphering it.

Now let's see another snippet where I introduce a magic isSquareEven function that performs the two same things than the previous one.

// declarative way

isSquareEven(5);

Much more concise right ?

The result we'll get is obvious because of the name of the function.

Even a non-programmer could easily understand.

But I'm cheating. I used a magic function.

We don't see "how" it actually works.

And that's a good thing because that frees us time, energy and memory to focus on what the piece of code does at the end of the day.

If we just want to use it, that's ideal.

But if we're curious, we still have the possibility to be by going to the definition of the function. (most editors allows you to jump to it easily)

So let's see the implementation of isSquareEven (the "how"):

// declarative way

const isSquareEven = (x) => ((x * x) % 2 === 0 ? true : false);

The fundamental building blocks of declarative code are functions.

In JavaScript, they have the particularity to be "first-class".

Which means that we can use them as normal data structures like numbers, strings etc.

In other words, you can store a function in a variable. You can pass a function as argument to another function. And a function can return another function.

So now that we have defined these two terms, it's easier to see in what declarative code is better than imperative code.

Declarative code is more readable.

Like we saw, it's way more concise and easier to understand.

In the previous example, we didn't deal with that much code so both snippets were easily understandable.

But you can imagine that a real project contains more code, and thus, more complexity.

So optimizing the readability will be more and more helpful as the codebase grows, and that's even more important if multiple persons work on it.

Declarative code is reusable. (because it often implies functions)

You may have noticed in the first snippet (imperative one) that the value of x is hard-coded at the beginning.

If we don't do this, the following lines cannot work.

Instead, when we use a function like in the declarative snippet, we can reuse the logic for any input, as long as it is a number.

Techniques

These techniques concern control flow statements: if/else, while, for loops.

These are imperative.

They describe how the work is done instead of what it is.

As a general guideline, you can simply abstract a piece of logic into a function with a descriptive name in order to make your code more declarative.

But when it comes to control flow statements, what to do is less obvious.

If/else statements

Sometimes, if/else statements are pretty explicit and short so I would argue that staying with them is, in this case, legitimate.

But other times, their conditions are less obvious and/or longer.

So we might abstract them out into functions with declarative names.

For example, let's say we want to check if an object is empty:

// imperative way

const o = { a: 1 }; // can be whatever object

if (Object.keys(o).length === 0) {
  console.log("Object is empty.");
} else {
  console.log("Object is not empty.");
}

In JavaScript, there's no easy way to determine if an object is empty.

You may be inclined to do this:

// imperative way

const o = { a: 1 }; // can be whatever object

if (o === {}) {
  console.log("Object is empty.");
} else {
  console.log("Object is not empty.");
}

But the condition will evaluate to false, because when using the == or === signs with objects (including arrays, functions, classes), they're compared by reference, not by equality of their properties.

If you're not familiar with this mechanism, explore this.

Going back to our example, it takes a bit of time realising that Object.keys(o).length === 0 is a trick to check if an object is empty or not.

So we might facilitate this by encapsulating it in a function:

// declarative way

const isEmpty = (o) => Object.keys(o).length === 0;

Now we want to log "Object is empty." or "Object is not empty." based on the result.

Instead of using an if/else statement, we can use a ternary expression.

The difference between the two, apart from the syntax, boils down to the difference between a statement and an expression.

A statement evaluates to nothing whereas an expression always evaluates to a value.

So we can treat an expression as a value, which means that we can store it in a variable, pass it into a function etc.

You can't do that with an if/else statement, for example:

// INVALID !!!
let variable =
  if (Object.keys(o).length === 0) {
    console.log("Object is empty.");
  } else {
    console.log("Object is not empty.");
  }

Finally, converting our first imperative snippet into a declarative one using a function and a ternary expression:

// declarative way

const o = { a: 1 }; // can be whatever object

const isEmpty = (o) => Object.keys(o).length === 0;

// function  -------------------- argument -----------------------
console.log(isEmpty(o) ? "Object is empty." : "Object is not empty");
//          condition    ----- then ------     ----- else ------

You might put the result of the ternary expression into a variable for even more readability and/or to reuse it later.

// declarative way

const o = { a: 1 }; // can be whatever object

const isEmpty = (o) => Object.keys(o).length === 0;

const message = isEmpty(o) ? "Object is empty." : "Object is not empty";

console.log(message);

For loops

When you're tempted to use a for loop, you can use map or forEach instead.

You might need to convert your data into an array if it isn't already because those functions only apply on it.

For example, you can use Object.entries() to get an array of key-value pairs sub-arrays from an object.

Then, after the mapping, you can convert back your result into an object with Object.fromEntries().

forEach is usually used for side-effects while map must be pure.

In other words, you use map when you need to get an array back whereas you use forEach if you want to perform some action(s) but don't care if it returns something or not.

That's why forEach returns undefined.

Here's an example of what I said:

// imperative way (aka with for loops)

const persons = [
  { firstname: "John", lastname: "Doe", age: 32 },
  { firstname: "Francesca", lastname: "Miller", age: 25 },
  { firstname: "Paul", lastname: "Bolton", age: 55 },
  { firstname: "Carol", lastname: "Oliver", age: 43 },
];

let presentations = [];

for (let i = 0; i < persons.length; i++) {
  presentations.push(
    `${persons[i].firstname} ${persons[i].lastname} is ${persons[i].age}.`
  );
}

for (let i = 0; i < presentations.length; i++) {
  console.log(presentations[i]);
}

Now let's see what it gives us with map and forEach:

// declarative way

const persons = [
  { firstname: "John", lastname: "Doe", age: 32 },
  { firstname: "Francesca", lastname: "Miller", age: 25 },
  { firstname: "Paul", lastname: "Bolton", age: 55 },
  { firstname: "Carol", lastname: "Oliver", age: 43 },
];

// use map because we want to compute a new array
const presentations = persons.map(
  (person) => `${person.firstname} ${person.lastname} is ${person.age}.`
);
// [
//   "John Doe is 32",
//   "Francesca Miller is 25",
//   "Paul Bolton is 55",
//   "Carol Oliver is 43",
// ]

// use forEach because only concerned by the action of logging
presentations.forEach((presentation) => console.log(presentation));
// undefined

We could achieve the same result simply by creating the "presentation" string inside the forEach callback and logging it right after, but I wanted to show the use cases of both map and forEach.

Now you might say:

Ok. But what if I want, let's say, the sum of all ages ?

With a for loop, that's pretty straightforward:

const persons = [
  { firstname: "John", lastname: "Doe", age: 32 },
  { firstname: "Francesca", lastname: "Miller", age: 25 },
  { firstname: "Paul", lastname: "Bolton", age: 55 },
  { firstname: "Carol", lastname: "Oliver", age: 43 },
];

let sumOfAges = 0;

for (let i = 0; i < persons.length; i++) {
  sumOfAges += persons[i].age;
}

What how to implement that with map ?

We can't because it always gives us an array and here, we want a number.

Now we need another function: reduce:

const persons = [
  { firstname: "John", lastname: "Doe", age: 32 },
  { firstname: "Francesca", lastname: "Miller", age: 25 },
  { firstname: "Paul", lastname: "Bolton", age: 55 },
  { firstname: "Carol", lastname: "Oliver", age: 43 },
];

const sumOfAges = persons.reduce((total, person) => total + person.age, 0);

I'm not gonna explain how reduce works here but that's quite a powerful tool you must learn because it's just... amazing. (I'll put some resources at the end of the post if you want to.)

Anytime you want to compute whatever (an other array, an object, a number, a string etc.) from an array, you can use it.

In fact, you can implement map, filter, slice and certainly other "declarative" functions with it.

That's why it's harder to grasp at the beginning.

But is there a non-trivial instrument that needs no learning before producing beautiful musics with ?

I don't think so.

Like I mentionned, there are other handy functions like filter and slice that can replace for loops to do specific tasks. (Again, the ressources are at the end of the post.)

Ok ! Let's tackle the last technique.

While loops

While loops can be replaced by recursion, more precisely, recursive functions.

What the heck is that ?

Well. A recursive function has two caracteristics:

It calls itself (recursive case).
It as a stop condition (base case) that, when satisfied, unwinds the callstack and eventually returns the wanted value.

Let's see an example:

const foo = (x) => {
  if (x < 5) return x; // stop condition
  return foo(x / 2); // calls itself
};

foo(16); // 4

Here's a visualization of what happens:

Each black arrow can be replaced by "returns".

The whole process explained literally:

foo(16): x === 16 so x > 5, thus we return foo(16 / 2). So we call it and will return whatever this call returns.
foo(8): x === 8 so x > 5, thus we return foo(8 / 2). So we call it and will return whatever this call returns.
foo(4): x === 4 so x < 5, the stop condition is satisfied. Thus we return 4.
Going back to step 2, we wanted to return whatever foo(8 / 2) (aka foo(4) in step 3) returns. Now we know it's 4, we return 4.
Going back to step 1, we wanted to return whatever foo(16 / 2) (aka foo(8) in step 2) returns. Now we know it's 4, we return 4.
Since the original call was foo(16), we have 4 as result.

The example is rather simple but at the end of the day, every recursive function share the two caracteristics I've listed above.

That's a technique I really struggled to grasp, so if it's your case, don't give up and expose yourself regularly to different learning materials.

Eventually, that should click one day.

Now let's see an example where we convert a while loop into a recursive function:

// imperative way

let x = 5;
let factor = x;

while (factor > 1) {
  factor -= 1;
  x *= factor;
}

Now, can you tell me what this loop does ?

It computes the factorial of 5.

So at the end, x is 120.

Even in this fairly simple example, it's not obvious what the while loop does.

Using a recursive function, we can easily solve this problem by giving it a meaningful name:

// declarative way

const factorial = (x) => (x === 1 ? 1 : x * factorial(x - 1));

Beautiful right ?

Try to decompose the function like I did in the previous visualization.

Do it on paper to really engage with the information.

Going further

In this post, I highlighted the terms imperative and declarative, essentially declaring that the later gives us more readable code.

But often those term are used in the context of OOP (often imperative) vs FP (more declarative).

Those are two programming paradigms (that is way of tackling software problems if you will).

FP stands for Functional Programming and OOP for Object-Oriented Programming.

While for loops are not an "Object-Oriented" thing specifically, the higher-order functions I introduced (map, reduce etc) are core tools in Functional Programming, for which they're often attributed.

The functional paradigm really interests me and I think you can enjoy learn about it.

In addition to being more declarative, it offers other powerful ideas/features like immutability of data-structures which helps to avoid a whole set of bugs related to mutability.

Unfortunately, JS doesn't provide that out of the box so it's a bit like swimming against the tide to try to enforce it, so you may play around with one that does like Clojure.

But they're great resources to learn this paradigm in JavaScript which I recommend because the functional languages are often less popular and with ecosystems of learning materials less mature.

Here are few of them:

Books:
- Functional-Light JavaScript
- Mostly adequate guide to FP (in JS)
Videos:
- Fun Fun Function playlist
Libraries:
- Ramda JS
More

Conclusion

That's it !

I hope you like this post and mostly, that it will be useful.

Keep coding ! 😄

Originally published on my site.

Message for those who begin coding

Yann — Fri, 31 Jul 2020 18:43:22 +0000

Introduction

I've been programming for almost one year and half now (since March 2019) and amazed by the progress I've made, but also by the landscape of learning that grows endlessly beyond me.

Programming is probably not an easy thing to learn for the majority of people.

I don't really know where to put myself on the spectrum, but I think I was pretty lucky to have the will and the interest to persist.

So in this post, I will talk about the difficulties I faced and how I overcame them.

I hope it will give hope for those who begin coding and prepare them to potential barriers they may face.

Thus, that should reduce the chances of giving up.

First encounter with code

I guess it depends on the background of each one of us, but I personally haven't been exposed even a little to programming.

I probably had more general knowledge on computers than the avergage (because I was quite into video games) but I certainly had no idea of the GIGANTIC world that's behind our screens.

It just strikes me how I never really questionned myself about how all these softwares I used were made.

When you're a mere user, you have absolutely no idea of what's happening behind the scene, and care no more.

That's really something to keep in mind while gaining knowledge in programming and computers in general:

Most of the people, and therefore the majority of the users of your software, don't know what you know.

They don't care about the technical aspects. They care about what they want to achieve with your software.

If you remember that, you will a have a great advantage.

You will never loose the track because you will have the perspective to know what's the most important thing: solving a problem with your software and do it as well as possible.

Because otherwise it's very easy to confine yourself in "not so important" technical aspects and basically waist your time and energy on them.

Tools (languages, frameworks, protocols, devices etc) are only relevant because of the objective they help to achieve.

Enough digression.

So I started to learn HTML and CSS, then JavaScript. (and English in addition because I was a french teenager of 16yo without the capacity to read fairly complex english texts... Yeah, that was a bit rough.)

I used free resources (which I always do apart from some books) like freeCodeCamp, MDN documentation, video tutorials... (trust me, you will quickly find stuff to explore. By the way, that leads to a problem that will talk about later in this post.)

I've some glimpse of memories of when I was beginning (and that was just 1 year and a half ago!).

I remember that sense of oddness, I mean that's really what it is, a language I've no familiarity with.

So yeah, my brain struggled for some weeks before being more familiar with that language.

Passed that step, you've gain a familiarity with programming languages in general that will make things way easier to learn (at least way easier than the beginning).

Things started to be more interesting when I learned JavaScript.

Javascript is a script language unlike HTML which is a markup language.

I would say that learning such a language increases your familiarity to an higher level.

Because the majority of languages are script ones, learning Javascript really helped me learning (or at least experimenting) other languages such as Python, PHP or Clojure recently.

I find those to be the two big steps.

Once you've overcome them, you will never be the same person. Really.

How to know if you love programming ?

The approach I had when I started programming (and I've this approach with any kind of new activity I start to learn) was to force me to code 1/2h each day during a month.

Only then I would make a recap and decide to continue or not based on my feelings.

Why ?

Because otherwise, one day that I get particularly de-motivated or upset, I could decide to stop programming forever.

And that's a shame to abandon a potential source of joy in your life, as well as accumulated knowledge and experience that may be really useful in the future, just because of a decision biaised by your mood in the moment.

At the end of the month, you will have a real time dedicated to taking perspective on your experience and feelings, thus making a decision less biaised and more likely to reflect your real desires.

If you find that you don't like programming after this month, just stop.

There's no reason to continue.

Don't feel guilty because you judge that you give up.

That's not abandoning. That's a conscious choice.

And by the way, that decision is not irreversible.

You can realise some days/weeks later that you actually want to keep coding.

Otherwise, if your motivation go up and down, that sometimes your super excited and other times you feel depressed, not good enough or that some bugs annoy you for multiple hours/days (or even forces you to put aside the thing to keep your mental health), then I would advise you to PERSIST.

That means that there's interest, passion, however you call it.

A challenged passion for sure, but a passion anyway.

Then, you can plan another cycle of 2/3 months this time, determining what you will focus on and AGAIN (that's very important), fixing in advance a moment to recap.

Being in the latter case, that's what I did and I keep making "cycles" to progress.

The gist here is that if you feel to have a real interest in programming, then PERSISTENCE is the most valuable skill you can have.

So spend appropriate resources (time, energy to develop habits and strategies) in order to build that skill.

Facing information overload and choosing what to learn

Halalala.... What a struggle... To be honest, I've certainly not resolved this problem yet.

I will share my thoughts and advices on that, but because, like I said, I still struggle, you must take perspective on what I'll say and test by yourself.

There's a lot of resources out there.

The good point is that you can easily access these once you've an internet connection.

You can clearly content yourself with free resources, especially in the world of programming where the community has an "open source" mentality I've never seen anywhere else.

The downside, however, is that you have to choose.

Doesn't seem horrible right ? Isn't it a sign of freedom ?

Well. It is. But now you must spend more time and energy in order to choose.

And that's not what we want. We want to spend these on learning/working.

(By the way, I highly recommend The Paradox of Choice by Barry Schwartz. It explains all the downsides of an excess of choice.)

But in the mean time, you don't want to pick a bad resource.

So here lies the friction.

I think the key is to make a conscious decision.

Don't fall into the habit of either picking whatever resource is close to hand or always spending an enormous amount of time pondering about what you'll pick next.

You must put the amount of time and energy you want in the choice process.

How do you determine that ?

I've no perfect answer but some general guidelines.

If you start learning something, there's no reason to worry too much about the quality of the resource, because anyway, you will learn something.

And at the beginning, it's more important to get going, to build the habit of working on the new subject of interest.

Going forward, you're knowledge will expand and it will be more and more difficult to find resources that bring something new.

At this phase, I think it's more relevant to spend more time searching for great, in-depth resources that may bring you novelty.

I always struggle with the feeling of waist when I read or watch something I already know.

But we must be patient and I would say that experience (i.e actually building stuff and explore yourself) will become the most valuable.

So if you have something to remember from this section, it's that:

The majority of your time and energy should be spent on learning. Not choosing.

Final note

There will be moments of struggle, fear, wrongness, culpability, maybe shame...

The thing is that in all those unpleasant situations that seem to be dead ends, remember that there's always reasons and thus, solutions.

Remember that wrong actions or decisions from your part doesn't mean that YOU are wrong.

Take it as a challenge, to make better actions and decisions for the goal in place.

Anyway...

If programming helps you enjoy life, then do it.

It's that simple.

A hook for data fetching in React

Yann — Mon, 13 Jul 2020 18:48:50 +0000

A hook for data fetching in React

Introduction

In this post, I will go through the process of creating a custom hook for data fetching in React.

I expect that you are familiar with React and the hook API, specifically useState, useEffect and useReducer.

If not, you must want to check out the doc before.

In addition, the hook we'll build is a mean to exercise and get inspiration more than an adapted version to the specific problem you may encounter in a real world project.

Building the custom hook

The hook we'll build addresses a task we often have to do in web apps: fetching data.

In this example, we'll fetch data from the PokéAPI and render some information about specific pokemons on the screen.

By the end of that tutorial, we'll have something that looks like this:

Let's quickly setup our app and the JSX it will render.

Don't bother too much about it, that's not the interesting part. I just put it here to give context:

// ...imports

export default function App() {
  // ==========================================

  // Where we gonna do the interesting stuff

  // ==========================================
  if (isLoading) return <div>Loading...</div>;
  if (err) return <div>{err.toString()}</div>;
  return (
    <div className="App">
      {data && (
        <div className="poke-card">
          <form onSubmit={handleSubmit}>
            <input
              ref={inputRef}
              type="text"
              id="poke-input"
              name="poke-input"
              placeholder="Choose your pokemon"
            />
            <button>Search</button>
          </form>
          <h1>{data.name.toUpperCase()}</h1>
          <img
            className="poke-img"
            src={data.sprites.front_default}
            alt="Pokemon"
          />
          <div>
            <strong>Weight</strong>: {data.weight}
          </div>
          <div>
            <strong>Height</strong>: {data.height}
          </div>
          <div>
            <strong>Abilities</strong>: {formatAbilities(data.abilities)}
          </div>
        </div>
      )}
    </div>
  );
}

The entry point for data coming from the user is the input.

It will receive a pokemon name which will be the endpoint of the PokeAPI url we gonna request.

Like you may have seen, the input is in a form that has an onSubmit handler which I called handleSubmit.

To get the input value inside handleSubmit, I use a React feature called ref.

It allows my to keep a reference of the input without the need to reach the DOM with the classic document.querySelector(selector)

Because it's a side effect, I would need to put it in a useEffect hook.

(Learn more about refs here.)

Let's add the code:

// ...imports

// base url of the PokeAPI
const baseUrl = 'https://pokeapi.co/api/v2/pokemon/';

export default function App() {
  const [endPoint, setEndPoint] = useState('pikachu');

  const inputRef = useRef(null);

  function handleSubmit(e) {
    e.preventDefault();

    setEndPoint(inputRef.current.value);
  }

  // ...
  return (
    // ...
  );
}

Here, I defined endPoint as a state variable with useState.

Then we update it with the input value at the time the user submit the form, that is when he clicks the button "Search".

Ok. Now that interaction with the user is setup, we have to actually fetch the data we want from the API.

Because this task is asynchronous and thus, may take time, we must do it in a useEffect hook in order to let the browser paint even if the data isn't there yet.

Let's do that using the fetch API:

// ...imports

// base url of the PokeAPI
const baseUrl = 'https://pokeapi.co/api/v2/pokemon/';

export default function App() {
  const [endPoint, setEndPoint] = useState('pikachu');
  const [data, setData] = useState(null);

  useEffect(() => {
    const fetchData = async () => {
      const pokeData = await fetch(baseUrl + endPoint);
      setData(pokeData);
    }

    fetchData();
  }, [endPoint])

  // ...
  return (
    // ...
  );
}

I introduced a new state variable called data to store what we receive from the API and use it in the JSX that the app renders.

When the promise returned by fetch is fulfilled, we update the data state using setData, which will trigger a re-render of the App component and thus, returns a UI with the updated data.

Finally, useEffect as endPoint as dependency so that it's re-executed only when endPoint changes.

But there's something we missed here.

What do we show to the user when the data is not there ?

And what happens if the request fails ?

An error will be thrown and the user will have no feedback about it.

So we need to catch the error and put it in a state variable in order to adapt the response we give to our user.

In addition, we'll use a state variable to track the loading state:

// ...imports

// base url of the PokeAPI
const baseUrl = 'https://pokeapi.co/api/v2/pokemon/';

export default function App() {
  const [endPoint, setEndPoint] = useState('pikachu');
  const [data, setData] = useState(null);
  const [err, setErr] = useState(null);
  const [isLoading, setIsLoading] = useState(false);

  useEffect(() => {
    const fetchData = async () => {
      setIsLoading(true);
      try {
        const pokeData = await fetch(baseUrl + endPoint);
        setData(pokeData);
        setIsLoading(false);
      } catch (err) {
        setErr(err);
        setIsLoading(false);
      }
    }

    fetchData();
  }, [endPoint])

  // ...
  return (
    // ...
  );
}

We have done a good job so far !

But there's still a bug that can happen. Did you see it ?

This one is hard to find.

Imagine the component is unmounted or re-rendered before the data arrives.

The useEffect callback will try to call setData (or setErr) whereas there's no more state variable.

In the browser console, you will see something like this:

To handle this gotcha, we need a way to tell useEffect to not call setData (or setErr) if the component has been unmounted or re-rendered.

But how will we do that ?

Well, the useEffect callback can return a function that's called after the component is unmounted. In the case it is re-rendered, the function is called right after the next render, but before that the new useEffect version runs.

Thus, we can use a flag (didCancel) that we'll reverse by calling the returned function, which will inform us about if the component has been unmounted or re-rendered when useEffect will be called:

// ...

export default function App() {
  // ...
  useEffect(() => {
    let didCancel = false;

    const fetchData = async () => {
      setIsLoading(true);
      try {
        const pokeData = await fetch(baseUrl + endPoint)
        if (!didCancel) {
          setData(pokeData);
          setIsLoading(false);
        }
      } catch (err) {
        if (!didCancel) {
          setErr(err);
          setIsLoading(false);
        }
      }
    }

    fetchData();

    return () => {
      didCancel = true;
    }
  }, [endPoint])

  // ...
}

Finally, we can make a last little improvement by merging the err and isLoading states into a single object that we'll update with a reducer.

But why would it be an improvement ?

In cases where you find yourself writing multiple setSomething together, that might be the sign that these states are related. So it makes sense to group them which can reduce complexity.

In our example, err and isLoading states can be classed as fetchStates.

So let's implement that with useReducer:

// ...

function fetchReducer(state, action) {
  switch (action.type) {
    case 'FETCH_INIT':
      return {
        isLoading: true,
        err: null
      };
    case 'FETCH_SUCCESS':
      return {
        isLoading: false,
        err: null
      };
    case 'FETCH_FAILURE':
      return {
        isLoading: false,
        err: action.payload.err
      };
    default:
      throw new Error('Unexpected action type');
  }
}

const initialState = {
  isLoading: false,
  err: null
};

export default function App() {
  const [data, setData] = useState(null);
  const [fetchState, dispatch] = useReducer(fetchReducer, initialState);

  useEffect(() => {
    let didCancel = false;

    async function fetchData() {
      try {
        dispatch({ type: 'FETCH_INIT' });
        const res = await fetch(url);
        const data = await res.json();
        if (!didCancel) {
          setData(data);
          dispatch({ type: 'FETCH_SUCCESS' });
        }
      } catch (err) {
        if (!didCancel) {
          dispatch({ type: 'FETCH_FAILURE', payload: { err } });
        }
      }
    }

    fetchData();

    return () => {
      didCancel = true;
    }
  }, [endPoint])

  // ...
}

In the snippet above, I've added a reducer called fetchReducer and a initialState.

I've put them outside the App component because they don't rely on any prop or state, so it's unnecessary to recompute them each time the component re-renders.

Now, instead of calling setErr and setIsLoading, we just dispatch an action object with a certain type property and an optional payload containing information that might be relevant to update the state.

Take the time to read the code in order to grasp what happens.

Cool, we have finished !

What ? But where's the custom hook ? I don't see any useFetch thing...

Hehe 😏, I'm joking...

The final step is pretty trivial. We've all the stateful logic so now, we just have to put it into it's own function, which will be our custom hook.

When I say "stateful" logic, I mean all the things that deal with state, i.e the useState, useEffect and useReducer.

Here's the full code:

// useFetch.js
import { useState, useEffect, useReducer } from 'react';

function fetchReducer(state, action) {
  switch (action.type) {
    case 'FETCH_INIT':
      return {
        isLoading: true,
        err: null
      };
    case 'FETCH_SUCCESS':
      return {
        isLoading: false,
        err: null
      };
    case 'FETCH_FAILURE':
      return {
        isLoading: false,
        err: action.payload.err
      };
    default:
      throw new Error('Unexpected action type');
  }
}

const initialState = {
  isLoading: false,
  err: null
};

function useFetch(url) {
  const [data, setData] = useState(null);
  const [fetchState, dispatch] = useReducer(fetchReducer, initialState);

  useEffect(() => {
    let didCancel = false;

    async function fetchData() {
      try {
        dispatch({ type: 'FETCH_INIT' });
        const res = await fetch(url);
        const data = await res.json();
        if (!didCancel) {
          setData(data);
          dispatch({ type: 'FETCH_SUCCESS' });
        }
      } catch (err) {
        if (!didCancel) {
          dispatch({ type: 'FETCH_FAILURE', payload: { err } });
        }
      }
    }

    fetchData();

    return () => {
      didCancel = true;
    };
  }, [setData, dispatch, url]);

  // Here we return the states that we want to expose to our App component
  return { data, ...fetchState };
}

export default useFetch;

// ======================================================================================

// App.js

import React, { useState, useRef } from 'react';
import useFetch from './useFetch.js';

// Helper to format what's shown
function formatAbilities(abilities) {
  const abilitiesList = abilities.reduce((acc, abilityObj) => {
    return [...acc, abilityObj.ability.name];
  }, []);
  return abilitiesList.join(', ');
}

const baseUrl = 'https://pokeapi.co/api/v2/pokemon/';

export default function App() {
  const [endPoint, setEndPoint] = useState('pikachu');

  // ============================================
  // Here's where we call useFetch !

  const { data, isLoading, err } = useFetch(baseUrl + endPoint);

  // ============================================

  const inputRef = useRef(null);

  function handleSubmit(e) {
    e.preventDefault();

    setEndPoint(inputRef.current.value);
  }

  if (isLoading) return <div>Loading...</div>;
  if (err) return <div>{err.toString()}</div>;
  return (
    <div className="App">
      {data && (
        <div className="poke-card">
          <form onSubmit={handleSubmit}>
            <input
              ref={inputRef}
              type="text"
              id="poke-input"
              name="poke-input"
              placeholder="Choose your pokemon"
            />
            <button>Search</button>
          </form>
          <h1>{data.name.toUpperCase()}</h1>
          <img
            className="poke-img"
            src={data.sprites.front_default}
            alt="Pokemon"
          />
          <div>
            <strong>Weight</strong>: {data.weight}
          </div>
          <div>
            <strong>Height</strong>: {data.height}
          </div>
          <div>
            <strong>Abilities</strong>: {formatAbilities(data.abilities)}
          </div>
        </div>
      )}
    </div>
  );
}

Now we're done ! 😄

See final version running here.

For those who are into TypeScript, I've done a typed version. But I encourage you to do it on your own to practice.

Conclusion

Like I said in the introduction, you may need to tweak the API of that hook in order to fit your specific use case and your preferences.

Anyway, I hope that it lightens the horizon of things you thought you can do with custom hooks.

As an intermediate user of custom hooks, I always feel overwhelmed by the huge power they give.

For sure, they offer a realm of appealing abstractions but at the end of the day, I think that one must strive to find the best and simplest solution to its specific problem rather than forcing the use of custom hooks.

What I mean is that if a block of stateful logic is not that big or complicated, and that it's used only in one or two components, don't bother with creating a custom hook for it.

Personally, I was so excited by them that I would directly try to think of a custom hook that would solve my problem.

But I changed my approach by doing things step by step, first using built-in hooks and then extract a block of stateful logic if needed, like we did in this post.

That's it ! I'm eager to read your comments and see the tweaked versions you may have built on your own !

Inspirations and further resources

This post is highly inspired by this article of Robin Wieruch.

If you want to go deeper into React in general, I highly recommend his blog as well as the one of Dan Abramov, a core developer of the React team.

Anyway, I believe the only source of truth is the documentation (unless it sucks..., which must question you about if you should use the tool concerned. But don't worry, the React doc is really great. The ecosystem is really mature, you will have no problem to find what you need.). So check it out.

How to render different components based on screen size

Yann — Mon, 29 Jun 2020 17:49:16 +0000

Introduction

I recently stumble across a pretty sweat JS Web API that I was completely unaware of before.

That API is Window.matchMedia().

With it, you can check the window size against a media query and you'll get a boolean: whether true if the window size matches your query or false otherwise.

You can make the check once are set a listener to dynamically check if the window matches your query.

Use cases (not exhaustive)

You're may be wondering why we would want to use this API.

We already have CSS media queries to change the style of our page depending on its size.

But in certain cases, you need to render different components based on that size, and CSS can't help you there.

Sometimes also, the amount of style change is so big between the views you want on each side of a breakpoint that you may find simpler to have two different components that are just different by there styles, and then render them depending on the window size.

Let's look at an example to understand it.

Vanilla JavaScript example

I wanted the capability to render different components based on the screen size in a Svelte project.

If your not familiar with Svelte, that's a JS framework that gather the HTML, CSS and JS for a component in a single .svelte file, which will be compiled before being send to the browser.

Thus, the CSS and JS in such a file are scoped to a block of HTML. The whole is referred as a Svelte component that you can pass around...

The framework adds a few features to JS but the code usually looks like vanilla JS, whereas in a framework like React, because of the way the code is organized, it doesn't look like vanilla JS anymore.

So the example I'll give here is an example implemented in vanilla JS, but if you wonder how to implement that feature in a React app, see react-media. This package was recommended in a reddit thread. I read the doc and it seems pretty cool. In addition, it was made by the creator of react-router, so definitely check it out.

Now, let's dive in the example:

First, I'll create two navbar components to mimic the situation we have in a component based framework:



const Component1 = `
<ul>
  <li>Navlink 1</li>
  <li>Navlink 2</li>
  <li>Navlink 3</li>
</ul>
`;

const Component2 = `
<ul>
  <li>Navlink 1</li>
  <li>Navlink 2</li>
  <li>Navlink 3</li>
  <li>Navlink 4</li>
</ul>
`;

The only difference between those two navbars is that the second as one more navlink.

We'll say that we want to render the long navbar (Component2) on desktop screens, but on mobile, we decide to remove one navlink because of the size of the screen (we might put that navlink in a hamburger menu for example).

So for the mobile view, we'll render the short navbar (Component1).

To render a component, we'll use a little helper to inject the html in the navbar:



const setNavInnerHTML = (html) => {
  const nav = document.querySelector('nav');
  nav.innerHTML = html;
};

Now, imagine that our breakpoint is a width of 600px: more is considered desktop view, less or equal is considered mobile view.

We are fully equipped to use Window.matchMedia():



// I'm borrowing the MDN doc notation here: "mql" stands for "media query list".
const mql = window.matchMedia('(max-width: 600px)');

let mobileView = mql.matches;

if (mobileView) {
  setNavInnerHTML(Component1);
} else {
  setNavInnerHTML(Component2);
}

Here, we specify our query as a string in the window.matchMedia() function, which returns an object of type MediaQueryList.

On this object, you can access the property matches which is boolean telling you if the current window size matches your media query.

Pretty simple.

It looks like this:

On this object, you can access the property matches which is a boolean telling you if the current window size matches your media query.

However, this example would only work for the first render.

If we want to dynamically adjust the layout, we can set an event listener on the media query list returned, of type change:



mql.addEventListener('change', (e) => {
  const mobileView = e.matches;
  if (mobileView) {
    setNavInnerHTML(Component1);
  } else {
    setNavInnerHTML(Component2);
  }
});

So on desktop, it will look like this:

And on mobile:

See full code here.

Conclusion

That's it for this quick post.

I hope you discovered a new tool to add in your toolbox, and maybe one day you will need it and use it!

On that, continue coding ;)

What's an API ?

Yann — Sun, 14 Jun 2020 19:01:32 +0000

Introduction

I find that the term "API" is used a LOT by people in the software industry. And frankly, I programmed for 1 year and a half without understanding it. That was really frustrating particularly because it's so much used !

But recently, the sky lightened up and I got a boost of motivation to go deeper in what it really means and try to explain it to you.

API stands for "Application Programming Interface".

Well, that's pretty explicit. An API is an interface through which a programmer can interact with an application, i.e a piece of code (more or less big of course).

That seems obvious, right ? Huuuurrrgh... Probably not if you're reading this post. So I'll explain how I think of it with some visualizations and then, give you some examples.

Visualization

Personally, I think of an API as a function which takes inputs and returns outputs.

I visualize it as an opaque box with a hole at the top where we provide the inputs and an exit on the side where outputs are returned.

Indeed, a simple function exposes an API. In this case, it's the inputs and the outputs.

It's like the Function Machine guy said to you:

Hey ! I can create four cubes. If you want them, you need to give me three spheres.

You have no idea how this guy makes four cubes out of three spheres, but you don't care ! The only thing important here is to know what that function does (outputs) and what you should provide to make it work (inputs).

A function API

May a simple code example be more concrete:

function sum(x: number, y: number): number {
  return x + y;
}

This code block is written in TypeScript, which is a superset of JavaScript. I used it to be explicit about the type of the inputs the function requires and the output it gives.

We can see that sum promises to return a sum if you give it two numbers. Dead simple right ?

Like I said previously, the internals of how the function does its sum are not important. That is, we could hide the code between the curly braces and still use sum.

Let's see an example by using multiply without knowing its implementation, but just its API.

// multiply API:
// It will give you the product of the two numbers you provided it.

// Cool ! I can use it to do my own stuff !:

function square(x) {
  return multiply(x, x);
}

console.log(square(2))
// 4

You see ? We used multiply without knowing its implementation !

Ok, you're not dumb... You have certainly guessed that the code inside the function is something like:

// ...
  return x * y;
// ...

...but you get the point.

With big, complicated functions, you do not know the inside, but you use them. We'll see more complex examples where that's the case.

API of a library

One case where the term API is used is when you deal with a library. To illustrate, we'll look at a popular JavaScript one: React. That library exposes a global object as an entry point called React.

This object has several APIs, that is several methods that produce outputs if we provide the intended inputs.

It looks like this:

const React = {
  createElement,
  createFactory,
  cloneElement,
  isValidElement,
  useState,
  useReducer,
  // ...
}

Let's use one of these: useState.

According to the API documentation of useState, it returns a stateful value and a function to update it, together placed in an array. As input, it takes one argument which is the initial state.

For example:

const output = useState(0)
// output: [0, function...]

We can use a JS feature called "array destructuring" to directly assign the array values returned by useState to their respective variables:

const [state, setState] = useState(0)
// state: 0
// setState: function...

Now we can use setState to update the state as we want:

setState(1)
// state: 1
// setState: function...

So as I said earlier, we don't know anything about the internal code of useState. But because we know its API specification, we can use the functionality it offers.

(Note: There are more considerations and possibilities to acknowledge about this method but explaining them is not the purpose of this post.)

API of a third-party service

Finally, I would like to show another example where API is used, one that implies a third-party service (such as Twitter, Youtube, Google Maps...).

In our example, we'll use OpenWeather. This a platform that collects weather data around the world and exposes an API through which we can request that data.

Here, we need to make a specific HTTP request to get the data we want. The documentation says that we must do a call of the form api.openweathermap.org/data/2.5/weather?q={city name}&appid={your api key}.

Let's do that:

// assuming we are in a async function

const data = await fetch('https://samples.openweathermap.org/data/2.5/weather?q=London,uk&appid=439d4b804bc8187953eb36d2a8c26a02').json()
// data:
// {
//   "coord": {
//     "lon": -0.13,
//     "lat": 51.51
//   },
//   "weather": [
//     {
//       "id": 300,
//       "main": "Drizzle",
//       "description": "light intensity drizzle",
//       "icon": "09d"
//     }
//   ]
//   ...
// }

// do whatever with the data

Easy peasy !

Now we can use the data in our application without worrying about how to get it, how to format it etc.

Indeed, it's far less tedious and expensive than creating the data by measuring all the stuff ourselves.

(In fact, I assume that OpenWeather itself rely on other services and APIs to get all that weather data.)

The power of APIs

APIs are the building blocks of abstraction.

They allow modular programming, that is the ability to leverage functionalities of external pieces of code (so called "modules") in our own codebase.

At the lowest level of abstraction, there are only 0 and 1s. So programmers have added multiple layers of abstraction above in order to focus on what is really important and thus, work more effectively.

Today, every program rely on some sort of abstraction and that's why they get increasingly powerful. Because otherwise, one's human brain would not keep up with all the 0 and 1s that the computer consume at the end of the day.

Conclusion

That's it!

I hope the article helped you to understand this term.

If you have any comments or suggestion about something, feel free to share it. I would really appreciate it.

I'm eager to deepen my understanding around that subject.

Sources

Going further

software architecture: https://en.wikipedia.org/wiki/Software_architecture
abstraction: https://en.wikipedia.org/wiki/Abstraction_(computer_science)
designing APIs: https://www.youtube.com/watch?v=_YlYuNMTCc8

Should we explicitly type the output of all functions (TypeScript) ?

Yann — Fri, 22 May 2020 13:39:40 +0000

I'm starting to learn TypeScript and I'm frustrated about if I should type functions output or not.

In one hand, I would like to be explicit and consistent in my code, which invite me to explicitly type the output.

But in the other hand there are type inferences and I feel that adding the output type can become verbose and thus, more difficult to read.
Finally (I'm not sure about this), I think that I've read in the doc that type inferences may fail when the type is complex. This last point is in favor of explicit output typing.

I wondered what our your thoughts on this, experienced TS developers, so share your opinions !

Two Little Tricks To Improve Your Productivity

Yann — Thu, 11 Jul 2019 17:44:55 +0000

Introduction

This is a short article where I share 2 little tricks I find powerfull to improve productivity. Let's discover them !

1) Micro-naps

I define as micro-nap a 10-20 min break you spent lying in a quiet environment.
Basically.

The exact duration of the nap depends on your preferences, but I recommend to not exceed 20 min because you can enter a kind of cycle which it will be really unpleasant to leave.

For me, this type of break is much more effective than a coffee break, discussing with others or listening podcasts and musics. It gives a real space to your brain and allows him to rearrange all the stuff you work on. It's also a good way for your body to rest.

By the way, you can't take a nap anywhere. Obviously, there's probably no bed in your office and even if that was the case, it would be embarrassing to sleep in front of your colleagues and boss. So I consider it like a luxury that I can afford to when I work at home. Even if that just concern the end of the afternoon after the workday or the moments when you work at home, I invite you to try micro-naps. Same for people who take lunch at home.

2) The 5s technique

This is a very tiny trick but I love it for its simplicity. Anyway, don't attend to get huge benefits with it.
The principle is just to count from 5 to 0 (the order is important) just before engage in a task or a period of time where you want to be concentrated.
That's just a way to emerge and put away all the thoughts that hold you to act.

Conclusion

I really invite you to test these 2 tricks. Schedule notifications for a week or two and fix yourself to apply one of these techniques. Despite what you might think during this week, don't stop and take a moment to wonder if that was usefull AFTER the period of test.
If that works for you in some ways, I would be happy that I could help you in your dev journey ;) !
If not, you would get some experience in testing things and that's fine too.

That's all for this article. Thanks for your time and attention. I hope that you enjoy reading it and for sure, give me your feedback in the comments or contact me on Twitter!

Keep It Simple

Yann — Sat, 06 Jul 2019 16:15:48 +0000

Introduction

If you can't keep yourself to buy a book, subscribe to a newsletter, add a ton of youtube videos in your "watch later" or even wonder at each second of your life if what you are doing is worse it, this short article is for you.

So you recognize yourself in this introduction... Well.

-Good news: You seem to be really motivated to learn and grow.

-Bad news: That's not by overwhelming your mind with all that stuff that you gonna reach your goals. Worse, you're probably too much stressed and frustrated that you gonna destroy yourself and will be forced to give up. And, for sure, programming is a long-term path. So the idea is to love going through it otherwise you would sooner or later give up.

That's my belief anyway. In that case, I often ask myself: "Would you be able to feel what you feel right now until the end of your life?". Or even more rough: "Do you WANT to repeatedly feel these sensations until you die? Would they make you happy?" If the answer is: "God if I feel like that everyday...", you should reconsider your workflow.

Personally, I can handle a delimited time of huge stress if the goal behind is valuable enough for me. By the way, that kind of situation rarely happens because of a choice but rather of a need. I tend to avoid it because it's painfull (of course) but also because few of my most important goals are short-term goals.

And I think that's the case for most of us. We might want to have the perfect shape for the summer but we would prefer to maintain this perfect shape for the life. Indeed this objective seem ambitious, but that's usually what we really want and that's a bad idea to neglect it.

So ask yourself what really matter for you and if you end up with a long-term goal, consider managing the stress throughout the path.

Conclusion

Enough digression,

The simple ideas I want to remind you are these:

1) You can't learn all the things out there.
2) Because you can't, you have to choose what matter the most for you.

Yes!!! What matter the most for you!
That's why we need to "Keep it simple", because each thing, each kind of useless reflexion that we do is another barrier between us and our goals, or even between us and things that make us happy. We just lose time and energy (i.e our precious ressources that we consume in order to learn, create or achieve other tasks) to consider these kind of superfluous layers above our goals.

Be honest with yourself. Be aware of what you do.
You would be more efficient in your work, more happy and all of this for an extended period of time.

That's it for this article. I hope my thoughts will "resonate" with yours and please, give me a feedback. I'm really exciting about this topic so feel free to give your opinions.

(I hope also that my english was not too bad. If some phrases sound horrible, I'm deeply sorry and I would really enjoy getting some tips ;) )

Thanks for your time and attention.

Should You Always Engage Yourself?

Yann — Thu, 04 Jul 2019 16:28:52 +0000

I guess "Deep Work" is applicable to a lot of domains in our lives but I find out even more important in programming.

I'm currently beginning in this field and like every "self-taught" person, I had to find some stuff to learn. Well. I made some research, typed that cliche phrase: "How to learn code?" and press ENTER...

I got a rush of excitement dude! So many things! I thought I would easily become a genius. But the reality isn't that.

I quickly understood that I can't learn all the stuff out there. So I started to search the best "ressources" (but always free ressources, which seems a bit contrary to the previous goal but I'm a teenager, I don't have money to invest like I want).

After some days, I didn't really focus myself on any sort of ressource because I was still looking for the best "ressources".

That's a real issue for me. I tend to always hesitating between: "Should I deep dive in this?" or "No dude, that's not worse it".

I've read The Attention Diet and I love that idea of consuming long-term content. Most of the time, we need to hardly focus on something for a certain amount of time. That's probably essential to create value and skills.

But I struggle with the fact that at some moments, you just need specific information in order to reach a goal. You don't want to understand a topic from A to Z and engage time and energy for just one information.

That's why I ended up on this thoughts:
→ Either the information you're looking for answer to a precise question (e.g "What's the git command to create a branch?" : git branch
→ Or your question need a broad set of information to answer (e.g "How to do a website?" : erghhhhh...)

In fact you would say : "Sure. But you can decompose that question in smaller questions."
And I would respond : "Ok. But how can you find all the specific enough questions that, regrouped, permit to answer the initial question?"

When you don't know something, you don't know it. That's all.

So, I guess, we need to make this difference.

Conclusion:

When the question you want to answer is specific enough, type in Google and get your answer in order to continue pursuing your goal.
When the question is large, pick 5 minutes max (set a clock if needed) to choose the "long-form content" on your topic that seems the best for you and then, deep dive in it without distractions.

That's it for this article. I hope my thoughts will "resonate" with yours and please, give me a feedback. I'm really exciting about this topic so feel free to give your opinions.

(I hope also that my english was not too bad. If some phrases sound horrible, I'm deeply sorry and I would really enjoy getting some tips ;) )

Thanks for your time and attention.