<p>This site just migrated from Gatsby to NextJS. If every coder today leans toward NextJs versus Gatsby, now I don't feel this so obvious.</p>
<hr>
<h2>Gatsby and its plugins</h2>
<p>I want to write more premium content on this site, so I was motivated to upgrade a few items,
when appeared at my first <code>gatsby develop</code> :</p>
<p><img src="./images/gatsby-plugin-bug.png" alt="Bug du plugin gatsby"></p>
<p>...last bug I wanted to see. Not on my code, but a bug about a plugin and the wrong version of
one of its dependencies.</p>
<h2>Gatsby versus NextJS ?</h2>
<p>The site you are reading now just migrated from Gatsby toward NextJS.
Those two technologies embrace the JAM stack and are <em>static sites generators</em>, which allow
to display very fastly web pages with a maximum of security. Wordpress killers.</p>
<p>But does it allow fast improvements ?</p>
<h2>DX: Developer Experience</h2>
<p>This capability of improving fastly and nicely an application is named <em>Developer Experience</em>. Now
that developers are more valuated than users, it has its importance.</p>
<p>DX relies on development speed, but even more on the pleasure of coding. This is impacted by many
factors that won't be described there, but you can understand that pleasure is important for
such a not monetized web site.</p>
<p>And, in terms of pleasure, Gatsby and and GraphQL are terrible. My opinion, and opinions of many.
Every type of page is affected by a huge, unpleasant, partly copy/pasted GraphQL query.</p>
<p><img src="./images/graph-ql-blog.png" alt="graphql query"></p>
<p>That is not very readable, and moreover the tooling is far from excellent.</p>
<p>Even worst, you must add many plugins, where each plugin wrap a lib adapted to Gatsby structure and GraphQL
queries. The bug I had above appeared on one of this plugin, not updated quickly enough. Classic and predictable.</p>
<h2>Programming language</h2>
<p>Both Gatsby and NextJS use React JS, but only one command line argument quickly adds Typescript to NextJS.
Typescript is now a must for most developers.</p>
<p>You can still use typescript with Gatsby. I used an <a href="https://github.com/antoinerousseau/gatsby-starter-antoine/">unofficial starter kit</a>
proposed by <a href="https://antoine.rousseau.im">Antoine Rousseau</a> for Gatsby.</p>
<h2>CSS Framework</h2>
<p>NextJS proposes by default <em>CSS Modules</em>. Nothing is proposed by Gatsby, which is not that bad.
Both work well with <em>Sass</em>.</p>
<p>I used very easily <em>Styled Components</em> with Gatsby, and it would be that easy also with NextJS.
CSS Modules didn't bring me more, it's a question of taste and coder experience.</p>
<h2>Deployment ease</h2>
<p><em>Vercel</em>, which is an Heroku competitor, is the NextJS editor and proposes in its documentation
a path to deploy in a few steps the website on Vercel servers.</p>
<p>The JAM stack also contains api capabilities. Your website is not read-only, and can create actions.
Vercel proposes an api from React JS front to Vercel servers.</p>
<p>However pricing from Vercel is not obvious to catch. Also I don't think it's always a good idea to be tied
to an editor. If the code gets slowly locked, I would have more awareness on quitting NextJS being outside
Vercel cocoon. I needed around 20 hours to move from Gatsby to NextJS, so I may reverse it quickly as long
as I don't call too much proprietary Vercel apis.</p>
<h3>Strange build for NextJS</h3>
<p>It took 10 seconds to my new edge computer to build NextJS website, and 16 seconds with Gatsby. As this
site is very small, those are not representative figures.</p>
<p>I expected both technologies to create basic html. It happens that structures were different. Here is the one generated by Gatsby.</p>
<p><img src="./images/structure-gatsby.png" alt="Generation Gatsby"></p>
<p>A browser going to <code>/page/2/</code> will load <code>/page/2/index.html</code> file with a basic server.</p>
<p>Generation is significantly different with NextJS:</p>
<p><img src="./images/structure-next.png" alt="Generation NextJS"></p>
<p>So after the command <code>next build &#x26;&#x26; next export</code>, I deployed the site with a local server (<code>php -S localhost:8888</code>), and going directly
to the second page (<code>/page/2</code>), we have an awful 404 error. I should call <code>/page/2.html</code> which is not a <em>sexy url</em>.</p>
<p>If I first go to the homepage, then on the second page, it will work as the React application will display content loaded from
some Json.</p>
<p><img src="./images/404.png" alt="404 sur NextJS"></p>
<p>Thought I followed the documentation with nothing fancy, it may be a configuration problem, but it's worrying if it's not the case.</p>
<p>Nevertheless, like my old Gatsby site, I used Netlify who deployed everything without any problem,
nor any 404 error page.</p>
<h2>Site publication</h2>
<p>The change of DNS was done quickly. The roadmap is written and next items are:</p>
<ul>
<li>The page to present the trainings</li>
<li>SEO: some headers and the sitemap</li>
<li>An API to record the emails of a newsletter</li>
</ul>
<p>The point of the <strong>sitemap</strong> is interesting for the comparison between Gatsby versus NextJS. It is about transforming all the pages
and articles to generate an XML. Using Gatsby, you would have to start from some sort of plugin or graphQL query.</p>
<p>With NextJS, I already have access to a <code>Post</code> type object array representing the pages that will need to be mapped to XML.
It's not done, but I have a clear idea of where to start.</p>
<p>In conclusion, Gatsby is missing an official version with typescript and without GraphQL to compete.</p>
<p>Since the migration, the site is just as fast, the updates are more regular, the articles more frequents,
which was the desired goal.</p>


Why I made the migration from Gatsby toward NextJS

<p>Le bug de trop de Gatsby et ses plugins, un mois plus tard, je migre ce site en NextJS... Si aujourd'hui chaque codeur semble préférer NextJs à Gatsby, le choix n'est
rétrospectivement pas si évident.</p>
<hr>
<h2>Gatsby et ses plugins</h2>
<p>Je veux maintenant écrire bien plus de contenu à haute valeur sur ce site,
et j'étais donc décidé à améliorer deux-trois éléments, quand apparu à mon premier <code>gatsby develop</code> :</p>
<p><img src="./images/gatsby-plugin-bug.png" alt="Bug du plugin gatsby"></p>
<p>...le bug de trop. Non pas sur mon code, mais un bug qui parle de plugin
et de mauvaise version de l'une de ses dépendances.</p>
<h2>Gatsby ou NextJS ?</h2>
<p>Le site que vous lisez actuellement vient de migrer de Gatsby vers NextJS.
Ces deux technologies embrassant la <em>JAM Stack</em> sont des <em>Static site generators</em>, ce qui permet
d'afficher très rapidement des pages web, avec un maximum de sécurité. L'opposé de Wordpress.</p>
<p>Mais est-ce que cela permet de coder rapidement ?</p>
<h2>DX: Experience de développement</h2>
<p>Cette capacité à faire progresser rapidement et sympathiquement une application a son petit anglicisme
barbare : la <em>Developer Experience</em>, aka DX. Maintenant que les développeurs sont plus précieux
que les utilisateurs, la DX a son importance.</p>
<p>La DX joue sur la rapidité de développement, mais aussi sur le
plaisir à coder, ce qui est en fait essentiel pour un projet non monétisé comme celui-là.</p>
<p>Et pour moi comme beaucoup d'autre, Gatsby et GraphQL sont catastrophiques. Chaque type de page
se retrouve affublée d'une requête GraphQL plus ou moins longue et qui se ressemblent.</p>
<p><img src="./images/graph-ql-blog.png" alt="graphql query"></p>
<p>Non seulement, c'est peu lisible, mais en plus l'outillage associé n'est pas excellent.</p>
<p>De plus il faut enchaîner plugins sur plugins. Et donc l'utilisation d'une bibliothèque adaptée à Gatsby et
,problème parfois superposé, requêtable en GraphQL. Le problème qui m'est survenu était qu'un de ces plugin n'était pas mis
à jour assez vite. Classique et prévisible.</p>
<h2>Langage de programmation</h2>
<p>Les deux technologies utilisent React JS, mais il suffit d'un argument simple pour initialiser NextJS avec Typescript.
Avec un peu d'habitude, Typescript est un must pour la plupart des dévelopeurs.</p>
<p>Typescript est toutefois utilisable avec Gatsby. J'ai utilisé
un <a href="https://github.com/antoinerousseau/gatsby-starter-antoine/">starter kit non officiel</a> proposé
par <a href="https://antoine.rousseau.im">Antoine Rousseau</a> pour Gatsby.</p>
<h2>Framework CSS</h2>
<p>NextJS propose les <em>CSS Modules</em> par défaut. Rien n'est proposé par Gatsby, ce qui n'est pas plus mal.
Les deux frameworks fonctionnent bien avec <em>Sass</em>.</p>
<p>J'avais utilisé facilement les <em>Styled Components</em> avec Gatsby, et ce serait aussi simple à mettre en place avec NextJS.
En comparaison, les CSS Modules ne m'ont rien apporté, c'est vraiment une question de goût et d'expérience.</p>
<h2>Simplicité de déploiement</h2>
<p>Vercel, que l'on peut classer comme un concurrent de Heroku, est l'éditeur de NextJS.
La documentation propose donc logiquement de déployer en quelques instants
le site sur les serveurs de Vercel.</p>
<p>Mais d'une part le pricing de Vercel n'est pas clair, d'autre part je pense qu'il n'est pas bon de trop se nouer avec un éditeur.
Si le code se verouille doucement, je serai plus alerte pour sortir de Next JS en étant hors du cocon de Vercel.</p>
<h3>Build étrange pour Next JS</h3>
<p>Il me faut 10 secondes pour builder NextJS, où Gatsby prend 16 secondes. Ce n'est pas représentatif vu la petite taille du site.</p>
<p>En théorie, ces deux build doivent créer un site avec du html basique. Or les structures sont différentes. Voici celle générée par
Gatsby</p>
<p><img src="./images/structure-gatsby.png" alt="Génération Gatsby"></p>
<p>Pour Gatsby, il faut se rendre sur <code>/page/2/</code> pour qu'un serveur très standard va charger le fichier <code>/page/2/index.html</code></p>
<p>La génération est différente pour Next JS :</p>
<p><img src="./images/structure-next.png" alt="Génération NextJS"></p>
<p>Si bien qu'après avoir fait la commande <code>next build &#x26;&#x26; next export</code>, j'ai deployé le site avec un serveur local
(<code>php -S localhost:8888</code>), et
si l'on se rend immédiatement à la seconde page <code>/page/2</code>, nous avons un affreux 404. Il faudrait charger
<code>/page/2.html</code>, ce qui n'est pas une url <em>sexy</em>.</p>
<p>Si je passe par le homepage, puis navigue vers la 2e page,
je n'ai pas de problème car l'application affiche le contenu issu d'un Json chargé via Ajax.</p>
<p><img src="./images/404.png" alt="404 sur NextJS"></p>
<p>Peut-être un problème de configuration, mais c'est inquiétant si ce n'est pas le cas.
Le déploiement sous Netlify se fait pourtant sans soucis et le probleme de 404 n'est pas rencontré.</p>
<h2>Publication du site</h2>
<p>Le changement des DNS s'est fait rapidement. La roadmap est écrite et les prochains objectifs sont :</p>
<ul>
<li>La page pour presenter les formations</li>
<li>SEO : quelques headers et le sitemap</li>
<li>Une api pour enregister les emails d'une newsletter</li>
</ul>
<p>Le point du <strong>sitemap</strong> est intéressant pour la comparaison entre Gatsby ou NextJS. Il s'agit de transformer l'ensemble des pages
et articles pour générer un XML. En utilisant Gatsby, il faudrait partir de je ne sais quel plugin ou requête graphQL.</p>
<p>Avec NextJS j'ai déjà accès un tableau d'objet de type <code>Post</code> représentant les pages qu'il faudra mapper vers du XML.
Ce n'est pas fait, mais j'ai une vision claire de par où commencer.</p>
<p>En conclusion, il manque à Gatsby de proposer une version officielle avec typescript et sans graphQl pour rivaliser.</p>
<p>Depuis la migration, le site est tout aussi rapide, les mises à jour sont plus régulières, les articles plus fréquents,
ce qui était bien le but recherché.</p>


Pourquoi j'ai migré de Gatsby vers NextJS

<p>How to complete an observable when the other completes ?</p>
<hr>
<h2>When to use RxJs ?</h2>
<p>I'm working on real time data these days, and now I'm getting pretty good with <strong>RxJS</strong>.
I have ranted many years against RxJS because it was packed with Angular, and
I don't see the point of using an Observable for a rest request, when a <strong>Promise</strong> is
perfect for that.</p>
<p>Moreover, RxJs api was moving fast, causing displeasure when you don't follow that much this
project.</p>
<p>When dealing with real time data, it's another story. RxJs nails it, and its
integration with <strong>Typescript</strong> is perfect.</p>
<h2>Completing an observable</h2>
<p>There are many operators included with RxJs, and over the time, they removed some to limit
the api surface, which is good. It's very easy to make your own operator,
so if your code often use a certain combination of operators with recurrent logic,
don't hesitate to factorize your code with your <strong>customized operator</strong>.</p>
<p>In my project, I often need to terminate an <code>Observable</code> when another finish. They
both finish at the same time. I first supposed that this is common and therefore an
operator already exists, but <code>takeUntil(other$)</code> terminates your observable
when the <code>other$</code> starts.</p>
<p>It's also easy to complete a <code>Subject</code>, with <code>subject.completes()</code>, but I prefer to
work with observables.</p>
<h2>My customized operator</h2>
<p>I want my <code>stream$</code> to complete with <code>other$</code> stream. I wish to use it like this:</p>
<pre><code class="language-typescript">stream$.pipe(completeWith(other$))
</code></pre>
<p>My <code>completesWith</code> function uses 4 lines of code:</p>
<pre><code class="language-typescript">export const completesWith = (other$: Observable&#x3C;any>) => (o: Observable&#x3C;number>) => {
  const terminator$ = new Subject()
  other$.subscribe().add(() => {
    terminator$.next('terminate')
  })
  return o.pipe(takeUntil(terminator$))
}
</code></pre>
<p>When other$ completes, a terminator$ Subject will emit any value, and using
takeUntil, it will then complete our observable.</p>
<h2>Replace Subject by an Observable</h2>
<p>As I said before, I prefer to avoid Subjects. The way Subjects store listeners could provoke
memory leaks. Functional style has much more guarantees.</p>
<pre><code class="language-typescript">export const completesWith = (end$: Observable&#x3C;any>) => (o: Observable&#x3C;number>) => {
  const terminator$ = new Observable(subscriber => {
    end$.subscribe().add(() => {
      // Will officially start the observable
      subscriber.next('FUNCTIONAL terminate')
    })
  })

  return o.pipe(takeUntil(terminator$))
}
</code></pre>
<p>This is more an exercise than a reality, as my project is full of Subjects, but they are always private object,
with very limited power. I just use them because it's convenient, more readable. Thought a bit dangerous...</p>
<p>If you can't replace your <code>Subject</code> by an <code>Observable</code>, probably harm is already done. Your Subject
may be linked to other objects, with complexity that puts your memory at risk.</p>


Completing a RxJs Observable with another

<p>Styled component is a technology that scales css. It's great, but there are some
traps. Here is what I wished I knew the most when starting Styled Components.</p>
<hr>
<h2>Goals and Difficulties</h2>
<p><strong>Styled Component</strong> is a library coded by the impressive Max Stoiber and now
maintained by many others, proof of success and durability.</p>
<p>There are two main goals in my point of vue.</p>
<ul>
<li>Scale by avoiding hell of BEM, like using class name such as <code>search-box__btn search -box__btn_max_visible</code></li>
<li>Protect your component from the cascading pattern of CSS. Yes. Break the <b>C</b> of CSS</li>
</ul>
<p>Like you may expect, this second goal may bring some pain, or at least surprises when, like me
, your are too naive.</p>
<h3>Quick example</h3>
<p>Let starts with an example <a href="https://styled-components.com/docs/basics#extending">from the doc</a>:</p>
<pre><code class="language-jsx">const Button = styled.button`
  color: palevioletred;
`;

const TomatoButton = styled(Button)`
  color: tomato;
`;
</code></pre>
<p>That works and gives two nice buttons. But using:</p>
<pre><code class="language-jsx">const MyButton = ()=>&#x3C;button>Click Me&#x3C;/button>

const MyTomatoButton = styled(MyButton)`
  color: tomato;
`;
</code></pre>
<p>I'm naive and I have a button. I want to style it, so I write <code>styled(button)</code>.
But my new button won't have any tomato color 😞</p>
<h3>Read the manual</h3>
<p>First, be smarter than me and don't miss this most important line <a href="https://styled-components.com/docs/basics#styling-any-component">from the manual</a>:</p>
<blockquote>
<p>The styled method works perfectly on all of your own or any third-party component, <strong>as
long as they attach the passed className</strong> prop to a DOM element.</p>
</blockquote>
<pre><code class="language-jsx">const Link = ({ className, children }) => (
  &#x3C;a className={className}>
    {children}
  &#x3C;/a>
);
</code></pre>
<p>Why ? Because later the examples given across the web, including Styled Component
documentation gives examples where it looks easy to modify a component, when
this second goal is <b>exactly</b> to avoid any modification of a component.</p>
<h2>Applying classes</h2>
<p>The problem is that styled(Comp) is effective only if Comp is already a styled component.
To achieve this, you must add the <code>className</code> to MyButton</p>
<pre><code class="language-jsx">const MyStyledButton = ({className})=>&#x3C;button className={className}>Click Me&#x3C;/button>

const MyTomatoButton = styled(MyStyledButton)`
  color: tomato;
`;
</code></pre>
<p>Now StyleComponent will create some classes and apply them to your component, making it a styled
component.</p>
<p><img src="./images/styled-classname.png" alt="ClassName applied to styled component"></p>
<p><em>No className, no style</em>. When using <code>styled.div</code>, then StyledComponent has
already applied the <code>className</code> trick.</p>
<p>This is wanted behaviour. You are not supposed to transform a component except
if the component creator has explicitly said you can ! It's the
<a href="https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle">open/close principal</a>
applied to styling.</p>
<h2>Advanced usage</h2>
<h3>Restyle</h3>
<p>Once a component is styled, you can re-style it.</p>
<pre><code class="language-jsx">const AttachingComp = ({className})=>&#x3C;div className={className}>I am a &#x3C;strong>attaching&#x3C;/strong> component&#x3C;/div>

const GreenAttachingComp= styled(AttachingComp)`
  color:green;
  strong{
    text-decoration:underline
  }
`

const Child = styled(GreenAttachingComp)`
   margin: 20px 20px;
   color: red;
`

</code></pre>
<p><img src="./images/restyle.png" alt="Restyling from another component"></p>
<h3>Nesting components</h3>
<p>The same <em>closed by default</em> behaviour is applied to nesting components. If you
have not applied <code>className</code> to a React element, nesting rules are ...not applied.</p>
<pre><code class="language-jsx">
const BasicComp = () => &#x3C;div>I am a &#x3C;strong>basic &#x3C;/strong>component&#x3C;/div>;

const AttachedComp = ({ className }) => (
  &#x3C;div className={className}>
    I am an &#x3C;strong>attached&#x3C;/strong> component
  &#x3C;/div>
);

const StyledBasicComp = styled(BasicComp)``;
const StyledAttachedComp = styled(AttachedComp)``;


const DemoNesting = ({className})=>{
  return (
    &#x3C;div className={className}>
      &#x3C;StyledBasicComp/>
      &#x3C;StyledAttachedComp/>
    &#x3C;/div>
)}


export const StyledDemoNesting = styled(DemoNesting)`
// general css rules. Will be applied to all nodes below
font-size:12px;
strong{
  color:red;
}


// component rule on basic component. Won't be effective
${StyledBasicComp}{
  color:yellow;
}

// component rule on className attached component. Rule is effective
${StyledAttachedComp}{
  color:green;
  font-size:24px;
}
`
</code></pre>
<p>You can test it in this <a href="https://stackblitz.com/edit/styled-components-robusta?file=nesting.js">Stackblitz</a></p>
<h2>When should I attach className ?</h2>
<p>Most often, you should not. Because it's designed this way. If you have a few rules, you should
prefer standard css or sass.</p>
<p>If you have a bigger application, then attaching <code>className</code> could increase interferences.</p>
<p>If you want to present a component in different way, you will rather use a <a href="https://styled-components.com/docs/advanced#theming">theme</a>
or <a href="https://styled-components.com/docs/basics#passed-props">passed props</a> if it's through your application state:</p>
<p>Attaching <code>className</code> is really meant for the case where you create a third party library, and you
design a point of extension. You create some open explicitly for the style. Attaching the
<code>className</code> will avoid some hacks are they are described here <a href="https://github.com/styled-components/styled-components/issues/2076">in this issue</a></p>
<p>I kind of attach <code>className</code> for creating my own library. I design some Theme Component, such as
<code>TCard</code>, then I modify the spacing at different point of this Gatsby website, or reuse it for similar
websites.</p>
<p>For the moment, it's just a test, and it looks good. But it took me way too much time to really
understand how and why attach <code>className</code>. Maybe this article will help you 😊</p>


Why I made the migration from Gatsby toward NextJS

Pourquoi j'ai migré de Gatsby vers NextJS

Completing a RxJs Observable with another

Applying correctly className with Styled components