SolidOS / SolidOS/solid-ui

Why is Solid UI and the use of virtual DOM problematic?

Ouverte
#240 0 commentaires 2 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

question
Langage dominant
TypeScript
Étoiles
153
Forks
46
Merge moyen
1 j 8 h
PR mergées (30 j)
7

Description

I'm writing this issue to explore the use of virtual DOMs in Solid UI, and perhaps in the greater picture of rdflib, as I don't understand why they are problematic.

Virtual DOM was made popular by the React framework (AFAIK), and they have a short read on it, with a deep dive on reconciliation if you want to understand what React does behind the hood. If you don't prefer React, Vue also uses Virtual DOM.

As I understand it, the use of Virtual DOM is about abstracting away the manipulation of DOM, and allow developers to think more about UI states and how these should be represented rather than the nitty gritty details of managing the DOM to get to these states. I'm no expert in React, but have found it very pleasant to use, and makes me much more efficient.

I think what's more important than using Virtual DOM, per ce, is the ability to abstract DOM manipulation into something that easier for developers to maintain. Svelte is a framework that does not use Virtual DOM (and is clear about why), and Angular does not use Virtual DOM either, but both have features that abstracts away the need for manually manipulating DOM (Svelte template syntax, Angular template syntax).

Wrt Solid UI specifically, I think we should export components (meaning functionality that returns something that is intended to be rendered into the UI) in a manner that can be reused in any framework. I believe Web Components to be a helpful utility that allows this, as it would also allow for compositioning with "normal" HTML, which I think is a very useful way of exposing functionality for reuse. That would also allow us to use a framework behind the hood to help us handling DOM manipulation.

Now, using something that abstracts away DOM manipulation is of course more expensive than doing the DOM manipulation manually, but I think it's worth the cost, as it would make code more maintainable.

Pros and cons for introducing some framework that abstracts away DOM manipulation:

Pros:

  • More maintainable code
  • Easier to read and understand for new developers coming into the code base

Cons:

  • More expensive than manual DOM manipulation in terms of performance (but I don't think this is going to be an issue)
  • Bigger bytesize (which might be an issue, but still worth it I think)

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

L’issue ne mentionne aucun fichier du dépôt, test ni point d’entrée de l’implémentation. Commencez par examiner l’approche actuelle des composants de Solid UI ainsi que les ressources liées concernant React, Vue, Svelte et Angular ; pour considérer le travail comme terminé, il faudrait définir et valider précisément le périmètre de la prise en charge des frameworks ou des Web Components.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
angular, react, typescript
Domaine
frontend, web-dev
Type d'issue
Fonctionnalité
Difficulté
5/5
Temps estimé
Plus d'une semaine
Activité
À l'abandon
Clarté
À clarifier
Accessibilité débutants
20/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.