fix: add notes

docs/markdown/01-intro/11-what-meta.md

@@ -5,3 +5,8 @@
 - Built on top of an existing framework (in this case, React)
 - Adds additional features and conventions
 - Aims to simplify development and improve performance
+
+Notes:
+
+- Next.js est avant tout un serveur Node.js
+- Mais le serveur occupe une place centrale dans le rôle du Framework

docs/markdown/01-intro/12-react-vercel.md

@@ -10,3 +10,11 @@
 ## A special connection between React and Vercel
 
 <img src="./assets/images/01-intro/react-vercel-search.png" class="react-vercel-12"  />
+
+Notes:
+
+- Les équipes de React et Next sont différentes, mais travaillent en liens étroi
+- Next.js est le framework React qui utilise le plus les dernières fonctionnalités
+- C'est même quasiment le seul (par exemple : server components, server actions etc...)
+- Au point où Next.js sert de base de développement pour React
+- C'est souvent ce qui lui est reproché : que ça se dirige un peu trop vers de l'expérimentation de nouvelles features

docs/markdown/01-intro/13-equivalents.md

@@ -10,3 +10,10 @@
 ## Equivalents
 
 <img src="./assets/images/01-intro/frameworks.png" class="equivalents-13"  />
+
+Notes:
+
+- Next est loin d'être le seul metaframework
+- Dans sa catégorie, on en trouve plusieurs autres, que ce soir pour du React ou autres langages / frameworks
+
+-> Question aux participants : Est-ce que vous en avez déjà utilisé dans la liste ou un autre ?

docs/markdown/01-intro/14-features.md

@@ -60,3 +60,15 @@
   - Server Actions
   </div>
   <!-- .element: class="fragment" data-fragment-index="5"-->
+
+Notes:
+
+- Passage en revue des principales fonctionnalités de Next.js
+
+Avec des exemples sur des sites en live :
+
+- Client side navigation (rapide à illustrer)
+
+Pour le CSS : Pas de prérogative du framework
+
+Il supporte les standards mais n'offre pas une manière officielle de faire. C'est au choix

docs/markdown/01-intro/20-history.md

@@ -5,3 +5,9 @@
 - **2020 | version 9** : Sass and CSS Modules support
 - **2022 | version 13** : New pattern in beta -> App Router **Turning Point**
 - **May 2023 | version 13.4** : Stable version of App Router
+
+Notes:
+
+- Passage en revue de l'historique des versions
+- Version 13 -> a amené un gros changement de paradigme
+  Version qui a fait le plus parler d'elle

docs/markdown/01-intro/21-app-router.md

@@ -26,3 +26,13 @@ The app router is a completely different pattern. Some features are common, but
 _In the documentation :_
 
 <img src="./assets/images/01-intro/pages-app.png" class="pages-app-21"  />
+
+Notes:
+
+On choisi de partir sur le pages router OU le app router
+
+Les choses s'implémentent de manière complètement différentes entre les deux
+
+Et les migrations de l'un vers l'autre peuvent être fastidieuses
+
+Donc aujourd'hui Next c'est deux frameworks à part entière

docs/markdown/01-intro/22-today.md

@@ -22,3 +22,13 @@
 
 </div>
 <!-- .element: class="fragment" data-fragment-index="1"-->
+
+Notes:
+
+Version 14 qui a bien stabilisé le app router
+
+La version 15 sera dans la même lignée
+
+Pas encore de visibilité sur une potentiel déprécation du pages router
+
+Même si on sent que le focus est mis sur le app router (résolution d'issues + nouvelles features)

docs/markdown/01-intro/30-command.md

@@ -5,3 +5,15 @@
 ```bash
 npx create-next-app@latest
 ```
+
+Notes:
+
+Pas besoin de lancer cette commande aujourd'hui
+
+Mais le prompt permet de choisir :
+
+- TypeScript
+- Solutions de styles clés en main (tailwind etc...)
+- app ou pages router
+- arborescence de fichiers
+  ...

docs/markdown/02-routing/01-intro.md

@@ -18,3 +18,11 @@
 
 - Parrallel routing
 - Route interception
+
+Notes:
+
+Le router c'est l'élément central du framework
+
+C'est sur le router que sont basés les fonctionnalités clé
+
+Et des features un peu plus poussées

docs/markdown/02-routing/10-naming.md

@@ -23,3 +23,21 @@
 - **default** : (advanced) Fallback UI for parallel routes
 </div>
 <!-- .element: class="fragment" data-fragment-index="1"-->
+
+Notes:
+
+Next.js a un router basé sur le filesystem
+
+Les pages et les points d'entrée de l'application sont définis par des fichiers :
+
+- nommés d'une certaine manière
+- placés au bon endroit
+
+Le dossier principal est configurable à l'init d'un projet :
+
+- Soit la racine du projet
+- Soit le dossier /app
+
+Listing des différents fichiers
+
+Pour les erreurs / loading -> on verra ça dans des modules dédiés

docs/markdown/02-routing/11-hierarchy.md

@@ -7,3 +7,13 @@
 File components are rendered and nested in a specific order :
 
 ![full-width](./assets/images/component-hierarchy.png)
+
+Notes:
+
+En interne, chaque fichier créé correspond à un composant React
+
+Ces composants sont imbriqués dans un certain ordre
+
+C'est toujours le même, et il n'y a pas possibilité de le changer
+
+Donc il est important de le garder en tête

docs/markdown/02-routing/12-nesting.md

@@ -7,3 +7,11 @@
 Nested routes = nested components
 
 ![](./assets/images/component-nesting.png)
+
+Notes:
+
+Les routes sont représentées par des dossiers
+
+Chaque sous-dossier permet de rajouter un segment dans l'URL
+
+Les composants générés suivent la logique : ils sont imbriqués dans les composants du segment parent

docs/markdown/02-routing/13-with-pages-router.md

@@ -26,3 +26,13 @@ Routes :
 src directory :
 
 <img src="./assets/images/02-routing/app-vs-pages-priority.png" class="routing-pages-vs-app-img"  />
+
+Notes:
+
+Il est possible de faire cohabiter app et pages router
+
+Dans le cadre d'une migration par exemple
+
+Ou dans des cas plus spécifiques si vraiment une feature est indisponible avec l'un ou l'autre
+
+Le app router prendra toujours le pas sur le pages router (petit indice qui prouve la préférence de Vercel sur le app router)

docs/markdown/02-routing/20-colocation.md

@@ -16,3 +16,14 @@ You can collocate files alongside specific files.
 They will not be interpreted as routes :
 
 <img src="./assets/images/02-routing/colocation.png" class="routing-colocation-img"  />
+
+Notes:
+
+La colocation de fichier permet d'envisager toute structure de projet
+
+Tout est possible :
+
+- Placer toutes les sources dans le dossier app, à côté des routes
+- Avoir une arbo plus "classique" où le app est juste la déclaration du router, et le reste à l'extérieur
+
+Attention : On ne sait pas quelles seront les futures conventions de Next. Donc la colocation est à utiliser avec vigilence

docs/markdown/02-routing/21-colocation-private.md

@@ -18,3 +18,11 @@ You can also make an entire subfolder private with an underscore prefix to exclu
 <br/> <br/>
 
 <img src="./assets/images/02-routing/colocation_folder.png" class="routing-colocation-private-img"  />
+
+Notes:
+
+On peut aussi faire de la colocation par dossier entier
+
+utile pour regrouper des fonctions utilitaires par exemple
+
+Mieux pour s'assurer qu'on aura aucun conflit de fichier

docs/markdown/02-routing/30-pages.md

@@ -11,3 +11,11 @@ Create a _page.tsx_ file in nested directories :
 /app/admin/page.tsx           website.com/admin
 /app/about/contact/page.tsx   website.com/about/contact
 ```
+
+Notes:
+
+Maintenant qu'on a vu toutes ces règles, comment est-ce qu'on crée nos premières pages ?
+
+Fichier page.tsx
+
+Avec Next, on crée beaucoup de dossiers

docs/markdown/02-routing/31-pages-dynamic.md

@@ -41,3 +41,15 @@ Optional catch all segments :
 </div>
 
 <!-- .element: class="fragment" data-fragment-index="2"-->
+
+Notes:
+
+Illustration des différents dynamic segments
+
+Pour gérer des URLs complexes
+
+Warning : Pas de possibilité de gérer des segments composés d'une partie fixe + une partie dynamique
+
+Il faut le gérer dans tout le segment
+
+Ou via d'autres mécanismes qu'on verra plus tard

docs/markdown/02-routing/40-layout.md

@@ -39,3 +39,11 @@ const Layout: React.FC<LayoutProps> = ({ children }) => {
 
 export default Layout;
 ```
+
+Notes:
+
+Layouts : pour toute UI ou fonctionnalité partagée entre plusieurs pages
+
+Pas de re-render d'une page à l'autre (partial rendering) : grosse plus value de la navigation côté client
+
+Illustration avec un exemple

docs/markdown/02-routing/41-root-layout.md

@@ -29,3 +29,9 @@ const RootLayout: React.FC<RootLayoutProps> = ({ children }) => {
 
 export default RootLayout;
 ```
+
+Notes:
+
+Layout un peu particulier : le root, qui est obligatoire
+
+Permet de définir la structure de base partagée par tout le site

docs/markdown/02-routing/42-nested-layout.md

@@ -19,3 +19,13 @@ Layouts are always nested :
 
 <br/> <br/>
 <img src="./assets/images/02-routing/nested-layout-schema-2.png"  />
+
+Notes:
+
+Gros avantage des layouts : possibilité de les imbriquer
+
+Pas possible auparavant avec le Pages Router
+
+Les layouts héritent alors du layout parent
+
+Pas de possibilité de désactiver cet héritage, en comparaison avec d'autres frameworks comme Sveltekit

docs/markdown/02-routing/43-template.md

@@ -46,3 +46,13 @@ const Wrapper = () => {
 ```
 
 <!-- .element: class="fragment" data-fragment-index="1"-->
+
+Notes:
+
+Layouts un peu particuliers : les templates
+
+Ce sont des layouts, mais qui sont re-render d'une page à l'autre
+
+Utile pour des besoins spécifiques. Par exemple pour du tracking (Redéclencher un pageView à chaque navigation)
+
+(Equivalent de mettre un key={pathname} sur un layout)

docs/markdown/02-routing/44-groups.md

@@ -31,3 +31,7 @@ They can be used for :
 </div>
 
 <!-- .element: class="fragment" data-fragment-index="1"-->
+
+Notes:
+
+Groups, fonctionnalité incomprise de Next, mais pourtant très puissante

docs/markdown/02-routing/50-advanced.md

@@ -6,3 +6,9 @@
 
 - Parallel routing
 - Intercepting routes
+
+Notes:
+
+On a vu le principal du router, maintenant abordons deux fonctionnalités plus poussées
+
+Et aussi moins utilisées de Next.js

docs/markdown/02-routing/51-advanced-parallel.md

@@ -40,3 +40,9 @@ const Layout = ({ children, settings, employees }) => {
   );
 };
 ```
+
+Notes:
+
+Utile quand on a une page composée de plusieurs parties indépendantes
+
+Inconvénient : difficile de faire communiquer les parties entre elles (partager les données de l'une à l'autre)

docs/markdown/02-routing/52-advanced-intercept.md

@@ -24,3 +24,9 @@ Route interception allows you to display a route from another location in the cu
 ##--##
 
 <img src="./assets/images/02-routing/intercepting-schema.png" class="intercepting-routing-schema-img" />
+
+Notes:
+
+Fonctionnalité très spécifique en soit, mais qui peut se révêler utile dans des cas bien précis
+
+On va le voir juste après

docs/markdown/02-routing/53-advanced-intercept-patterns.md

@@ -32,3 +32,7 @@ Patterns :
 <br/> <br/>
 
 <img src="./assets/images/02-routing/intercepting-pattern-routes.png" class="intercepting-pattern-routes-img" />
+
+Notes:
+
+Les patterns fonctionnent comme une arborescence de fichiers linux

docs/markdown/02-routing/54-advanced-intercept-modal.md

@@ -23,3 +23,9 @@ We can combine route interception and parallel routing to display a page on top
 ##--##
 
 <img src="./assets/images/02-routing/modal-schema.png" class="intercepting-pattern-modal-schema-img" />
+
+Notes:
+
+L'interception toute seule peut sembler trop spécifique, mais utilisé en combinaison avec le parallel routing, elle permet de gérer des modals avec URL
+
+Démo sur l'application SFEIR People

docs/markdown/02-routing/70-navigation.md

@@ -10,3 +10,21 @@
 - Client-side navigation - Soft navigation
 - Partial rendering
 - Scroll restoration
+
+Notes:
+
+Une fois les pages créées, on va chercher à naviguer entre elles
+
+Chaque route / layout génère ses propres fichiers dans le build
+
+Ce qui permet le code splitting
+
+Donc à la navigation côté client :
+
+- On peut prefetcher les routes (charger les ressources à l'avance)
+- On peut persister les ressources dans le cache
+- On peut faire de la navigation dans refresh
+- Partial rendering, on en a parlé avec les layouts
+- Scoll restoration : Possibilités plus riches qu'avec un refresh classique
+
+Démo des fonctionnalités sur l'appli

docs/markdown/02-routing/71-link.md

@@ -30,3 +30,13 @@ const Component = ({ employeeId, employeeName }) => {
   );
 };
 ```
+
+Notes:
+
+Element principal de navigation : le liens
+
+C'est celui qu'il faudra utiliser un maximum
+
+Pour des questions d'accessibilité, et de sémantique HTML
+
+Il gère aussi le prefetch par défaut

docs/markdown/02-routing/72-userouter.md

@@ -38,3 +38,9 @@ const Component = ({ employeeId, employeeName }) => {
   return <p>You will be redirected in 5 seconds</p>;
 };
 ```
+
+Notes:
+
+Si on ne peut pas utiliser de Link, ou qu'on souhaite interagir directement avec le router de manière programmatique
+
+On peut accéder à l'instance du router et utiliser ses méthodes

docs/markdown/02-routing/73-history.md

@@ -27,3 +27,16 @@ const Component = () => {
   return <button onClick={handleClick}>Show all results</button>;
 };
 ```
+
+Notes:
+
+Le shallow routing, cela permet de mettre à jour l'URL, et donc d'ajouter une entrée dans l'historique de navigation
+
+Sans causer un re-render de la page
+
+Donc on ne touche pas à l'arbre de composants, mais on change l'URL
+
+Utile par exemple si on veut gérer du scroll infini :
+
+- On change l'URL manuellement
+- On se charge de render nous même les éléments suivants, plutôt que de le faire via un changement de page