diff --git a/docs/markdown/01-intro/11-what-meta.md b/docs/markdown/01-intro/11-what-meta.md index dfbf6a0..ab47bf0 100644 --- a/docs/markdown/01-intro/11-what-meta.md +++ b/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 diff --git a/docs/markdown/01-intro/12-react-vercel.md b/docs/markdown/01-intro/12-react-vercel.md index 18fc04e..db46984 100644 --- a/docs/markdown/01-intro/12-react-vercel.md +++ b/docs/markdown/01-intro/12-react-vercel.md @@ -10,3 +10,11 @@ ## A special connection between React and Vercel + +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 diff --git a/docs/markdown/01-intro/13-equivalents.md b/docs/markdown/01-intro/13-equivalents.md index 3a31220..840b579 100644 --- a/docs/markdown/01-intro/13-equivalents.md +++ b/docs/markdown/01-intro/13-equivalents.md @@ -10,3 +10,10 @@ ## Equivalents + +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 ? diff --git a/docs/markdown/01-intro/14-features.md b/docs/markdown/01-intro/14-features.md index d57bc7d..91cb309 100644 --- a/docs/markdown/01-intro/14-features.md +++ b/docs/markdown/01-intro/14-features.md @@ -60,3 +60,15 @@ - Server Actions + +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 diff --git a/docs/markdown/01-intro/20-history.md b/docs/markdown/01-intro/20-history.md index 05f3a2e..fe90458 100644 --- a/docs/markdown/01-intro/20-history.md +++ b/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 diff --git a/docs/markdown/01-intro/21-app-router.md b/docs/markdown/01-intro/21-app-router.md index 706e186..2881948 100644 --- a/docs/markdown/01-intro/21-app-router.md +++ b/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 :_ + +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 diff --git a/docs/markdown/01-intro/22-today.md b/docs/markdown/01-intro/22-today.md index 0ef6cc4..c51d49f 100644 --- a/docs/markdown/01-intro/22-today.md +++ b/docs/markdown/01-intro/22-today.md @@ -22,3 +22,13 @@ + +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) diff --git a/docs/markdown/01-intro/30-command.md b/docs/markdown/01-intro/30-command.md index a4e20fb..ada3709 100644 --- a/docs/markdown/01-intro/30-command.md +++ b/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 + ... diff --git a/docs/markdown/02-routing/01-intro.md b/docs/markdown/02-routing/01-intro.md index 33ea5b4..af05ec3 100644 --- a/docs/markdown/02-routing/01-intro.md +++ b/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 diff --git a/docs/markdown/02-routing/10-naming.md b/docs/markdown/02-routing/10-naming.md index 0e631a4..f4e8399 100644 --- a/docs/markdown/02-routing/10-naming.md +++ b/docs/markdown/02-routing/10-naming.md @@ -23,3 +23,21 @@ - **default** : (advanced) Fallback UI for parallel routes + +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 diff --git a/docs/markdown/02-routing/11-hierarchy.md b/docs/markdown/02-routing/11-hierarchy.md index a63a16d..7e4e2cb 100644 --- a/docs/markdown/02-routing/11-hierarchy.md +++ b/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 diff --git a/docs/markdown/02-routing/12-nesting.md b/docs/markdown/02-routing/12-nesting.md index 95fa439..822b1e5 100644 --- a/docs/markdown/02-routing/12-nesting.md +++ b/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 diff --git a/docs/markdown/02-routing/13-with-pages-router.md b/docs/markdown/02-routing/13-with-pages-router.md index 1314279..beec8c9 100644 --- a/docs/markdown/02-routing/13-with-pages-router.md +++ b/docs/markdown/02-routing/13-with-pages-router.md @@ -26,3 +26,13 @@ Routes : src directory : + +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) diff --git a/docs/markdown/02-routing/20-colocation.md b/docs/markdown/02-routing/20-colocation.md index 6865425..24c4b95 100644 --- a/docs/markdown/02-routing/20-colocation.md +++ b/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 : + +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 diff --git a/docs/markdown/02-routing/21-colocation-private.md b/docs/markdown/02-routing/21-colocation-private.md index e2752f9..e075682 100644 --- a/docs/markdown/02-routing/21-colocation-private.md +++ b/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

+ +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 diff --git a/docs/markdown/02-routing/30-pages.md b/docs/markdown/02-routing/30-pages.md index 7b372db..90eb289 100644 --- a/docs/markdown/02-routing/30-pages.md +++ b/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 diff --git a/docs/markdown/02-routing/31-pages-dynamic.md b/docs/markdown/02-routing/31-pages-dynamic.md index cbfeb35..68dc261 100644 --- a/docs/markdown/02-routing/31-pages-dynamic.md +++ b/docs/markdown/02-routing/31-pages-dynamic.md @@ -41,3 +41,15 @@ Optional catch all segments : + +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 diff --git a/docs/markdown/02-routing/40-layout.md b/docs/markdown/02-routing/40-layout.md index bfeb04d..5e184a3 100644 --- a/docs/markdown/02-routing/40-layout.md +++ b/docs/markdown/02-routing/40-layout.md @@ -39,3 +39,11 @@ const Layout: React.FC = ({ 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 diff --git a/docs/markdown/02-routing/41-root-layout.md b/docs/markdown/02-routing/41-root-layout.md index 3ff0106..2adec65 100644 --- a/docs/markdown/02-routing/41-root-layout.md +++ b/docs/markdown/02-routing/41-root-layout.md @@ -29,3 +29,9 @@ const RootLayout: React.FC = ({ 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 diff --git a/docs/markdown/02-routing/42-nested-layout.md b/docs/markdown/02-routing/42-nested-layout.md index 788e7dc..640cdbc 100644 --- a/docs/markdown/02-routing/42-nested-layout.md +++ b/docs/markdown/02-routing/42-nested-layout.md @@ -19,3 +19,13 @@ Layouts are always nested :

+ +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 diff --git a/docs/markdown/02-routing/43-template.md b/docs/markdown/02-routing/43-template.md index 20cf8cd..379690e 100644 --- a/docs/markdown/02-routing/43-template.md +++ b/docs/markdown/02-routing/43-template.md @@ -46,3 +46,13 @@ const Wrapper = () => { ``` + +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) diff --git a/docs/markdown/02-routing/44-groups.md b/docs/markdown/02-routing/44-groups.md index a7d0f1e..4d7ac4b 100644 --- a/docs/markdown/02-routing/44-groups.md +++ b/docs/markdown/02-routing/44-groups.md @@ -31,3 +31,7 @@ They can be used for : + +Notes: + +Groups, fonctionnalité incomprise de Next, mais pourtant très puissante diff --git a/docs/markdown/02-routing/50-advanced.md b/docs/markdown/02-routing/50-advanced.md index 4f0a1a9..af34da7 100644 --- a/docs/markdown/02-routing/50-advanced.md +++ b/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 diff --git a/docs/markdown/02-routing/51-advanced-parallel.md b/docs/markdown/02-routing/51-advanced-parallel.md index bcff988..ee30fa7 100644 --- a/docs/markdown/02-routing/51-advanced-parallel.md +++ b/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) diff --git a/docs/markdown/02-routing/52-advanced-intercept.md b/docs/markdown/02-routing/52-advanced-intercept.md index 366b2e5..63ddbdc 100644 --- a/docs/markdown/02-routing/52-advanced-intercept.md +++ b/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 ##--## + +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 diff --git a/docs/markdown/02-routing/53-advanced-intercept-patterns.md b/docs/markdown/02-routing/53-advanced-intercept-patterns.md index b46c281..126b169 100644 --- a/docs/markdown/02-routing/53-advanced-intercept-patterns.md +++ b/docs/markdown/02-routing/53-advanced-intercept-patterns.md @@ -32,3 +32,7 @@ Patterns :

+ +Notes: + +Les patterns fonctionnent comme une arborescence de fichiers linux diff --git a/docs/markdown/02-routing/54-advanced-intercept-modal.md b/docs/markdown/02-routing/54-advanced-intercept-modal.md index 4535a0e..20a8100 100644 --- a/docs/markdown/02-routing/54-advanced-intercept-modal.md +++ b/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 ##--## + +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 diff --git a/docs/markdown/02-routing/70-navigation.md b/docs/markdown/02-routing/70-navigation.md index 24c2754..7e5ba92 100644 --- a/docs/markdown/02-routing/70-navigation.md +++ b/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 diff --git a/docs/markdown/02-routing/71-link.md b/docs/markdown/02-routing/71-link.md index d5da572..d9b14e6 100644 --- a/docs/markdown/02-routing/71-link.md +++ b/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 diff --git a/docs/markdown/02-routing/72-userouter.md b/docs/markdown/02-routing/72-userouter.md index ae2a36e..f9f495b 100644 --- a/docs/markdown/02-routing/72-userouter.md +++ b/docs/markdown/02-routing/72-userouter.md @@ -38,3 +38,9 @@ const Component = ({ employeeId, employeeName }) => { return

You will be redirected in 5 seconds

; }; ``` + +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 diff --git a/docs/markdown/02-routing/73-history.md b/docs/markdown/02-routing/73-history.md index 08db1cc..76e882e 100644 --- a/docs/markdown/02-routing/73-history.md +++ b/docs/markdown/02-routing/73-history.md @@ -27,3 +27,16 @@ const Component = () => { return ; }; ``` + +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 diff --git a/docs/markdown/02-routing/74-redirect.md b/docs/markdown/02-routing/74-redirect.md index dd9b4a3..b5aec06 100644 --- a/docs/markdown/02-routing/74-redirect.md +++ b/docs/markdown/02-routing/74-redirect.md @@ -17,3 +17,11 @@ const ServerComponent = ({ user }) => { ``` ##--## + +Notes: + +On parlera des server components juste après + +Mais il faut savoir qu'on peut faire de la navigation côté serveur, grâce à la fonction redirect + +L'avantage est que c'est pas une redirection client. C'est une vraie redirection serveur, avec le bon status code diff --git a/docs/markdown/02-routing/75-hooks.md b/docs/markdown/02-routing/75-hooks.md index 88b77ad..3e15d54 100644 --- a/docs/markdown/02-routing/75-hooks.md +++ b/docs/markdown/02-routing/75-hooks.md @@ -47,3 +47,9 @@ export function Navigation() { ); } ``` + +Notes: + +Pour consulter l'état de la navigation, avant on avait un hook unique sur le pages router + +Maintenant c'est via des hooks dédiés diff --git a/docs/markdown/02-routing/76-serverside.md b/docs/markdown/02-routing/76-serverside.md index dbecb1d..7544aed 100644 --- a/docs/markdown/02-routing/76-serverside.md +++ b/docs/markdown/02-routing/76-serverside.md @@ -19,3 +19,16 @@ const Page = ({ params, searchParams }) => { ); }; ``` + +Notes: + +Du côté serveur, on expliquera un peu plus tard ce que ça implique + +Mais on peut récupérer : + +- les paramètres dynamiques d'URL +- les query params + +Uniquement dans les pages + +Donc il faudra le faire descendre si on en a besoin plus loin dans la hiérarchie de composants diff --git a/docs/markdown/03-server-components/01-intro.md b/docs/markdown/03-server-components/01-intro.md index 0a6c82b..5420694 100644 --- a/docs/markdown/03-server-components/01-intro.md +++ b/docs/markdown/03-server-components/01-intro.md @@ -8,3 +8,13 @@ - Better SEO - Less client complexity - Better security + +Notes: + +Avant d'essayer de comprendre quels sont les patterns des RSC, essayons de comprendre pourquoi ils existent + +Ils répondent à plusieurs besoins + +Tous autour de la même logique => le serveur est le point central de l'application + +Pour mieux comprendre pourquoi, on doit passer en revue l'évolution des méthodes de rendu diff --git a/docs/markdown/03-server-components/10-csr.md b/docs/markdown/03-server-components/10-csr.md index 55a6069..641d7a4 100644 --- a/docs/markdown/03-server-components/10-csr.md +++ b/docs/markdown/03-server-components/10-csr.md @@ -39,3 +39,11 @@ ReactDOM.createRoot(rootElement).render(); + +Notes: + +les applications React à l'origine était quasiment toutes des SPA, rendues uniquement côté client + +Ce que le navigateur reçoit : une page HTML vide + +- un script chargé de booter l'application avec React et React-Dom diff --git a/docs/markdown/03-server-components/11-csr-workflow.md b/docs/markdown/03-server-components/11-csr-workflow.md index 96a956e..249338e 100644 --- a/docs/markdown/03-server-components/11-csr-workflow.md +++ b/docs/markdown/03-server-components/11-csr-workflow.md @@ -20,3 +20,7 @@ Cons : - Bad SEO - A lot a JavaScript - Network blocking requests + +Notes: + +Description du workflow et explication des inconvénients du full CSR diff --git a/docs/markdown/03-server-components/13-ssr.md b/docs/markdown/03-server-components/13-ssr.md index 469cec6..53a96bd 100644 --- a/docs/markdown/03-server-components/13-ssr.md +++ b/docs/markdown/03-server-components/13-ssr.md @@ -39,3 +39,11 @@ app.use('/employees/:id', async (req, res) => { res.send(html); }); ``` + +Notes: + +pendant longtemps, React c'était pour le CSR, et pour le SSR on utilisait des technos dédiées (Java / PHP etc...) + +Mais on a fini par réaliser qu'on pouvait utiliser les technos JavaScript pour faire le rendu côté serveur + +On fait globalement la même chose, mais à la demande des utilisateurs, sur un serveur au lieu du navigateur diff --git a/docs/markdown/03-server-components/14-ssr2.md b/docs/markdown/03-server-components/14-ssr2.md index 174305f..0cd53d3 100644 --- a/docs/markdown/03-server-components/14-ssr2.md +++ b/docs/markdown/03-server-components/14-ssr2.md @@ -36,3 +36,19 @@ import App from './App.jsx'; const rootElement = document.getElementById('root'); hydrateRoot(rootElement, ); ``` + +Notes: + +On a toujours besoin de rendre nos applications interactives : c'est le but de React + +Donc on charge toujours un script + +Mais plutôt que de render toute l'application à partir d'une feuille blanche, on vient se brancher au DOM existant + +Et on vient seulement : + +- enregistrer les event listeners +- Ajouter le rendu conditionnel +- Charger les scripts manquants + +Ce process, c'est l'hydration diff --git a/docs/markdown/03-server-components/15-ssr3.md b/docs/markdown/03-server-components/15-ssr3.md index 846ee43..0e0d573 100644 --- a/docs/markdown/03-server-components/15-ssr3.md +++ b/docs/markdown/03-server-components/15-ssr3.md @@ -48,3 +48,15 @@ const data = JSON.parse(dataElement.innerText); hydrateRoot(rootElement, ); ``` + +Notes: + +Mais comment on gère la data dans tout ça ? + +Le serveur a récupéré la data + +Pour hydrater l'application, le script client en a besoin aussi + +Pour ça, on passe la donnée inlinée dans le DOM + +-> Démo sur un site en live diff --git a/docs/markdown/03-server-components/16-ssr-next.md b/docs/markdown/03-server-components/16-ssr-next.md index bb58520..299fbef 100644 --- a/docs/markdown/03-server-components/16-ssr-next.md +++ b/docs/markdown/03-server-components/16-ssr-next.md @@ -27,3 +27,9 @@ export default function EmployeePage({ employee }) { ); } ``` + +Notes: + +Sur NextJs, c'est le fonctionnement qu'on retrouve sur le pages router + +getServerSideProps => chargement de la donnée côté serveur + sérialisation diff --git a/docs/markdown/03-server-components/17-ssr-workflow.md b/docs/markdown/03-server-components/17-ssr-workflow.md index bdf721a..4ce4162 100644 --- a/docs/markdown/03-server-components/17-ssr-workflow.md +++ b/docs/markdown/03-server-components/17-ssr-workflow.md @@ -18,3 +18,7 @@ Pros : - Better first loading performance - Better SEO + +Notes: + +Présentation du workflow SSR diff --git a/docs/markdown/03-server-components/18-hydration-cons.md b/docs/markdown/03-server-components/18-hydration-cons.md index 8ed4afa..f9cd82b 100644 --- a/docs/markdown/03-server-components/18-hydration-cons.md +++ b/docs/markdown/03-server-components/18-hydration-cons.md @@ -10,3 +10,9 @@ - The whole page is hydrated at once - Even non-interactive components are hydrated - Non standard (every framework has its own aproach) + +Notes: + +Tout n'est pas encore parfait + +Explication de chaque inconvénient diff --git a/docs/markdown/03-server-components/20-server-components.md b/docs/markdown/03-server-components/20-server-components.md index 4f95b83..ca38fa2 100644 --- a/docs/markdown/03-server-components/20-server-components.md +++ b/docs/markdown/03-server-components/20-server-components.md @@ -34,3 +34,19 @@ Generated HTML ``` + +Notes: + +Solution à ça : les server component + +Ils ne s'éxécutent que côté serveur + +L'application n'est plus hydratée entièrement + +Donc ils ne génèrent pas de JavaScript + +Ils ne génèrent non pas du HTML, mais un "RSC payload" qui est la représentation du server component et de son arbo + +C'est ce qui permet une communication client / server, et à l'hydration sélective de s'y retrouver + +Présentation sur un site en live diff --git a/docs/markdown/03-server-components/21-heavy-work.md b/docs/markdown/03-server-components/21-heavy-work.md index 30b2ba0..2110f51 100644 --- a/docs/markdown/03-server-components/21-heavy-work.md +++ b/docs/markdown/03-server-components/21-heavy-work.md @@ -19,3 +19,11 @@ const CodeBlock = async ({ code }) => { ``` ##--## + +Notes: + +Avantage : permet d'éviter d'envoyer de grosses librairies côté client + +On peut éxécuter du code uniquement côté serveur et n'envoyer que le RSC payload + +Ce n'était pas possible avant avec le pages routes, même pour des composants non interactifs diff --git a/docs/markdown/03-server-components/22-security.md b/docs/markdown/03-server-components/22-security.md index 8fc44d5..0bcb69c 100644 --- a/docs/markdown/03-server-components/22-security.md +++ b/docs/markdown/03-server-components/22-security.md @@ -36,3 +36,11 @@ const EmployeesPage = async () => { }; export default EmployeesPage; ``` + +Notes: + +Avantage : sécurité + +Permet de s'assurer que du code est joué uniquement sur le serveur, et qu'il ne sera jamais envyué au client + +Permet également l'utilisation de async, donc permet les taches asynchrones comme le chargement de donnée diff --git a/docs/markdown/03-server-components/23-node-api.md b/docs/markdown/03-server-components/23-node-api.md index 8bd7b22..0617eb4 100644 --- a/docs/markdown/03-server-components/23-node-api.md +++ b/docs/markdown/03-server-components/23-node-api.md @@ -42,3 +42,11 @@ const LogViewer = async () => { ); }; ``` + +Notes: + +Vu qu'ils ne sont joués qu'une seule fois et sur le serveur, ils permettent d'accéder aux apis nodejs + +On peut faire la comparaison avec PHP : le langage a accès à toutes les ressources du serveur + +Il n'y a que dans certains cas bien particuliers qu'on décide d'insérer du code "client" via un "script" diff --git a/docs/markdown/03-server-components/24-client-server.md b/docs/markdown/03-server-components/24-client-server.md index 29fc35f..c141c29 100644 --- a/docs/markdown/03-server-components/24-client-server.md +++ b/docs/markdown/03-server-components/24-client-server.md @@ -23,3 +23,11 @@ const MyComponent = () => { return

Hello World!

; }; ``` + +Notes: + +Justement, si on veut faire l'équivalent d'un script en PHP, on peut ajouter un "use client" sur un composant + +ça signifie alors qu'il sera éxécuté une fois, lors du rendu initial côté serveur + +Puis une ou plusieurs fois côté client, selon son cycle de vie diff --git a/docs/markdown/03-server-components/31-rules-hooks.md b/docs/markdown/03-server-components/31-rules-hooks.md index 02bd428..b31212b 100644 --- a/docs/markdown/03-server-components/31-rules-hooks.md +++ b/docs/markdown/03-server-components/31-rules-hooks.md @@ -26,3 +26,19 @@ const Timer = () => { return Seconds : {count} } ``` + +Notes: + +Maintenant qu'on comprend pourquoi les RSC existent, on va se pencher sur les règles d'utilisation + +Quand on sait pourquoi ils existent, normalement ça devrait paraitre assez logique + +à partir du moment où un composant a de l'interactivité : hooks, contextes, event handlers + +Ils ne peuvent pas être rendus uniquement côté serveur + +Sinon toute cette interactivité ne pourrait pas être mise en oeuvre dans le navigateur + +Donc pour dire qu'un composant doit être rendu de manière classique, "use client" + +ce qui ne l'empêche pas d'être rendu côté serveur. C'est juste que ses éléments interactifs seront ignorés dans le rendu initial diff --git a/docs/markdown/03-server-components/32-rules-import.md b/docs/markdown/03-server-components/32-rules-import.md index 00cf459..e29970f 100644 --- a/docs/markdown/03-server-components/32-rules-import.md +++ b/docs/markdown/03-server-components/32-rules-import.md @@ -29,3 +29,13 @@ If all the components are Server Components, the property will never change beca + +Notes: + +On peut faire de la composition avec des server components, et donc passer des props + +Est-ce qu'un changement de props causera un re-render ? Non ! + +Mais si toute l'arbo de composant est des RSC, alors il n'y aura jamais de changement de props car rien ne peut le causer + +Le rendu côté serveur est fait en one-shot, pas de re-render possible diff --git a/docs/markdown/03-server-components/33-boundaries.md b/docs/markdown/03-server-components/33-boundaries.md index 51f07b9..a6a07dc 100644 --- a/docs/markdown/03-server-components/33-boundaries.md +++ b/docs/markdown/03-server-components/33-boundaries.md @@ -22,3 +22,13 @@ + +Notes: + +Un composant sans "use client" importé dans un client component devient automatiquement un client-component + +Ce qui signifie qu'il peut être re-render si il y'a un changement de props + +Et donc, premier point de vigilance à avoir : il ne faut pas que ce composant fasse des choses impossibles à faire côté client + +Comme faire du rendu asynchrone, charger de la donnée ou utiliser les API Node.js diff --git a/docs/markdown/03-server-components/34-boundaries-invalid.md b/docs/markdown/03-server-components/34-boundaries-invalid.md index a6fb42d..9cac1e0 100644 --- a/docs/markdown/03-server-components/34-boundaries-invalid.md +++ b/docs/markdown/03-server-components/34-boundaries-invalid.md @@ -30,3 +30,7 @@ It's impossible to import it from a client-component : + +Notes: + +Exemple d'import impossible à faire diff --git a/docs/markdown/03-server-components/35-composition.md b/docs/markdown/03-server-components/35-composition.md index 41fbf83..33380a9 100644 --- a/docs/markdown/03-server-components/35-composition.md +++ b/docs/markdown/03-server-components/35-composition.md @@ -48,3 +48,11 @@ And the component tree : + +Notes: + +On est pas condamnés à n'avoir que des client-components + +On a des patterns de composition à notre disposition qui nous permettent de le gérer + +Par exemple, on peut passer un server component à un client component en tant que props (children ou props) diff --git a/docs/markdown/03-server-components/37-composition2.md b/docs/markdown/03-server-components/37-composition2.md index bf5d40f..a0ef558 100644 --- a/docs/markdown/03-server-components/37-composition2.md +++ b/docs/markdown/03-server-components/37-composition2.md @@ -47,3 +47,11 @@ Client boundary is much smaller + +Notes: + +Donc la réponse est non : on est pas condamnés à n'avoir que des client components dans le bas de l'arborescence + +Le tout est de visualiser correctement l'arborescence, bien découper les composants et gérer correctement la composition + +C'est d'autant plus important avec les Server Components que sur les autres applications React "classiques" diff --git a/docs/markdown/03-server-components/38-recap.md b/docs/markdown/03-server-components/38-recap.md index bd0f14c..309f55f 100644 --- a/docs/markdown/03-server-components/38-recap.md +++ b/docs/markdown/03-server-components/38-recap.md @@ -13,3 +13,9 @@ # Let's summarise + +Notes: + +Quand utiliser un server component ? + +La réponse fournie par NExt.js