En 2013, j'ai décidé de créer pour le développement d'applications Web. Le meilleur résultat de ce processus est peut-être , un framework frontend JS pur côté client écrit en 2 000 lignes de code. un ensemble d'outils minimalistes gotoB J'ai été motivé à écrire cet article après avoir lu des articles intéressants rédigés par des auteurs de frameworks frontend très réussis : Tout d'abord, Rich Harris a écrit sur , qui sont basées sur des signaux. l'introduction des runes dans Svelte Cela m'a conduit à deux articles de Ryan Carniato, l'un expliquant l'évolution des et l'autre décrivant . signaux les signaux, notamment dans le contexte de SolidJS L'article de Ryan m'a conduit à deux articles de Michael Westrate, où il décrit et . les principes derrière MobX comment ils sont mis en œuvre Ce qui m'a enthousiasmé dans ces articles, c'est qu'ils parlent de l'évolution des derrière ce qu'ils construisent ; la mise en œuvre n'est qu'un moyen de les rendre réelles, et les seules fonctionnalités abordées sont celles qui sont si essentielles qu'elles représentent les idées elles-mêmes. idées De loin, l'aspect le plus intéressant de ce qui est ressorti de gotoB est les idées qui ont émergé suite aux défis de sa construction. C'est ce que je veux aborder ici. Parce que j'ai construit le framework à partir de zéro et que j'essayais d'atteindre à la fois le minimalisme et la cohérence interne, j'ai résolu quatre problèmes d'une manière qui, je pense, est différente de la manière dont la plupart des frameworks résolvent les mêmes problèmes. Ces quatre idées sont celles que je souhaite partager avec vous maintenant. Je ne le fais pas pour vous convaincre d'utiliser mes outils (même si vous êtes le bienvenu !), mais plutôt dans l'espoir que ces idées pourraient vous intéresser. Idée 1 : littéraux d'objet pour résoudre le problème de création de modèles Toute application Web doit créer du balisage (HTML) à la volée, en fonction de l'état de l'application. Cela s'explique mieux avec un exemple : dans une application de liste de tâches ultra-simple, l'état pourrait être une liste de tâches : . Étant donné que vous écrivez une application (par opposition à une page statique), la liste de tâches doit pouvoir changer. ['Item 1', 'Item 2'] Étant donné que l'état change, le code HTML qui constitue l'interface utilisateur de votre application doit changer en fonction de l'état. Par exemple, pour afficher vos tâches, vous pouvez utiliser le code HTML suivant : <ul> <li>Item 1</li> <li>Item 2</li> </ul> Si l'état change et qu'un troisième élément est ajouté, votre état ressemblera désormais à ceci : ; ensuite, votre HTML devrait ressembler à ceci : ['Item 1', 'Item 2', 'Item 3'] <ul> <li>Item 1</li> <li>Item 2</li> <li>Item 3</li> </ul> Le problème de la génération de HTML en fonction de l'état de l'application est généralement résolu avec un , qui insère des constructions de langage de programmation (variables, conditions et boucles) dans du pseudo-HTML qui est ensuite étendu en HTML réel. langage de création de modèles Par exemple, voici deux manières de procéder dans différents outils de création de modèles : // Assume that `todos` is defined and equal to ['Item 1', 'Item 2', 'Item 3'] // Moustache <ul> {{#todos}} <li>{{.}}</li> {{/todos}} </ul> // JSX <ul> {todos.map((item, index) => ( <li key={index}>{item}</li> ))} </ul> Je n'ai jamais aimé ces syntaxes qui apportaient de la logique au HTML. Réalisant que la création de modèles nécessitait de la programmation et voulant éviter d'avoir une syntaxe distincte pour cela, j'ai décidé d'apporter du HTML au js, en utilisant . Ainsi, je pouvais simplement modéliser mon HTML sous forme de littéraux d'objet : des littéraux d'objet ['ul', [ ['li', 'Item 1'], ['li', 'Item 2'], ['li', 'Item 3'], ]] Si je voulais ensuite utiliser l'itération pour générer la liste, je pourrais simplement écrire : ['ul', items.map ((item) => ['li', item])] Et ensuite, utilisez une fonction qui convertirait cet objet littéral en HTML. De cette façon, tout le template peut être réalisé en JS, sans aucun langage de template ou de transpilation. J'utilise le nom pour décrire ces tableaux qui représentent du HTML. liths À ma connaissance, aucun autre framework JS n'aborde la création de modèles de cette manière. J'ai fait quelques recherches et j'ai trouvé , qui utilise presque la même structure pour représenter le HTML dans les objets JSON (qui sont presque les mêmes que les littéraux d'objet JS), mais je n'ai trouvé aucun framework construit autour de lui. JSONML et se rapprochent assez de l’approche que j’ai utilisée, mais ils utilisent toujours des appels de fonction pour chaque élément. Mithril Hyperapp // Mithril m("ul", [ m("li", "Item 1"), m("li", "Item 2") ]) // hyperapp h("ul", [ h("li", "Item 1"), h("li", "Item 2") ]) L’approche consistant à utiliser des littéraux d’objet a bien fonctionné pour HTML, je l’ai donc étendue au CSS et je génère désormais également tout mon CSS via des littéraux d’objet. Si, pour une raison quelconque, vous vous trouvez dans un environnement où vous ne pouvez pas transpiler JSX ou utiliser un langage de création de modèles et que vous ne souhaitez pas concaténer de chaînes, vous pouvez utiliser cette approche à la place. Je ne suis pas sûr que l'approche Mithril/Hyperapp soit meilleure que la mienne ; je trouve que lorsque j'écris de longs littéraux d'objet représentant des liths, j'oublie parfois une virgule quelque part et cela peut parfois être difficile à trouver. À part cela, je n'ai vraiment rien à redire. Et j'aime le fait que la représentation pour HTML soit à la fois 1) des données et 2) en JS. Cette représentation peut en fait fonctionner comme un DOM virtuel, comme nous le verrons lorsque nous arriverons à l'idée n°4. Détail bonus : si vous souhaitez générer du HTML à partir de littéraux d'objet, vous n'avez qu'à résoudre les deux problèmes suivants : Entityifier les chaînes (c'est-à-dire : échapper les caractères spéciaux). Sachez quelles balises fermer et lesquelles ne pas fermer. Idée 2 : un magasin global adressable via des chemins pour contenir tous les états des applications Je n'ai jamais été fan des composants. Structurer une application autour de composants nécessite de placer les données appartenant au composant à l'intérieur du composant lui-même. Cela rend difficile, voire impossible, le partage de ces données avec d'autres parties de l'application. Dans projet sur lequel j'ai travaillé, j'ai constaté que j'avais toujours besoin que certaines parties de l'état de l'application soient partagées entre des composants assez éloignés les uns des autres. Un exemple typique est le nom d'utilisateur : vous pourriez en avoir besoin dans la section compte, et également dans l'en-tête. Alors, où se trouve le nom d'utilisateur ? chaque J'ai donc décidé très tôt de créer un objet de données simple ( ) et d'y placer tout mon état. Je l'ai appelé le . Le store contient l'état de toutes les parties de l'application et peut donc être utilisé par n'importe quel composant. {} store Cette approche était quelque peu hérétique en 2013-2015, mais elle a depuis gagné en prévalence et même en domination. Ce qui me semble encore assez nouveau, c'est que j'utilise pour accéder à n'importe quelle valeur à l'intérieur du magasin. Par exemple, si le magasin est : des chemins { user: { firstName: 'foo' lastName: 'bar' } } Je peux utiliser un chemin pour accéder (par exemple) au , en écrivant . Comme vous pouvez le voir, est le vers . est une fonction qui accède au store et renvoie une partie spécifique de celui-ci, indiquée par le chemin que vous passez à la fonction. lastName B.get ('user', 'lastName') ['user', 'lastName'] chemin 'bar' B.get Contrairement à ce qui précède, la méthode standard pour accéder aux propriétés réactives consiste à les référencer via une variable JS. Par exemple : // Svelte let { firstName, lastName } = $props(); firstName = 'foo'; lastName = 'bar'; // Knockout const firstName = ko.observable('foo'); const lastName = ko.observable('bar'); // mobx class UserStore { firstName = 'foo'; lastName = 'bar'; constructor() { makeAutoObservable(this); } } const userStore = new UserStore(); // SolidJS const [firstName, setFirstName] = createSignal('foo'); const [lastName, setLastName] = createSignal('bar'); Cela nécessite cependant que vous conserviez une référence à et (ou ) partout où vous avez besoin de cette valeur. L'approche que j'utilise nécessite uniquement que vous ayez accès au magasin (qui est global et disponible partout) et vous permet d'y avoir un accès précis sans définir de variables JS pour eux. firstName lastName userStore Immutable.js et la base de données en temps réel Firebase font quelque chose de beaucoup plus proche de ce que j'ai fait, bien qu'ils fonctionnent sur des objets distincts. Mais vous pourriez potentiellement les utiliser pour tout stocker dans un seul endroit qui pourrait être adressable de manière granulaire. // Immutable.js let store = Map({ user: Map({ firstName: 'foo', lastName: 'bar' }) }); const firstName = store.getIn(['user', 'firstName']); // 'foo' // Firebase const db = firebase.database(); db.ref('user').set({ firstName: 'foo', lastName: 'bar' }); db.ref('user/firstName').once('value').then(snapshot => { const firstName = snapshot.val(); // 'foo' }); Avoir mes données dans un magasin accessible globalement et auquel on peut accéder de manière granulaire via des chemins est un modèle que j'ai trouvé extrêmement utile. Chaque fois que j'écris ou quelque chose comme ça, cela me semble redondant. Je sais que je pourrais simplement faire chaque fois que j'ai besoin d'y accéder, sans avoir à déclarer et à transmettre ou . const [count, setCount] = ... B.get ('count') count setCount Idée 3 : chaque changement s'exprime à travers des événements Si l'idée n°2 (un magasin global accessible via des chemins) libère les données des composants, l'idée n°3 est la façon dont j'ai libéré le code des composants. Pour moi, c'est l'idée la plus intéressante de cet article. La voici ! Notre état est une donnée qui, par définition, est mutable (pour ceux qui utilisent l'immuabilité, l'argument tient toujours : vous voulez toujours que la version de l'état change, même si vous conservez des instantanés des anciennes versions de l'état). Comment pouvons-nous changer l'état ? dernière J'ai décidé d'utiliser des événements. J'avais déjà des chemins vers le magasin, donc un événement pourrait être simplement la combinaison d'un verbe (comme , ou ) et d'un chemin. Donc, si je voulais mettre à jour , je pourrais écrire quelque chose comme ceci : set add rem user.firstName B.call ('set', ['user', 'firstName'], 'Foo') C'est certainement plus verbeux que d'écrire : user.firstName = 'Foo'; Mais cela m'a permis d'écrire du code qui à un changement dans . Et c'est là l'idée cruciale : dans une interface utilisateur, il existe différentes parties qui dépendent de différentes parties de l'état. Par exemple, vous pourriez avoir ces dépendances : répondrait user.firstName En-tête : dépend de et user currentView Section Compte : dépend de user Liste de tâches : dépend des items La grande question à laquelle j'ai été confrontée était la suivante : comment mettre à jour l'en-tête et la section du compte lorsque change, mais pas lorsque changent ? Et comment gérer ces dépendances sans avoir à effectuer des appels spécifiques tels que ou ? Ces types d'appels spécifiques représentent la « programmation jQuery » dans sa forme la plus difficile à maintenir. user items updateHeader updateAccountSection Ce qui me semblait être une meilleure idée était de faire quelque chose comme ceci : B.respond ('set', [['user'], ['currentView']], function (user, currentView) { // Update the header }); B.respond ('set', ['user'], function (user) { // Update the account section }); B.respond ('set', ['items'], function (items) { // Update the todo list }); Ainsi, si un événement est appelé pour , le système d'événements notifiera toutes les vues intéressées par ce changement (section en-tête et compte), tout en laissant les autres vues (liste de tâches) intactes. est la fonction que j'utilise pour enregistrer (qui sont généralement appelés « écouteurs d'événements » ou « réactions »). Notez que les répondeurs sont globaux et ne sont liés à aucun composant ; ils n'écoutent cependant que les événements sur certains chemins. set user B.respond les répondeurs set Maintenant, comment un événement est-il appelé en premier lieu ? Voici comment je l'ai fait : change B.respond ('set', '*', function () { // Assume that `path` is the path on which set was called B.call ('change', path); }); Je simplifie un peu, mais c'est essentiellement ainsi que cela fonctionne dans gotoB. . Dans l'exemple ci-dessus, si vous appelez , deux morceaux de code sont exécutés : celui qui modifie l'en-tête et celui qui modifie la vue du compte. Notez que l'appel à update ne se soucie pas de savoir qui écoute cela. Il fait simplement son travail et laisse le répondeur récupérer les modifications. Ce qui rend un système d'événements plus puissant que de simples appels de fonctions, c'est qu'un appel d'événement peut exécuter 0, 1 ou plusieurs morceaux de code, alors qu'un appel de fonction appelle toujours exactement une fonction B.call ('set', ['user', 'firstName'], 'Foo'); firstName Les événements sont si puissants que, d'après mon expérience, ils peuvent remplacer des valeurs calculées, ainsi que des réactions. En d'autres termes, ils peuvent être utilisés pour exprimer tout changement devant se produire dans une application. Une valeur calculée peut être exprimée avec un répondeur d'événements. Par exemple, si vous souhaitez calculer un et que vous ne souhaitez pas l'utiliser dans le magasin, vous pouvez procéder comme suit : fullName B.respond ('set', 'user', function () { var user = B.get ('user'); var fullName = user.firstName + ' ' + user.lastName; // Do something with `fullName` here. }); De même, des réactions peuvent être exprimées avec un répondant. Considérez ceci : B.respond ('set', 'user', function () { var user = B.get ('user'); var fullName = user.firstName + ' ' + user.lastName; document.getElementById ('header').innerHTML = '<h1>Hello, ' + fullName + '</h1>'; }); Si vous ignorez une minute la concaténation gênante de chaînes pour générer du HTML, ce que vous voyez ci-dessus est un répondeur exécutant un « effet secondaire » (dans ce cas, la mise à jour du DOM). (Remarque : quelle serait une bonne définition d'un effet secondaire, dans le contexte d'une application Web ? Pour moi, cela se résume à trois choses : 1) une mise à jour de l'état de l'application ; 2) une modification du DOM ; 3) l'envoi d'un appel AJAX). J'ai découvert qu'il n'y avait vraiment pas besoin d'un cycle de vie séparé qui mette à jour le DOM. Dans gotoB, il existe des fonctions de réponse qui mettent à jour le DOM à l'aide de certaines fonctions d'assistance. Ainsi, lorsque change, tout répondeur (ou plus précisément, , puisque c'est le nom que je donne aux répondeurs chargés de mettre à jour une partie du DOM) qui en dépend s'exécutera, générant un effet secondaire qui finit par mettre à jour le DOM. user fonction d'affichage J'ai rendu le système d'événements prévisible en lui faisant exécuter les fonctions de réponse dans le même ordre, et une à la fois. Les répondeurs asynchrones peuvent toujours s'exécuter de manière synchrone, et les répondeurs qui viennent « après » eux les attendront. Des modèles plus sophistiqués, où vous devez mettre à jour l'état sans mettre à jour le DOM (généralement pour des raisons de performances), peuvent être ajoutés en ajoutant , comme , qui modifient le magasin mais ne déclenchent aucun répondeur. De plus, si vous devez faire quelque chose sur le DOM un redessin, vous pouvez simplement vous assurer que ce répondeur a une faible priorité et s'exécute après tous les autres répondeurs : des verbes muets mset après B.respond ('set', 'date', {priority: -1000}, function () { var datePicker = document.getElementById ('datepicker'); // Do something with the date picker }); L'approche ci-dessus, qui consiste à disposer d'un système d'événements utilisant des verbes et des chemins et un ensemble de répondeurs globaux qui sont mis en correspondance (exécutés) par certains appels d'événements, présente un autre avantage : chaque appel d'événement peut être placé dans une liste. Vous pouvez ensuite analyser cette liste lorsque vous déboguez votre application et suivre les modifications apportées à l'état. Dans le contexte d'un frontend, voici ce que permettent les événements et les répondeurs : Pour mettre à jour des parties du magasin avec très peu de code (juste un peu plus verbeux qu'une simple affectation de variable). Pour que certaines parties du DOM se mettent à jour automatiquement lorsqu'un changement se produit sur les parties de la boutique dont dépend cette partie du DOM. Pour qu'aucune partie du DOM ne se mette à jour automatiquement lorsqu'elle n'est pas nécessaire. Pour pouvoir avoir des valeurs calculées et des réactions qui ne concernent pas la mise à jour du DOM, exprimées en tant que répondeurs. Voilà ce qu'ils permettent (d'après mon expérience) de faire sans : Méthodes ou hooks du cycle de vie. Observables. Immutabilité. Mémorisation. En fait, il s'agit simplement d'appels d'événements et de répondeurs, certains répondeurs ne s'occupent que des vues, et d'autres d'autres opérations. Tous les éléments internes du framework utilisent simplement . l'espace utilisateur Si vous êtes curieux de savoir comment cela fonctionne dans gotoB, vous pouvez consulter cette . explication détaillée Idée 4 : un algorithme de comparaison de texte pour mettre à jour le DOM semble aujourd'hui assez dépassée. Mais si vous prenez une machine à remonter le temps jusqu'en 2013 et que vous abordez à partir des premiers principes le problème de redessiner le DOM lorsque l'état change, qu'est-ce qui semblerait plus raisonnable ? La liaison de données bidirectionnelle Si le HTML change, mettez à jour votre état dans JS. Si l'état dans JS change, mettez à jour le HTML. Chaque fois que l'état dans JS change, mettez à jour le code HTML. Si le code HTML change, mettez à jour l'état dans JS, puis mettez à jour à nouveau le code HTML pour qu'il corresponde à l'état dans JS. En effet, l’option 2, qui est le flux de données unidirectionnel de l’état vers le DOM, semble plus compliquée et inefficace. Concrétisons maintenant cela : dans le cas d'une ou interactive qui est focalisée, vous devez recréer des parties du DOM à chaque frappe de touche de l'utilisateur ! Si vous utilisez des flux de données unidirectionnels, chaque changement dans l'entrée déclenche un changement d'état, qui redessine ensuite l' pour qu'elle corresponde exactement à ce qu'elle devrait être. <input> <textarea> <input> Cela place la barre très haut pour les mises à jour du DOM : elles doivent être rapides et ne pas gêner l'interaction de l'utilisateur avec les éléments interactifs. Ce n'est pas un problème facile à résoudre. Maintenant, pourquoi les données unidirectionnelles de l'état vers le DOM (JS vers HTML) ont-elles gagné ? Parce que c'est plus facile à comprendre. Si l'état change, peu importe d'où vient ce changement (cela peut être un rappel AJAX apportant des données du serveur, une interaction de l'utilisateur, un minuteur). L'état change (ou plutôt, ) de la même manière toujours. Et les changements de l'état se répercutent toujours dans le DOM. est muté Alors, comment effectuer des mises à jour du DOM de manière efficace sans gêner l'interaction de l'utilisateur ? Cela se résume généralement à effectuer le nombre minimum de mises à jour du DOM qui permettront d'accomplir le travail. C'est ce qu'on appelle généralement « diffing », car vous établissez une liste de différences dont vous avez besoin pour prendre une ancienne structure (le DOM existant) et la convertir en une nouvelle (le nouveau DOM après la mise à jour de l'état). Lorsque j'ai commencé à travailler sur ce problème vers 2016, j'ai triché en regardant ce que faisait React. Ils m'ont donné l'idée cruciale qu'il n'existait pas d'algorithme généralisé et linéaire pour différencier deux arbres (le DOM est un arbre). Mais, têtu s'il en est, je voulais toujours un algorithme à usage général pour effectuer la comparaison. Ce que je n'ai pas particulièrement apprécié dans React (ou presque n'importe quel framework d'ailleurs), c'est l'insistance sur le fait que vous devez utiliser des clés pour les éléments contigus : function MyList() { const items = ['Item 1', 'Item 2', 'Item 3']; return ( <ul> {items.map((item, index) => ( <li key={index}>{item}</li> ))} </ul> ); } Pour moi, la directive était superflue, car elle n'avait rien à voir avec le DOM ; c'était juste une indication du framework. key Ensuite, j'ai pensé à essayer un algorithme de comparaison textuelle sur des versions aplaties d'un arbre. Et si j'aplatissais les deux arbres (l'ancien morceau de DOM que j'avais et le nouveau morceau de DOM par lequel je voulais le remplacer) et que je calculais une sur celui-ci (un ensemble minimum de modifications), afin de pouvoir passer de l'ancien au nouveau en un nombre d'étapes plus réduit ? diff J'ai donc pris l' , celui que vous utilisez à chaque fois que vous exécutez , et je l'ai mis en œuvre sur mes arbres aplatis. Illustrons cela avec un exemple : algorithme de Myers git diff var oldList = ['ul', [ ['li', 'Item 1'], ['li', 'Item 2'], ]]; var newList = ['ul', [ ['li', 'Item 1'], ['li', 'Item 2'], ['li', 'Item 3'], ]]; Comme vous pouvez le voir, je ne travaille pas avec le DOM, mais avec la représentation littérale d'objet que nous avons vue sur l'idée 1. Maintenant, vous remarquerez que nous devons ajouter un nouveau à la fin de la liste. <li> Les arbres aplatis ressemblent à ceci : var oldFlattened = ['O ul', 'O li', 'L Item 1', 'C li', 'O li', 'L Item 2', 'C li', 'C ul']; var newFlattened = ['O ul', 'O li', 'L Item 1', 'C li', 'O li', 'L Item 2', 'C li', 'O li', 'L Item 3', 'C li', 'C ul']; Le signifie « balise ouverte », le signifie « littéral » (dans ce cas, du texte) et le signifie « balise fermée ». Notez que chaque arbre est maintenant une liste de chaînes et qu'il n'y a plus de tableaux imbriqués. C'est ce que j'entends par aplatissement. O L C Lorsque j'exécute une comparaison sur chacun de ces éléments (en traitant chaque élément du tableau comme s'il s'agissait d'une unité), j'obtiens : var diff = [ ['keep', 'O ul'] ['keep', 'O li'] ['keep', 'L Item 1'] ['keep', 'C li'] ['keep', 'O li'] ['keep', 'L Item 2'] ['keep', 'C li'] ['add', 'O li'] ['add', 'L Item 3'] ['add', 'C li'] ['keep', 'C ul'] ]; Comme vous l'avez probablement déduit, nous conservons la majeure partie de la liste et ajoutons un vers la fin de celle-ci. Ce sont les entrées que vous voyez. <li> add Si nous changions maintenant le texte du troisième de à et que nous exécutions une comparaison dessus, nous obtiendrions : <li> Item 3 Item 4 var diff = [ ['keep', 'O ul'] ['keep', 'O li'] ['keep', 'L Item 1'] ['keep', 'C li'] ['keep', 'O li'] ['keep', 'L Item 2'] ['keep', 'C li'] ['keep', 'O li'] ['rem', 'L Item 3'] ['add', 'L Item 4'] ['keep', 'C li'] ['keep', 'C ul'] ]; Je ne sais pas à quel point cette approche est mathématiquement inefficace, mais en pratique, elle fonctionne plutôt bien. Elle ne fonctionne mal que lors de la comparaison de grands arbres qui présentent de nombreuses différences entre eux ; lorsque cela se produit occasionnellement, j'ai recours à un délai d'attente de 200 ms pour interrompre la comparaison et remplacer simplement la partie incriminée du DOM. Si je n'utilisais pas de délai d'attente, l'application entière se bloquerait pendant un certain temps jusqu'à ce que la comparaison soit terminée. L'un des avantages de l'utilisation de la comparaison Myers est qu'elle donne la priorité aux suppressions plutôt qu'aux insertions : cela signifie que s'il existe un choix tout aussi efficace entre la suppression d'un élément et l'ajout d'un élément, l'algorithme supprimera d'abord un élément. En pratique, cela me permet de récupérer tous les éléments DOM éliminés et de pouvoir les recycler si j'en ai besoin plus tard dans la comparaison. Dans le dernier exemple, le dernier est recyclé en changeant son contenu de à . En recyclant les éléments (plutôt qu'en créant de nouveaux éléments DOM), nous améliorons les performances à un point tel que l'utilisateur ne se rend pas compte que le DOM est constamment redessiné. <li> Item 3 Item 4 Si vous vous demandez à quel point il est complexe d'implémenter ce mécanisme d'aplatissement et de différenciation qui applique les modifications au DOM, j'ai réussi à le faire en 500 lignes de javascript ES5, et il fonctionne même dans Internet Explorer 6. Mais, il faut l'admettre, c'était peut-être le morceau de code le plus difficile que j'aie jamais écrit. Être têtu a un prix. Conclusion Voilà les quatre idées que je voulais vous présenter ! Elles ne sont pas totalement originales mais j'espère qu'elles seront à la fois novatrices et intéressantes pour certains. Merci de votre lecture !
