Why is Solid UI and the use of virtual DOM problematic?
Nadie ha tomado este issue todavía.
- Lenguaje dominante
- TypeScript
- Estrellas
- 153
- Forks
- 46
- Merge medio
- 1 d 8 h
- PR fusionados (30 d)
- 7
Descripción
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)
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Línea de trabajo
El issue no menciona archivos del repositorio, tests ni puntos de entrada de la implementación. Empieza revisando el enfoque actual de componentes de Solid UI y el material enlazado sobre React, Vue, Svelte y Angular; para darlo por terminado sería necesario concretar y acordar el alcance de la compatibilidad con frameworks o Web Components.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- angular, react, typescript
- Área
- frontend, web-dev
- Tipo de issue
- Nueva funcionalidad
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Estado de actividad
- Estancado
- Claridad
- Necesita aclaración
- Aptitud para principiantes
- 20/100