ReactJS

Journaux liées à cette note :

Journal du mercredi 11 décembre 2024 à 11:03 #web-components, #WebDev, #JaiDécouvert, #JaimeraisUnJour, #JaiLu

Je viens de croiser pour la première fois la propriété windom.customElements (from). Elle fait partie de l'ensemble des technologies qui composent ce que l'on appelle les Web Components.

Je connais depuis longtemps les Web Components, mais je n'ai jamais essayé de mettre en œuvre cette technologie. Je me suis contenté de lire et d'écouter des retours d'expérience et de suivre l'évolution des spécifications.

#JaiDécouvert que je peux facilement créer des Web Components en Svelte : https://svelte.dev/docs/svelte/custom-elements.

Custom elements can be a useful way to package components for consumption in a non-Svelte app, as they will work with vanilla HTML and JavaScript as well as most frameworks.

source

#JaiDécouvert le site Custom Elements Everywhere (https://custom-elements-everywhere.com/). Je lis que les Web Components sont maintenant parfaitement supportés par les frameworks majeurs : ReactJS, VueJS, Angular, Svelte, Solid… Ce qui est une très bonne nouvelle 🙂.
Je vais essayer de garder cette information à l'esprit, les Web Components me seront sans doute utile à l'avenir.

Avec Svelte, j'apprécie une sorte de "retour aux sources", c'est-à-dire, vers un web un peu plus "vannila", celui que j'ai connu au début des années 2000.
Je pense que Web Components vont encore renforcer cette sensation, comme par exemple le fait que si j'utilise la fonctionnalité développeur "inspection" du navigateur sur un Web Component, je vais voir, par exemple, la balise <button>....</button> du Web Component et non sa "soupe" HTML, comme c'est le cas avec un composant ReactJS ou Svelte (je sais qu'il existe des extensions navigateur pour éviter cela).

#JaimeraisUnJour prendre le temps d'étudier les performances des Web Components versus les composants de ReactJS, Svelte et Solid.

#JaiLu le thread du Subreddit ReactJS : Is it worth learning Web Components?. Voici quelques extraits :

Not worth it to be quite honest. I expect to get some hate for this.

I worked on a design system for three years that was written in Stencil (web component framework) that was used by multiple teams all using React, Angular, Vue. I regret everything, it should have all been react but the dumb decision to allow different teams to use different frameworks in order to do "micro frontend architecture" was the reason web components were picked shortly before I joined and took the lead.

Web components are also impossible to version and whichever one loads first is going to be the one that is globally used. This means production breaking changes without teams even knowing their breaking changes were going to fuck over another team.

source

Un peu plus loin du même auteur :

No, I view “micro frontend architecture” as a total disaster and it usually is implemented badly. When each application is a different framework too it’s quite honestly so difficult as to not even be worth entertaining.

source

Web components can be a great way to add functionality to legacy web apps. I don't know if I'd set out to use them in any other scenario though. I suppose you could, but I don't know many people writing vanilla HTML/JS apps these days.

source

J'ai effectué une recherche GitHub sur le topic "web-components" et j'ai trouvé des choses intéressantes :

Journal du jeudi 05 décembre 2024 à 23:10 #ux-design, #user-interface, #JaiDécouvert

Ce matin, lors d'une discussion avec un client, le sujet de la densité des User Interface a été abordé. Cela m'a rappelé une note que j'avais rédigée le 2024-07-27.

Suite à cela, je me suis lancé dans des recherches en lien avec les grilles de Perspective que j'aime beaucoup (https://perspective.finos.org/blocks/editable/index.html).

#JaiDécouvert Glide Data Grid (https://grid.glideapps.com/) :

A ReactJS data grid with no compromises, outrageous performance, rich rendering and full TypeScript support.

Apparement, cette librairie utiliser HTML Canvas pour son rendering.

Dans ce thread Hacker News, #JaiDécouvert l'article "The Design Philosophy of Great Tables" (https://posit-dev.github.io/great-tables/blog/design-philosophy/).

J'ai consulter la page Components > Data Table de Evidence. J'aime beaucoup.

#JaiDécouvert https://tabulator.info

Journal du mercredi 01 mai 2024 à 10:05 #cms, #headless-cms, #svelte, #JaiDécouvert, #headless

En faisant la recheche suivant sur le subreddit Svelte : "markdown" #JaiDécouvert ici le projet Sveltia :

Alternative to Netlify/Decap CMS. Modern, fast, lightweight, Git-based headless CMS. Free & open source. UX-driven development. Made with Svelte.

#JaiDécouvert aussi ici le projet Sanity :

Sanity Studio – Rapidly configure content workspaces powered by structured content

basé sur ReactJS, après une première lecture rapide, je ne n'arrive pas à comprendre si c'est un #headless-cms ou non 🙅‍♀️.

En lien : l'issue de mon backlog nommée Étudier, tester, mettre en oeuvre tina.io

Svelte n'a pas de runtime, il est compilé #svelte, #ReactJS, #VueJS, #comparaison

D'après ce que j'ai compris, les framework framework VueJS et ReactJS utilisent des runtime. Ce n'est pas le cas de Svelte qui est un framework qui nécessite une phase de compilation, il n'utilise pas de runtime.

C'est une différence majeure entre les frameworks VueJS et ReactJS versus Svelte.

Je dis cela avec des pincettes, mais il me semble que cela permet à Svelte d'implémenter des solutions "élégantes" non possibles avec runtime. À vérifier…

Aller plus loin sur ce sujet :

  • Extrait de Svelte 3: Rethinking reactivity :

    Svelte is a component framework — like React or Vue — but with an important difference. Traditional frameworks allow you to write declarative state-driven code, but there's a penalty: the browser must do extra work to convert those declarative structures into DOM operations, using techniques like virtual DOM diffing that eat into your frame budget and tax the garbage collector.

    Instead, Svelte runs at build time, converting your components into highly efficient imperative code that surgically updates the DOM. As a result, you're able to write ambitious applications with excellent performance characteristics.

  • Frameworks without the framework: why didn't we think of this sooner? You can't write serious applications in vanilla JavaScript without hitting a complexity wall. But a compiler can do it for you.

  • Virtual DOM is pure overhead