## L'upload de fichier avec le protocole DDP 

Dernièrement je partageais avec vous ma façon d'organiser mon code lorsque j'utilise **MeteorJS**, vous pouvez retrouver cet article [ici](https://dev-freelance.fr/dev/meteorjs-react-typescript).

Mais comme je vous disais dans cet article, l'utilisation protocole **DDP** risque de casser vos habitudes en matière de communication serveur. Il ne s'agira pas de **REST API** ni de **GraphQL** ! Nous allons devoir nous servir des RPC (Remote Procedure Call). 

Ainsi, je vais vous expliquer comment je m'y prends pour uploader des ressources publiques. Notez que le mot **public** a son importance étant donné que pour une ressource publique, il suffit de le positionner dans un dossier _public/_ à la racine de votre projet **Meteor**.

Ce fichier sera accessible via un appel **HTTP** standard. Nous verrons ultérieurement comment déposer les fichiers dans un dossiers inaccessible, nous forçant ainsi à gérer les accès aux fichiers (plus facile à faire une fois que nous avons mis en place des sessions !).

#### Important à savoir pour les utilisateurs de Meteor Typescript ⚠️

Lorsque vous travaillez en **Typescript**, votre code est compilé. Donc au runtime, votre interpreter se positionne dans le dossier **.meteor** qui contient le build du projet. Ce qui signifie que parcourir les dossiers et fichiers depuis cet endroit peut s'avérer fastidieux !

C'est pourquoi il y a des variables d'environnement pour nous aider à nous repérer plus facilement au niveau des paths. Nous utiliserons : **process.env.PWD**

### Preparons notre API pour l'upload

Commençons par créer un dossier **/public** à la racine de notre projet et dans ce même dossier, ajoutons un fichier **.keep** pour pouvoir ensuite faire les règles **.gitignore** nécessaires : 

```
# gitignore
public/
!public/.keep
```
Maintenant tout ce que vous uploadez ne sera pas versionné (évitons d'envoyer des fichiers binaires sur git... 😅).

```tsx
// /imports/api/file.ts
import { Meteor } from 'meteor/meteor'
import * as fs from 'fs'
import path from 'path'
import { v4 as uuid } from 'uuid'

const FILES_PATH = path.resolve(process.env.PWD ?? '', 'public/files')

type UploadedFile = {
  mimeType: string
  name: string
}

Meteor.methods({
  'file.upload'(
    file: UploadedFile, // Changement de type car le File Object ne passe pas via RPC
    fileData: any // Ici nous passons les données binaires en raw
  ) {
    if (Meteor.isServer) {
      // On donne un nom unique à notre fichier uploadé
      const fileName = uuid()
      const filePath = path.resolve(FILES_PATH, `${fileName}.${file.mimeType?.split('/')?.[1]}`)

      // On écrit notre fichier dans notre répertoire
      fs.writeFileSync(filePath, fileData, 'binary')
      
      // ... Ici je fais les écritures DB nécessaires (à personnaliser) 
      
      // On retourne le nom du fichier uploadé
      return `${fileName}.${file.mimeType?.split('/')?.[1]}`
    }
  },
})

```

Mise à jour du fichier **api/index.ts** : 

```tsx
// imports/api/index.ts

// ...
import './file'
// ...
```

### Côté formulaire client

Sur notre page, nous allons ajouter un **input file** pour gérer l'envoi du fichier :

```tsx
// pages/page.tsx

//...

type MaPageProps = {
  uploadFile: (f: File) => void
}

const MaPage = ({ uploadFile }: MaPageProps) => {
  return (
    /* ... form inputs */
    <div>
      <label htmlFor="name">
        Photo
      </label>
      <input type="file" onChange={e => uploadFile(e.currentTarget.files?.[0])} />
    </div>
  )
}

export default withTracker(() => {
  return {
    uploadFile: (file: File) => {
      if (file) {
        const reader = new FileReader()
        
        reader.onload = function () {
          Meteor.call(
            'file.upload',
            // File to Object pour le RPC
            {
              mimeType: file.type,
              name: file.name,
            },
            // Raw binary data
            reader.result,
            (err: any, fileName: string) => {
              if (err) {
                console.log(err)
                return error()
              }
              alert('Fichier uploadé')
              console.log(fileName)
            }
          )
        }

        reader.readAsBinaryString(file)
      }
    }
  }
})(MaPage)
```

### Affichage du fichier uploadé sur la page

Une fois le fichier uploadé, puisqu'il s'agit d'un fichier public. 
Je pars du principe que vous avez fait les stockage DB nécessaires. Une fois que vous récupérez votre collection via des requêtes, il ne vous reste plus qu'à l'afficher. Vous pouvez tester avec une URL en dur juste pour vérifier que votre fichier est accessible.

Si votre dossier public est organisé de la sorte :

```
/public
|_/img
   |_picture.jpg
```

Il ne vous reste plus qu'à faire un essai : 

```tsx
// /pages/index.tsx

const pictureUrl = "/img/picture.jpg";

// ...
<img src={pictureUrl} />
```

Dans un prochain article on parlera de la pagination de données sur les requêtes de collection. D'ici là, portez vous bien, bon code ! 😉

mike-van-den-bos-jf1EomjlQi0-unsplash.jpg

large_mike-van-den-bos-jf1EomjlQi0-unsplash.jpg

medium_mike-van-den-bos-jf1EomjlQi0-unsplash.jpg

small_mike-van-den-bos-jf1EomjlQi0-unsplash.jpg

thumbnail_mike-van-den-bos-jf1EomjlQi0-unsplash.jpg

MeteorJS est une plateforme fullstack qui de part sa conception et l'utilisation du Distributed Data Protocol (DDP) change l'approche en matière de communication front/back. Comment faire pour gérer l'upload de fichiers dans ces conditions ?

Comment uploader fichiers publics avec Meteor.js

## Organiser le code avec Meteor 

**Meteor.js** s'appuie sur Node.js et intègre nativement plusieurs fonctionnalités et librairies, tels que MongoDB, les sockets, etc...  

Il s'agit d'une plateforme fullstack qui permet de coder à la fois le front et le back dans des fichiers partagés qui peuvent être importé de n'importe où. C'est pourquoi il faut souvent vérifier dans le code où est-ce que l'on se positionne avant d'exécuter un code uniquement backend ou uniquement frontend.

![meteor-js ><](https://bo.dev-freelance.fr/uploads/meteor_js_7dd27b0515.png)

Pour savoir si le code est exécuté coté client on fait : 

```tsx
import { Meteor } from 'meteor/meteor'

if (Meteor.isClient) {
  // ... code exécuté uniquement sur le client
}
```

Pour le serveur, ce serait : 

```tsx
import { Meteor } from 'meteor/meteor'

if (Meteor.isServer) {
  // ... code exécuté uniquement sur le serveur
}
```

### Comment s'effectue sa communication backend/frontend ?

Meteor fait communiquer ces deux briques via ce qu'il appelle le protocole **DDP** (pour **Distributed Data Protocol**) qui utilise à la fois : 

- du RPC (**Remote Procedure Call**)
- le fait de pouvoir souscrire à des événements
- faire des stream etc...

Comprenez bien que ce protocole cadre énormément les choses par la suite !

Cela signifie que globalement vous ne ferez pas de **REST API** (même si vous pouvez en faire via des extensions), de même vous ne ferez pas de **GraphQL** (même si vous pouvez en faire via des extensions  😅).

Ainsi cela implique moins d'intervention sur la partie routing du projet, l'organisation se fera ailleurs via : 

- **La publication de données** : **Meteor.js** permet d'exposer une partie des données DB côté front (en lecture uniquement), on peut faire des requêtes directement depuis la partie cliente, mais à condition d'avoir autorisé le dataset et avec des pré-conditions de filtres (par exemple une clé ownerId ou companyId serait forcée côté client pour empêcher de requêter des données dont on est pas propriétaire). Côté serveur toutes les données restent accessibles... Ingénieux ! 🧐
- **La création de méthodes** : Le server défini un certains nombres de fonctions server-side que l'on peut appeler avec certains paramètres pour qu'il exécute du code non exposé au front. Généralement on y met les opérations d'écritures vers la base de données, écriture de fichiers, appels API, etc...
- **L'appels de ces méthodes** : Le client peut appeler les server-side methods et exécuter des insertions en base de données, des updates, etc. via l'utilisation de Meteor.call.

###  L'influence du DDP de Meteor sur l'organisation !

Autre plateforme, autre méthodo, je vous propose mon approche lorsque je travaille sur un projet **Meteor**. Cela demande de l'organisation afin de ne pas perdre ses repaires car nous sortons des sentiers battus.
Dans cet article, je ne mentionnerai pas la définition des types qui doit être faite en amont (la base de **Typescript** !).

#### Préparation du code Meteor.js côté server

On défini notre collection Mongo :

```tsx
// /imports/api/products.ts

import { Meteor } from 'meteor/meteor'
import { Mongo } from 'meteor/mongo'

export const ProductCollection = new Mongo.Collection<Product>('products')
```
J'utilise le fichier index pour centraliser tous les modèles et permettre de faire un import unique sur mon module serveur plus tard.

```tsx
// /imports/api/index.ts
// On exporte nos modèles ici

// ....
export { ProductCollection } from './products'
```

Il est temps d'exposer nos données sur le frontend, mais ceci ne se fait pas sans une sécurité préalable !
Ici nous exposerons uniquement les produits appartenant à une même compagnie sur le frontend.
Ce filtre sera appliqué par défaut pour toutes les requêtes DB qui arrivent du client. De même si l'on ajoute des conditions supplémentaires, elles viendront s'ajouter à celles existantes sur ce qui a été publié.  

Par exemple : companyId = 'ABCD' + name = 'clé usb'

Idem pour la pagination, les skip etc...

```tsx
// /imports/api/published/product-publ.ts

import { Meteor } from 'meteor/meteor'
import { ProductCollection } from '../product'

Meteor.publish('products', function (companyId: string) { 
  if (!companyId) return null
  return ProductCollection.find({
    companyId
  })
})
```
Le fichier index du dossier published permet de centraliser tous les sous-modules : 

```tsx
// /imports/api/published/index.ts

import './product-publ'
```

Enfin nous importons tout cela dans notre Meteor server :

```tsx 
// /server/main.ts

import '/imports/api/published'
import '/imports/api'
```

#### Préparation du code Meteor.js côté client

Lorsque j'utilise **Meteor**, je gère les pages avec un **react-router** traditionnel. Mais j'organise toujours mes pages de manière à exporter le composant avec un **Higher Order Component** (appelé aussi **HoC**) qui permet de lier la partie vue à la couche de données et de souscrire aux événements (à la manière d'un redux connect). 

Pratique pour le côté temps réel 👌! 

```tsx
// /imports/pages/products.tsx

import * as React from 'react'
import { useFind, useSubscribe, withTracker } from 'meteor/react-meteor-data'
import { ProductCollection } from '/imports/api' // On expose l'objet Mongo sur le front

type ProductsPageProps = {
  products: Products[]
}

function ProductsPage({ products }: ProductsPageProps) {
  return (
    <table>
      <thead>
        <tr>
          <td>Name</td>
          <td>Price</td>
        </tr>
      </thead>
      <tbody>
        {
          products.map((product: Product, index: number) => {
            return <tr key={index}>
              <td>{product.name}</td>
              <td>{product.price} €</td>
            </tr>
          })
        }
      </tbody>
    </table>
  )
}

// Mapping avec les données
export default withTracker(() => {
  // Hook de récupération de ma société (cookie ou session ou localStorage...)
  const { activeCompany } = useCompany()
  // On souscrit aux produits pour pouvoir les requêter
  const isLoading = useSubscribe('products', activeCompany) 
  
  
  const products = useFind(
    () => ProductCollection.find({}),
    [ ]
  )

  return {
    products 
  }
})(ProductsPage)
```

### Les sauvegardes en base de données avec Meteor

Toujours dans notre fichier d'api, pour la partie serveur, nous allons ajouter une méthode **Meteor** afin d'insérer la donnée en base : 

```tsx
// /imports/api/products.tsx

import { Meteor } from 'meteor/meteor'
import { Mongo } from 'meteor/mongo'

export const ProductCollection = new Mongo.Collection<Product>('products')

Meteor.methods({
  'product.create'(companyId: string, data: Product) {
    try {
      return ProductCollection.insert({
        ...data,
        companyId
      })
    } catch (err) {
      console.log(err)
    }
  }
})
```

Côté vue, on se crée une page de formulaire. Personnellement j'utilise react-hook-form, mais je reviendrai un peu plus en détail sur cette librairie dans un prochain article.

```tsx
// /imports/pages/product-add.tsx

import * as React from 'react'
import { useSubscribe, withTracker } from 'meteor/react-meteor-data'
import { useNavigate, useParams } from 'react-router-dom'

type ProductAddPageProps = {
  onSubmit: (data: Partial<Product>) => void
}

function ProductAddPage({ onSubmit }: ProductAddPageProps) {
  // ... formulaire sur lequel j'attache mon submit
})

export default withTracker(() => {
  const navigate = useNavigate()
  const { activeCompany } = useCompany()
  
  return {
    onSubmit: (data: Product) => {
      Meteor.call('product.create', activeCompany, data, (err: any, productId: string) => {
        alert('Product inserted')
        navigate('/products')
      })
    }
  }
})(ProductAddPage)
```

A ce stade vous savez faire de la lecture/écriture en base avec **Meteor.js** **React** et **Typescript**.

Dans de prochains articles nous verrons comment gérer les uploads et la pagination de données. Stay tuned ! 😃


large_tasos-mansour-ndWAEhY_w20-unsplash.jpg

medium_tasos-mansour-ndWAEhY_w20-unsplash.jpg

small_tasos-mansour-ndWAEhY_w20-unsplash.jpg

thumbnail_tasos-mansour-ndWAEhY_w20-unsplash.jpg

tasos-mansour-ndWAEhY_w20-unsplash.jpg

Meteor est une plateforme js fullstack qui fait sa vie depuis bientôt 10 ans avec une communauté plutôt active. Son principal avantage est son approche reactive, Meteor.js se veut être une plateforme temps réel. Il accepte la syntaxe Typescript et permet de coder les vues en React depuis quelques années déjà. Que demander de mieux ?

Meteor.js avec React et Typescript

## Un blog avec Next.js et Strapi

Ces technologies ont la particularité d'avoir une communauté active et présente, et m'ont permis d'accélérer le développement de ce blog personnalisé. J'ai pu m'appuyer sur des bases existantes solides et me concentrer sur la personnalisation de l'affichage, du contenu, etc.

### Typescript, une course à la stabilité

Cette plateforme aura pris exactement deux semaines pour voir le jour. Alors, effectivement mon temps était sporadiquement utilisé sur ce projet personnel, le soir et les week-end et finalement, le projet a vu le jour assez rapidement. 

Le gros du changement concerne le langage utilisé pour coder la plateforme, on est passé de **Javascript** à **Typescript** qui est tout de même beaucoup plus fiable en matière de livrable. Cela signifie tout simplement que pour chaque feature livré, je n'ai pas ou quasiment pas eu à intervenir de nouveau pour fixer quelque chose.

Effectivement, on est sur une courbe de rendement (similaire à une courbe d'apprentissage), c'est à dire que pour produire quelque chose en **Typescript**, on fourni un peu plus d'effort, mais le résultat obtenu est très robuste et satisfaisant. 

Par ailleurs, nous avons pu faire cela en un délai record, grâce à **Strapi** utilisé dans sa version beta, elle aussi en **Typescript** !

Pour ceux qui ne connaissent pas [Strapi](https://strapi.io/v4), je vous recommande leur documentation ici, ainsi que pour [Next.js](https://nextjs.org/).

### Ce moteur de blog que fait-il de plus que les autres ?

Alors, il s'agit d'un moteur de blog avec **Strapi** utilisé comme backoffice, mais à la différence d'autres moteurs existants sur le marché tel que **Wordpress** ou **Joomla**, il est beaucoup plus flexible (en tout cas pour un développeur). 

Voici une liste des avantages : 

- Flexible (possibilités sans limite, vente de produits, contenu multimédia, etc...)
- Robuste (grâce à **Typescript**, j'imagine qu'il y a de petites choses à corriger, mais globalement pas de bugs)
- Rapide, grâce à notre **caching** sur mesure (entre 2 rafraîchissement je suis à 100ms parfois)
- Composants **React** (qui fera plaisir aux développeurs)
- **Responsive** nativement (oui j'ai codé 100% du thème dans un style clair et sobre grâce à **Tailwindcss**, sans utiliser de template ou autre)

Le blog prend alors ici des allures d'applications si on le souhaite, car on a les pleins pouvoirs et main mise sur le code source. 

### Quelles sont les fonctionnalités de ce blog ?

Le blog dev-freelance se devait de fonctionner comme tout type de blog, à savoir : poster du contenu et recevoir du feedback. C'est pourquoi, j'ai rapidement conçu un module de commentaires. Il est donc possible de s'inscrire sur le blog afin de poster des commentaires, réagir aux autres commentaires, de liker les articles...

Ce module commentaire a pu être intégré au sein même de **Strapi**, afin d'éviter de cumuler plusieurs backend pour le faire. J'ai créé les modèles de données, personnalisé certains endpoints et le tour était joué. Ce n'est pas la partie la plus difficile tant la documentation de **Strapi** est détaillée. Dans le cas contraire, vous avez énormément de supports sur internet (**github**, **stackoverflow**, etc.).

![module-commentaire-strapi ><](https://bo.dev-freelance.fr/uploads/ezgif_2_b62652a7fe_e756a2f644.gif)

J'ai aussi intégré mon système de **captcha** sur-mesure afin de parer à toute éventualité contre les bots d'internet (croyez-moi ils sont légion). Je constate tout de même que j'ai quelques optimisations à faire sur mobile, notamment sur les ratios d'image, mais cela reste potable.

![module-captcha-nextjs ><](https://bo.dev-freelance.fr/uploads/ezgif_2_49eb59a6f0_42b0dfec3f.gif)

L'intégration de contenu multimédia en passant par les vidéo **youtube** ou les audio de **soundcloud**.

![dev-freelance-blog ><](https://bo.dev-freelance.fr/uploads/ezgif_4_becc89aec0_2d4728ddab.gif)

### Quel projet après celui-ci ?

Maintenant que le blog semble assez stable, que ce soit pour la partie email, contenu, etc, il me reste tout de même quelques pages que j'aimerais ajouter comme la gestion du compte utilisateur. Et probablement encore du travail à effectuer pour optimiser le blog pour la SEO. 

En outre, je ne vous cache pas que j'ai encore beaucoup d'autres projets en cours, sur lesquels j'avance petit à petit et que j'ai hâte de sortir. Petit teaser, il y a des projets en **Meteor Typescript**, d'autres projets en **Next.js**... Bref encore beaucoup de challenge en perspective.


fotis-fotopoulos-6sAl6aQ4OWI-unsplash.jpg

large_fotis-fotopoulos-6sAl6aQ4OWI-unsplash.jpg

medium_fotis-fotopoulos-6sAl6aQ4OWI-unsplash.jpg

small_fotis-fotopoulos-6sAl6aQ4OWI-unsplash.jpg

thumbnail_fotis-fotopoulos-6sAl6aQ4OWI-unsplash.jpg

Vous vous en êtes peut-être rendu compte, cela fait un certain temps que j'ai basculé le blog qui était initalement codé dans un moteur 100% custom en Node Express Handlebars, sur cette plateforme codée en Next.js Strapi full Typescript avec bien évidemment du React pour la partie frontend. En dehors des technologies, que propose cette plateforme ?

Petit point technique sur le blog

## Réduire la taille du bundle généré par Next.js

Lorsque l'on importe nos composants dans nos pages de cette façon : 

```tsx
import {
  ComponentA,
  ComponentB,
  ComponentC
} from '@components'

// ...
```

Ce qu'il se passe réellement lors de la construction du bundle (**next build**), c'est que **webpack** resolve l'intégralité du fichier @components/index. 

En d'autres mots, si vous exportez aussi ComposantD, ComposantE, etc... ils seront dans le source code compilé de la page, même s'ils ne sont pas utilisés.

Il s'agit du comportement standard de **webpack**, tout ceci est normal. Même si cela peut nous porter préjudice : 

![next-build-non-optimized ><](https://bo.dev-freelance.fr/uploads/Capture_d_ecran_de_2022_06_28_22_34_46_313c923aba.png)

Nous devons alors, demander à **webpack** de purger le code inutilisé pour nous. Cette opération s'appelle faire du **tree shaking**, je vous invite à voir [la documentation de webpack](https://webpack.js.org/guides/tree-shaking/) d'un peu plus près.

### Première solution pour optimiser notre bundle Next

Une solution un peu plus longue, en fonction de la densité de votre code consiste à isoler les imports de chaque composant. Ainsi, vous aurez une ligne par composant et cela risque de prendre un peu de place : 

```tsx
import { ComponentA } from '@components/component-a'
import { ComponentB } from '@components/component-b'
import { ComponentC } from '@components/component-c'
```

J'entends que cette solution peut être fastidieuse à mettre en place, surtout si votre projet comporte énormément de pages et de composants.

Mais le jeu en vaut la chandelle : 

![next-build-optimized ><](https://bo.dev-freelance.fr/uploads/Capture_d_ecran_de_2022_06_28_22_34_56_6732e95352.png)

Dans notre cas, nous obtenons un gain de 16% par rapport au premier build.

### Une solution plus laxiste pour optimiser la taille du bundle Next.js

Cette seconde méthode n'est pas forcément la plus propre et ne vous permettra pas d'avoir une réelle maîtrise de tout ce qu'il se passe en dessous, mais elle aura l'avantage de vous faire gagner du temps. 

Cette méthode consiste à ajouter une ligne de configuration dans votre **package.json** afin de préciser à webpack comment effectuer son build.

```js
{
    ...
    "sideEffects": false
}
```

Et voilà, le tour est joué, vous aurez à peu près le même résultat, voire le même résultat lors du build. En revanche, ici, nous précisons juste à **webpack** de supprimer le deadcode lors du build. En théorie, cela devrait suffire mais nous ne sommes pas à l'abris d'un imprévu étant donné que nous n'avons pas manuellement exclus ce qui semble "inutilisé".

On a souvent tendance à minimiser l'impact du poids des pages sur la performance de notre site, mais à tord. Il a été maintes et maintes fois démontré que les sites les plus lents perdent du trafic, sans doute à cause de l'impatience des utilisateurs, à qui les moyens actuels (fibre, serveurs performants, 5G, etc...) apportent encore plus de confort.

large_saffu-E4kKGI4oGaU-unsplash.jpg

medium_saffu-E4kKGI4oGaU-unsplash.jpg

small_saffu-E4kKGI4oGaU-unsplash.jpg

thumbnail_saffu-E4kKGI4oGaU-unsplash.jpg

saffu-E4kKGI4oGaU-unsplash.jpg

Lorsque l'on organise son code, on a tendance à regrouper les composants dans un dossier, et souvent on exporte l'intégralité des composants via un fichier index. Sans le savoir voici ce qu'il se passe...

Optimisation des imports en Next.js

## ReactJS, un besoin d'organisation

Contrairement à d'autres libraries frontend comme **Angular**, **React** donne beaucoup de liberté aux développeurs pour organiser le code. Mais il est difficile de s'y retrouver si plusieurs personnes travaille avec des méthodologies différentes. **Redux** a apporté une façon d'organiser le code via des événements nommés et connus d'avance. Cependant le code à mettre en place avant de pouvoir le faire est assez dense. Et son utilisation au quotidien peut s'avérer problématique tant il est compliqué d'ajouter de nouveaux événements ou namespaces au fonctionnement existant.

### Comment s'organise le code avec Redux

Depuis que les développeurs frontend se sont mis à **React**, nombreux ont été les tentatives d'organisation du code autour d'un flow qui permet de gérer les états et les changements d'états. 

Dans tout cela, Redux a sorti son épingle du jeu en proposant une approche basé sur des stores de données qui écoutent des événements précis afin de changer d'état. Cependant, sa mise en place n'est pas des plus simple. Cela demande une organisation des fichiers sources, la création de chacun des états et la gestion de chacun des événements. 

Sans compter le fait que les composants qui utilisent ce store doivent être wrappé dans une fonction qui permettra de déclencher un re-render au moment d'un événement. Et que chaque composant doit être attaché au store pour pouvoir utiliser un état de ce dernier. Bref une mise en place qui une fois qu'on s'est habitué n'est pas si compliqué, mais qui demeure complexe à mettre en place et à organiser.

Chaque nouvel événement implique la création de ce dernier et se doit de spécifier comment va réagir le store de donnée en fonction des événements. Toute cette organisation demande surtout énormément de temps, que finalement on en passera pas à créer des features, mais plutôt à organiser notre code et essayer au maximum de gérer side-effects des événements cross-stores... 

![redux-flow ><](https://bo.dev-freelance.fr/uploads/redux_1_drawio_94d90142bc.png)

**Le temps passé à mettre en place l'architecture redux vous coûte cher à l'échelle d'un projet complexe.**

### La mauvaise méthode pour remplacer Redux

La solution à l'ancienne pour impacter un child sans utiliser redux était de créer un state à haut niveau sur un parent element, et passer les getter/setter en props à chaque composants. Ce pattern s'appelle le **props-drill pattern**.

En revanche, vous imaginez bien les limites de ce modèle, il s'agit de passer toujours de plus en plus de props à chaque composants intermédiaire et ses composants imbriqués. 

Pour vous donner une idée : 

![react-props-drill-pattern ><](https://bo.dev-freelance.fr/uploads/redux_2_drawio_579ef0919e.png)

Et en implémentation simplifiée cela donnerait quelque chose comme ça : 


```tsx
import * as React from 'react'

type User = {
  name: string
  age: number
}

type ParentContainerProps = {
  children: React.ReactNode
}

// Mock data fetch
const ConnectUser = (cb: (u: User) => void) => {
  cb({
    name: 'John Doe',
    age: 30
  })
}

// parent-container.tsx
const ParentContainer = ({children}: ParentContainerProps) => {
  const [user, setUser] = React.useState<User | null>(null)
  return (
    <div>
      <UserContainer user={user} setUser={setUser} />
      {children}
    </div>
  )
}

// user-container.tsx
const UserContainer = ({ user, setUser }: { 
  user: User|null, 
  setUser: (u: User) => void 
}) => {
  // Fetch data
  React.useEffect(() => {
    ConnectUser((connectedUser: User) => setUser(connectedUser))
  }, [])
  return user ? (
    <div>
      {user.name} - {user.age} ans
    </div>
  ) : null
}

export default ParentContainer
```

On constate que chaque composant doit avoir les props qui permettent de manipuler un user et se doivent de le passer à chaque child qui en a aussi besoin. Ce pattern est d'autant plus problématique qu'en Typescript, s'il s'agit d'une donnée que l'on récupère de manière asynchrone, cela implique qu'il risque d'être null ou changer d'état.

### Une meilleure approche pour remplacer Redux

Depuis que l'on utilise majoritairement des functional components et des hooks, la manière de faire a changé. Désormais, on emploie le **Provider/Context pattern**. 

La mise en place de ce pattern consiste à wrapper le code dans un Provider. Et comme ses enfants viendront consommer son context, il pourra ainsi gérer le re-render des composants si besoin. 

Pour rendre mon code réutilisable, je passe par les hooks pour isoler les getters, setters. Ainsi seuls les hooks viendront consommer les contexts (aucune lecture en direct) et les composants consommeront les hooks.

![react-provider-context-pattern ><](https://bo.dev-freelance.fr/uploads/redux_3_drawio_b8cda10bc0.png)


```tsx
import * as React from 'react'

type User = {
  id: number 
  username: string
  age: number
  email: string
}

// /context/user-context.tsx
type UserContextValues = {
  connected: boolean
  setConnected: (c: boolean) => void
  userInfos: User
  setUserInfos: (u: User) => void
}

export const UserContext = React.createContext<UserContextValues>({
  connected: false,
  setConnected: () => void,
  userInfos: {
    id: null,
    username: '',
    age: '',
    email: '',
  },
  setUserInfos: () => null,
})

export const UserProvider = ({ children }: { children: React.ReactNode }) => {
  const [connected, setConnected] = React.useState(false)
  const [userInfos, setUserInfos] = React.useState<User>({
    id: null,
    username: '',
    age: '',
    email: '',
  })

  // Get our user
  React.useEffect(() => {
    if (!connected) {
      fetch('/my/user/api/endpoint')
        .then(res => res.json())
        .then(user => {
          setUserInfos(user)
          setConnected(true)
        })
        .catch(err => console.log(err))
    }
  }, [connected])

  return (
    <UserContext.Provider
      value={{
        connected,
        setConnected,
        userInfos,
        setUserInfos,
      }}
    >
      {children}
    </UserContext.Provider>
  )
}

// /hook/use-get-user.tsx
export const useGetUser = () => {
  const { userInfos } = React.useContext(UserContext)
  return userInfos
}

// /components/user-card.tsx
export const UserCard = () => {
  const user = useGetUser()

  return user ? (
    <div className="card">
      <h3>{user.username}</h3>
      <p>{user.age} ans<p>
    </div> 
  ) : null
}

// app.tsx
// ...
return (
  <UserProvider>
    <App />
  </UserProvider>
)
```

Comme on peut le voir, la deuxième méthode est beaucoup plus propre et malgré un plus grand nombre de fichiers à créer, cela reste une approche simple pour accéder à des données centralisées à la manière d'un redux.

lautaro-andreani-UYsBCu9RP3Y-unsplash.jpg

large_lautaro-andreani-UYsBCu9RP3Y-unsplash.jpg

medium_lautaro-andreani-UYsBCu9RP3Y-unsplash.jpg

small_lautaro-andreani-UYsBCu9RP3Y-unsplash.jpg

thumbnail_lautaro-andreani-UYsBCu9RP3Y-unsplash.jpg

React a changé notre vision du développement applicatif. Depuis sa sortie, cette librairie a connu plusieurs modifications, que ce soit le langage ES5, puis ES6, puis Typescript, etc... Redux avait apporté un brun d'organisation dans toute cette tambouille mais, avec un niveau de complexité non négligeable.  Voici une méthode pour y voir plus clair.

Pourquoi je préfère me passer de Redux 

## Quelques astuces pour bien progresser en tant que développeur web

Pour faire suite [au précédent article sur le développement](https://dev-freelance.fr/dev/mes-conseils-de-developpeur-partie-1), voici encore quelques conseils pour vous améliorer en développement.

### 1 - Tester son code

Cela demande du temps de tester en permanence les itérations de votre code source. Mais cette étape est très importante ! Elle assure le bon fonctionnement - parcours prévu, résultat attendu - de votre code.

Il y a plusieurs façon de tester son code : les TU (tests unitaires) souvent réalisé par les développeurs eux-mêmes.  

Il s'agit d'isoler une petite partie du code et tester son fonctionnement. On le fait généralement avec les fonctions que l'on peut tester directement via ses I/O (entrées, sorties). En gros on l'appelle avec des paramètres et on vérifie que la réponse est cohérente et qu'il s'agit bien du résultat attendu, ou comportement attendu s'il s'agit d'un void (fonction sans retour).

Pendant longtemps, les boîtes ont encouragé les développeurs à avoir un fort niveau de coverage, c'est à dire plus de teste sur une plus grande partie du code. Plus le coverage est élevé plus l'entièreté du code est testé. Or, d'expérience, c'est parfois contre-productif de le faire. Je dirais qu'il faut tester essentiellement les logiques complexes et avoir environ 60 à 65% de coverage est déjà largement suffisant.

Au delà, on passe surtout énormément de temps à maintenir les tests, moins à développer des features, en sachant que des langages comme Typescript (mon petit chouchou), règle déjà énormément de problèmes en amont.

Les TU restent cependant terriblement efficaces, a tel point qu'on en a fait une méthodologie de travail : le TDD (test-driven development). Ce qui signifie que l'on va commencer par implémenter les tests avant même de faire le code. 

Par exemple,  je dois faire une fonction qui doit multiplier un entier passé en argument par 2. 
Cette fonction s'appelle multPer2. 
Je commence par faire un test qui vérifie que le résultat est bien égal au double de mon entrée.
Avec les libs de tests assez connu tel que Jest, ça donnerait cela :

```js
describe('test libs', () => {
    it('Should multiply per 2', () => {
        var result = multPer2(2)
        expect(result).toEqual(4)
    })
})
```

Dans ce test, on vérifie que le résultat est égal à 4. Dans le cas contraire, le test renverra une erreur.
Maintenant une fois que les tests sont prêts, je peux commencer à coder ma fonction, le but du jeu est de faire tourner les tests (automatiquement si possible) jusqu'à ce que tout soit ok.

```js
function multPer2(inp) {
    return 2 * inp
}
```

Pour tester le front (des composants react par exemple) ce n'est pas si simple. En général, on utilisera des outils qui permettront de générer un fake DOM et de simuler des timers, pour les lifecycle de render (comme jest, react-testing-library, etc...). Mais ils ne sont pas simple à prendre en main, et si votre composant connait énormément de mutation d'état pour X ou Y raison, cela risque d'être difficile à tester. Mais rassurez-vous il y a des outils spécifiques pour ça : les tests E2E.

Les tests E2E (end-to-end) sont généralement implémentés (code ou no code) par les QA testeurs, donc des profils dédiés à ce type de tests. Mais dans certaines équipe il n'est pas rare que ce soit les développeurs eux-mêmes qui implémentent les E2E. Aujourd'hui, le marché propose de nombreux outils intéressants comme : Cypress ou Playwright et il y a de quoi faire !

Ou au moins testez à la main ce que vous faites, c'est un minimum. De même, si vous relisez la PR d'un collègue, prenez le temps de réellement tester les choses et ne validez pas uniquement en ayant lu sur GIT à moins que ce soit du code très simple CSS, etc... Prenez le temps de le faire.

### 2 - Anticiper le comportement du code

Lorsque vous prenez de l'expérience, vous serez en mesure d'anticiper plus facilement sur la complexité de ce que vous allez implémenter. 
Instinctivement, vous saurez d'avance : 

- quand est-ce qu'une implémentation risque de vous donner du fil à retordre
- quand est-ce qu'une valeur en entrée risque de changer
- pourquoi le code risque de ne pas s'exécuter
- pourquoi une partie de votre code est exécuté avant ou après telle ou telle action
- pourquoi le résultat obtenu risque de ne pas être correct

Maintenant, utilisez votre expérience pour prévenir ce genre de problèmes. Puisque vous savez que cela peut arriver, et que vous êtes en mesure de comprendre pourquoi. Il est possible de mettre en place des gardes-fous.

**Votre expérience ne doit pas vous servir uniquement à coder plus vite, mais surtout à coder mieux.**

J'ai des règles d'organisation et d'anticipation qui globalement fonctionnent très bien et me permet de dormir sur mes deux oreilles.

Voici ma méthodologie :

**La base :**

- J'organise toujours mon code de manière à savoir exactement où est positionné telle ou telle brique. Il faut que je n'ai pas à réfléchir pour retrouver un composant, une lib, une page, les configs, etc...
- Je n'inclus jamais les clés API, tokens et les endpoints au code source, car le code n'est pas hébergé sur ma propre machine. Dans un data center qui sait ce qui peut arriver ? Les sociétés comme Github, Bitbucket et autre ne sont pas à l'abris d'un hack de la couche 0... (l'humain, les employés eux même !). J'utilise l'environnement sans versionner le fichier .env

**Plus technique :**

- Je pars du principe que tout ce qui est externe a mon code n'est pas fiable, donc je redouble d'effort sur les vérifications de ces données. Par exemple une API peut ne pas répondre, changer de format de réponse, etc..., donc, je prends les devant et je vérifie que je dispose des éléments qui me permette de continuer à processer, dans le cas contraire, je m'arrête avant de générer des erreurs ou faire crasher mon programme.
- Lorsque je code du frontend, je réduis au maximum le nombre de composants qui font des calculs ou manipulent des données. En général, je crée le maximum de dumb components, destinés uniquement à faire de l'affichage. Et j'effectue des appels API et des opérations uniquement dans certains fichiers ciblés. Cela me permet en cas de dysfonctionnement de savoir exactement où effectuer une action.
- Je factorise au maximum les utilisation commune ou les schéma commun dans mon code, cela me permet de réduire mes efforts en cas de modification car plusieurs éléments seraient modifiés simultannément.
- Je dissocie la partie API (récupération de données) de la partie exploitation de ces données, afin de ne pas avoir de comportement trop spécifique sur ma brique la plus commune. Par exemple, je traite la réponse d'API et affiche des toasters etc... à l'endroit ou j'appelle ma librairie d'API et pas directement dans la lib.
- Sur les gros projets, je distingue fortement le traitement synchrone du traitement asynchrone. C'est à dire que je préfère garder sur mon API ce qui est vital pour que l'utilisateur puisse avoir le maximum de confort (temps de réponse courts, données essentielles, etc...). Et toute la partie traitement (stats, compteurs, cache, etc...) je le fais via d'autres threads que j'appelle les Workers.  
- Je privilégie toujours la lisibilité plutôt que la sur-optimisation. Biensûr dans certains cas, je préfère optimiser afin de ne pas trop multiplier les instructions et ralentir le code. Mais si cela rend le code plus lisible pour mes collègues, je prends le temps de montrer certaines opérations de manière plus explicite afin d'être plus clair et plus facile à appréhender.

### 3 - Surmonter ses peurs en programmation

A chaque fois qu'un sujet technique vous angoisse, car il vous parait complexe, soyez sûr que si vous le maîtrisez vous apprendrez quelque chose. 

Les outils à disposition des développeurs n'existent pas par hasard. Très souvent, ils sont le fruit de recherches et de travaux destinés à simplifier la vie du développeur.

Par exemple, combien de condition "if" vous faut-il pour remplacer une seule et unique RegExp ? 

Combien d'indentation vous faut-il utiliser dans une série de Promise, au lieu d'utiliser l'async/await ?

Une chose est sûr, cela m'a toujours été bénéfique d'apprendre de nouvelles choses. Et cela devrait être un sujet excitant et pas repoussant. 

Prenez le temps d'appréhender et de tester les nouveaux outils et les nouvelles méthodos. Si les gens en parlent, c'est qu'il y a forcément un intérêt qui a été décelé par développeurs.

Le plus simple est d'intégrer cet apprentissage à votre routine de veille technique. Une partie de votre temps doit impérativement être destiné à la veille technique et doit vous permettre de tester ces outils.

Même si, vous ne comptez pas vous en servir à terme, il est intéressant de savoir dans quelle situation, cela pourrait vous servir. De même, je vous recommande d'utiliser un outil de note, et de toujours noter une description, un exemple et tagger la note afin de la retrouver plus tard. 

**Votre apprentissage doit vous servir à quelque chose, car si vous ne faites que lire sur le sujet, votre lecture ne vous aura servi à rien si vous n'en avez pas tiré une information.**

### 4 - Intéressez vous aux patterns

Il y a des méthodologie partout et sur tout. Nous cherchons sans cesse le moyen de nous organiser, de faciliter la collaboration, c'est pourquoi, des chercheurs créent chaque jour de nouveau outils, des patterns afin de rendre cela possible.

Qu'est-ce qu'un pattern ?

**Un pattern est une méthode de travail qui va organiser comment implémenter notre code afin de répondre à une ou des problématiques (découpage des tâches, compatibilité, communication, etc...)**

Par exemple un Pattern d'organisation de projet MVC (Model, Vue, Contrôleur) cherche à isoler la complexité de chaque ensemble d'éléments (utilisateurs, produits, ventes, paiements, etc...), en le découpant en 3 axes. Si nous voulons utiliser le pattern MVC pour gérer des utilisateurs, nous ferons : 

- le model qui décrit de quoi est composé un utilisateur, ses champs (nom, prénom, age, etc...)
- la vue, c'est à dire comment on va afficher un ou des utilisateurs
- le contrôleur qui fera le lien entre le modèle, donc l'objet utilisateur au sens code et la base de données. En général le model décrira les actions qui manipulent un modèle utilisateur (créer un utilisateur, mettre à jour un utilisateur, etc...)

Ce pattern a plusieurs avantages, son découpage permet non seulement de réduire la complexité, mais de séparer le travail en plusieurs tâches réalisables par plusieurs collaborateurs. 

Dans notre cas, un intégrateur peut se charger de toutes les vues et un développeur peut se charger des Modèles et Contrôleurs...

Et il existe des milliers de patterns intéressants à connaitre qui permettent de régler beaucoup de problèmes. Certains patterns sont mêmes propre à des langages spécifiques, tel que l'Event-Driven Pattern que l'on peut faire essentiellement en JS, C# ou Java. 

Bien sûr il y a souvent des adaptations de certains pattern dans différents langages mais parfois certains langages s'y pretent mal de par leur conception.

Ainsi, je vous recommande d'en savoir plus sur les patterns afin de toujours faire le choix le plus éclairé dans une situation donnée.

### Conclusion

Globalement, le fait de répéter les mêmes choses chaque jour et de s'intéresser au développement vous aidera naturellement à progresser. 

Ce que je vous recommande pour mettre en place quelque chose de concret est de se donner 1 heure par jour de travail approfondi sur un sujet. Que ce soit une nouvelle techno, un pattern, une librairie etc... Se donner 1 heure même en deux session de 30 minutes (matin et soir) c'est une différence énorme sur une année (plus de 200h). En sachant qu'à chaque heure que vous passez à tester, ou réaliser quelque chose, vous devenez meilleur. 

A vos claviers ! 😃

fotis-fotopoulos-LJ9KY8pIH3E-unsplash.jpg

large_fotis-fotopoulos-LJ9KY8pIH3E-unsplash.jpg

medium_fotis-fotopoulos-LJ9KY8pIH3E-unsplash.jpg

small_fotis-fotopoulos-LJ9KY8pIH3E-unsplash.jpg

thumbnail_fotis-fotopoulos-LJ9KY8pIH3E-unsplash.jpg

Suite au précédent article où je vous parle de comment je me suis amélioré en tant que développeur. Je vous propose de continuer notre progression ensemble en parlant de ce que l'on peut faire pour devenir meilleur.

Mes conseils de développeur partie 2

## Comment s'améliorer en programmation ?

Ce post reprend un précédent podcast que j'avais fait au sujet de s'améliorer en tant que développeur. 
Retrouvez le [podcast audio sur comment s'améliorer en tant que développeur](https://dev-freelance.fr/media/xp2dev---episode-2---comment-devenir-un-meilleur-developpeur). Je tiens à préciser que cet article est un complément du podcast et ne reprend pas tout ce qui s'est dit précédemment, c'est pourquoi je vous recommande de l'écouter avant ou après cette lecture.

La programmation est une compétence qui demande du temps et de la répétition. A la manière d'un instrument de musique, ou d'une activité sportive, en pratiquant vous allez travailler vos réflexes musculaires, votre endurance, votre intelligence dans ce domaine, en revanche, il ne s'agit pas vraiment de travailler vos muscles, mais vous musclerez votre cerveau à le faire. 

Il est indéniable que vous y développerez des automatismes et comme une boule de neige qui devient de plus en plus grosse en roulant, plus vous coderez, plus vous deviendrez meilleur.

Dans le sport, en musique, ou autre domaine de compétence, il y a cependant des exercices que l'on vous conseille de faire afin de travailler votre compétence. J'ai personnellement passé des années à faire et refaire les mêmes choses jusqu'à atteindre un niveau qui me satisfait et qui me permet de satisfaire toute demande. Pour vous donner un exemple, en 2016, je codais 10 heures par jour (en moyenne 260h par mois, soit plus de 3000h cette année là, Noël compris, jour de l'an compris et jours fériés inclus).

Cette année là, j'ai appris plus de choses qu'en 5 ans dans toute ma carrière...

**Après avoir passé des années à coder voici ce que je vous recommande de faire pour exploser vos résultats et votre niveau en développement.**

### 1 - Recoder des petites librairies que l'on utilise au quotidien

Le gestionnaires de paquet npm, composer et autre voire même les repo git sont remplis de projets et de librairies qui répondent à tous les besoins. Très souvent la mise en place de nouveau projet consiste dans les premiers jours à piocher lesquelles de ces librairies nous allons choisir afin de réaliser notre objectif.

**Les librairies comme _lodash_, _uuid_ etc, sont à la portée de n'importe qui !**

On dit souvent qu'il ne faut pas réinventer la roue, mais ce n'est pas tout à fait vrai. Si ça vous prend 2 minutes pour faire quelque chose, faîte-le et commencez à réfléchir lorsque la chose en question vous prend au moins une journée. 

Mon constat après avoir travaillé dans une dizaine d'équipes différentes : les gens savent de moins en moins comment faire les choses et c'est affolant ! Trop de développeurs sont persuadés que si une librairie existe alors elle répond forcément à notre problématique, sans tenir compte du besoin réel, sans se demander s'il n'y a pas de façon plus optimisée de faire quelque chose.

Il y a plusieurs raisons saines pour lesquels il est intéressant de recoder une librairie :

- Comprendre réellement comment les choses fonctionnes (et croyez-moi, cela règle d'avance tous les problèmes que vous rencontrerez ensuite, bugs et autre)
- Entraîner votre logique
- Créer et utiliser uniquement ce dont vous avez besoin, parfois vous utilisez uniquement 5% d'une lib entière, pourquoi alourdir inutilement vos projets ?
- Etre propriétaire du code source (pas uniquement pour faire joli, mais vous maîtrisez réellement votre repo ou votre package et cela évite les hacks et garantie la propriété intellectuel du reste de votre produit)

### 2 - Continuer à coder

Le fait de ne jamais arrêter de coder est un tremplin pour vos compétences. 

**Faites des projets en permanence**

Il y a plusieurs raisons pour lesquels faire vos propres projets :

- Vous faire plaisir sur un sujet qui vous passionne
- Solutionner un problème du quotidien qui vous tient à coeur
- Tester une nouvelle technologie (un langage, un framework) ou une nouvelle méthodologie (une organisation, un outil)

Lorsque vous travaillez sur un sujet qui vous intéresse réellement, vous décuplerez votre énergie. Vous attaquerez chaque session de dev avec une pêche comme jamais auparavant. 

De même, vous serez forcément confronté à des bugs, ou des problématiques et le fait de trouver la solution vous fera progresser. 

**Si augmenter les poids sur une barre vous fait vous muscler davantage, régler des bugs musclera vos compétences de développeur.**

Mon observation du marché du travail depuis des années est la suivante. Lorsqu'une technologie sort, rare sont les sociétés qui adoptent cette dernière directement dans leur projet. Cela a été le cas pour Node.js (tout le monde restait sur du PHP), pour React (tout le monde restait sur du jQuery), etc...

Cela vous laisse le temps, à la sortie d'une technologie qui vous intéresse, de vous familiariser avec cette dernière. Et là ou les recrutements sont parfois un peu vicieux, lors des entretiens 3 ans après la sortie d'une techno, les RH vous demanderont de justifier d'un maximum de temps d'expérience sur cette compétence, en sachant que le marché l'a adopté bien après... la belle blague. En attendant, si vous l'avez utilisé même dans un cadre personnel, vous sortirez votre épingle du jeu !

En regardant de plus près, quel est le plus gros risque d'une société lorsqu'elle décide d'adopter une nouvelle technologie ? 
La réponse c'est la perte de maîtrise. La société a peur de ne plus rien maîtriser en terrain inconnu, c'est pourquoi beaucoup restent sur leurs acquis et préfèrent tabler sur quelque chose de maîtrise. 

Mais qu'est-ce que la maîtrise en définitive ?
La maîtrise c'est avoir déjà échoué, et savoir comment sortir des problématiques (l'expérience !).

Plus vous passerez à l'action en créant, en vous trompant et en recommençant, vous développerez les skills de toute une vie.

### 3 - Faire de la relecture de code

Relire du code vous permet de voir différentes approches pour répondre à une problématique. Les chemins pour arriver à un résultat sont presque infinis. C'est une gymnastique intéressante de se mettre dans la peau d'un autre et de regarder son cheminement logique. A moins que la logique utilisée soit trop complexe ou tordu, ne jugez pas les autres sur leur implémentation. 

Chacun est différent, chacun pense différemment, c'est pourquoi nous devons portez un regard bienveillant sur ce qui a été fait, et surtout veiller à ce que l'objectif soit atteint. 

Ce processus vous permettra d'apprendre des autres, d'observer les choses sous un autre angle et vous permettra de continuer à développer votre compréhension de la programmation car je le redis, tout est affaire de compréhension. 

**La compréhension règle chaque bug, vous permet d'anticiper sur des problèmes et enlève toutes les barrières mentales que vous pouvez rencontrer en codant.**

### 4 - Faire de la veille technique

**Y a t-il quelqu'un sur youtube, sur git ou twitter qui maîtrise un sujet que vous souhaitez maîtriser ?**

Cette personne pourrait être votre mentor, suivez cette personne, écoutez attentivement ce qu'elle a à dire. Lisez attentivement ses posts. Très souvent les développeurs partagent le fruit de leur recherches et leur observations. Si vous souhaitez apprendre également, rapprochez vous au maximum de ces gens là. 

Combien d'entre-nous ont appris le développement en imitant du code que nous avons vu ? Cela ne retire en rien la compréhension de ce code. A partir du moment où tout ce qui est fait est clair à vos yeux, réutilisez ces informations que votre cerveau détient déjà ! L'avantage avec cette technique, c'est que plus vous le faite, plus vous le faites vites car vous développez des automatismes. 

**Par exemple, regardez combien de temps vous a pris la déclaration de votre première classe en orienté objet, comparé au temps que cela met au bout de la 1000e fois que vous le faîtes.**

Le mimétisme est un excellent moyen d'apprendre et de progresser vite. Et plus la personne que vous mimez est doué, plus vous allez devenir vous-même talentueux. 

De nouveau langages, de nouvelles librairies apparaissent chaque jour. Tous avec un seul et même but : répondre à un problème de développeurs ! 

Prenez le temps de tester ces outils, prenez des notes, créez des repo ou des gist, cela vous aidera probablement un jour ! Ou du moins, vous permettra de savoir à quoi sert cet outil et quelle problématique cela règle.

Lorsque vous devez mettre en place une solution, votre choix sera toujours de meilleurs qualité si vous êtes conscient des différents outils à votre disposition pour y arriver, car vous saurez pourquoi passer par tel chemin et pas l'autre.

### 5 - La magie des todo list

J'imagine que tout le monde aujourd'hui sait ce qu'est une todo list, maintenant comment le faire efficacement ?

**Chacun des objectifs de votre todolist doit être réalisable en un jour.**

C'est pourquoi, il faut toujours découper votre objectif en séquences. 
Et cela fait totalement sens, de la même manière que pour construire la muraille de Chine, on n'aurait jamais fait une tâche :

- Construire la muraille

...mais plutôt un objectif découpé en centaines de mètres au quotidien.

De même pour faire décoller un avion, on ne ferait jamais : 

- Entrer dans l'avion
- Faire décoller l'avion

Cela demande réellement un travail qui relève de la conception, que de savoir observer chacune des étapes nécessaires pour réaliser un objectif. Et s’entraîner à faire cela, vous fera progresser sur les points suivants : 

- La conception (avoir la vision du chemin vers l'objectif)
- Pouvoir estimer plus facilement le temps moyen pour réaliser une solution (calculer la distance vers l'objectif)
- Etre motivé (car chaque jour, on voit la progression et l'objectif se rapproche)
- Savoir expliquer (car on sait où l'on se positionne par rapport à l'objectif)

Nous continuerons cette exercice dans un prochain article où l'on parlera des tests unitaires et d'autres techniques pour améliorer notre compétence.

large_james-harrison-vpOeXr5wmR4-unsplash.jpg

medium_james-harrison-vpOeXr5wmR4-unsplash.jpg

small_james-harrison-vpOeXr5wmR4-unsplash.jpg

thumbnail_james-harrison-vpOeXr5wmR4-unsplash.jpg

james-harrison-vpOeXr5wmR4-unsplash.jpg

Comment devenir un meilleur développeur ? J'ai consacré beaucoup de temps dans ma vie à mon apprentissage. J'y toujours passe le plus clair de mon temps et voici ce que j'ai appris...

Mes conseils de développeur partie 1

## Une meilleure association Strapi Next.js

Lorsque vous rédigez vos articles avec Strapi, un input de type RichText se contentera de générer du texte au format **Markdown**. Pour pouvoir l'afficher avec la mise en forme, côté Next.js, nous allons utiliser un composant **React** : **React-Markdown**.

### A quoi sert cette librairie ? 

Elle remplace le Markdown généré par Strapi en composants HTML plus traditionnel. 

Des 
```
<H1> <H2> <H3>
```
pour les titres, 

des 
```
<A> 
```
pour les liens, 

des 
```
<UL>
``` 
pour les listes...

Cette librairie est personnalisable à souhait. On peut remplacer pour chaque élément HTML rendu par un composant custom et [la documentation](https://remarkjs.github.io/react-markdown/) nous montre comment nous y prendre : 

```tsx
import React from 'react'
import ReactDOM from 'react-dom'
import ReactMarkdown from 'react-markdown'
import MyFancyRule from './components/my-fancy-rule.js'

ReactDOM.render(
  <ReactMarkdown
    components={{
      // Use h2s instead of h1s
      h1: 'h2',
      // Use a component instead of hrs
      hr: ({node, ...props}) => <MyFancyRule {...props} />
    }}
  >
    # Your markdown here
  </ReactMarkdown>,
  document.querySelector('#content')
)
```

En **JSX** cela ne pose aucun problème, mais en **TSX** c'est une autre pair de manches...

### Comment se fait la surcharge de React-Markdown

On passe un objet à la propriété components, et chaque clé de cet objet représente un composant.
Le problème, c'est que le renderer est une fonction et cela pose pas mal de problème pour pouvoir typer ces éléments.

Voici comment j'ai procédé :

Je commence par créer mon composant **MarkdownLink** qui retourne un **JSX.Element** basique : 

```tsx
import * as React from 'react'

type MarkdownLinkProps = {
  href: string
  children: React.ReactNode
}

const MarkdownLink = ({ href, children }: MarkdownLinkProps) => {
  return (
    <a href={href} target="_blank" rel="noreferrer">
      {children}
    </a>
  )
}

export default MarkdownLink
```

Puis au moment du render de **React-Markdown** :

```jsx
<ReactMarkdown
    components={{
        a: ({ node, children }) => {
           return (
               <MarkdownLink href={(node.properties?.href as string) ?? ''}>
                  {children[0]}
               </MarkdownLink>
            )
        },
    }}
   >
   {post.attributes.content}
</ReactMarkdown>
```

Et voilà, notre composant remplace désormais la balise <a></a> standard généré par React-Markdown. 😉

large_sigmund-59yRYIHWtzY-unsplash.jpg

medium_sigmund-59yRYIHWtzY-unsplash.jpg

small_sigmund-59yRYIHWtzY-unsplash.jpg

thumbnail_sigmund-59yRYIHWtzY-unsplash.jpg

sigmund-59yRYIHWtzY-unsplash.jpg

React-Markdown est une librairie d'interprétation de contenu markdown qui permet de générer automatiquement le code HTML. Cependant, il génère des balises standards, sans classes et les affiche. Si vous voulez personnaliser tout ça, il faudra créer votre CSS en fonction de l'élément parent.
Nous allons voir comment créer nos propres renderer pour les composants HTML avec react-markdown en typescript.

Personnalisation de React-Markdown en Typescript

## Optimiser son référencement Strapi

La SEO est un incontournable pour obtenir de la visibilité sur internet. Les CMS tels que Wordpress, Joomla etc sont reconnus pour être très efficace pour leur compatibilité avec les moteurs de recherches.

**Cependant, si l'on devait partir de 0 et tout faire, comment vous y prendriez vous ?**

Vaste question à laquelle il y a plusieurs réponses possibles.

### Générer un sitemap.xml dynamiquement avec Next.js

[La documentation de Next.js](https://nextjs.org/learn/seo/introduction-to-seo) nous donne beaucoup d'informations sur le sujet et même [des exemples](https://nextjs.org/learn/seo/crawling-and-indexing/xml-sitemaps).

Un des fichiers clé de la SEO, le fichier **sitemap.xml** doit impérativement être accessible pour donner aux robots la liste des liens disponibles sur votre site, autrement dit, une sorte d'état des lieux...

Dans leur exemple, Next.js propose de générer dynamiquement ce fichier en créant une page **sitemap.xml.js**

```jsx
//pages/sitemap.xml.js
const EXTERNAL_DATA_URL = 'https://jsonplaceholder.typicode.com/posts';

function generateSiteMap(posts) {
  return `<?xml version="1.0" encoding="UTF-8"?>
   <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
     
     <url>
       <loc>https://jsonplaceholder.typicode.com</loc>
     </url>
     <url>
       <loc>https://jsonplaceholder.typicode.com/guide</loc>
     </url>
     ${posts
       .map(({ id }) => {
         return `
       <url>
           <loc>${`${EXTERNAL_DATA_URL}/${id}`}</loc>
       </url>
     `;
       })
       .join('')}
   </urlset>
 `;
}

function SiteMap() {
  // getServerSideProps will do the heavy lifting
}

export async function getServerSideProps({ res }) {
  // We make an API call to gather the URLs for our site
  const request = await fetch(EXTERNAL_DATA_URL);
  const posts = await request.json();

  // We generate the XML sitemap with the posts data
  const sitemap = generateSiteMap(posts);

  res.setHeader('Content-Type', 'text/xml');
  // we send the XML to the browser
  res.write(sitemap);
  res.end();

  return {
    props: {},
  };
}

export default SiteMap;
```

Avec le temps, en fonction du nombre d'articles sur votre site, cette approche pourrait être problématique à cause des délais de réponse pour générer dynamiquement cette page.

### Générer un sitemap.xml static avec Strapi

J'ai opté pour une approche de pré-construction de ce fichier qui sera rendu dans le dossier **/public/**

![seo-optimisation-strapi-sitemap ><](https://bo.dev-freelance.fr/uploads/sitemap_job_drawio_b5c960abad.png)

Afin de générer ce fichier, j'ai créé un worker qui fait ce travail de génération en amont, pour réduire au maximum les temps d'accès à cette url. Ce même worker pourra me servir dans le futur pour d'autres tâches, donc la solution est évolutive.

Le worker va lire les clés **WORKER:<jobName>** dans Redis, créés via lifecycle hook côté Strapi.

Vous remarquerez que je n'ai pas opté pour un pub/sub Redis, mais c'est un choix, cela aurait très bien pu se faire. Je l'ai déployé sur une solution en 2019 chez Webedia et c'est quelque chose de relativement stable, bien que pour du pub/sub, je préfère me tourner vers des outils comme RabbitMQ qui est beaucoup plus fiable. Dans mon cas, il s'agit d'une solution assez petite, c'est pourquoi j'ai préféré faire simple.

large_solen-feyissa-UWVJaDvXW_c-unsplash.jpg

medium_solen-feyissa-UWVJaDvXW_c-unsplash.jpg

small_solen-feyissa-UWVJaDvXW_c-unsplash.jpg

thumbnail_solen-feyissa-UWVJaDvXW_c-unsplash.jpg

solen-feyissa-UWVJaDvXW_c-unsplash.jpg

Après avoir conçu mon blog en Next.js et Strapi, j'ai du travailler sur la partie SEO afin de donner un peu de visibilité à mon site. Je vous explique comment je m'y suis pris.

Découvrez tous nos articles de la catégorie Dev - page 6 sur 7