Árboles falsos: usar sangría para una UI más simple

Árboles falsos: una UI simple usando sangría

• Cuando se quiere una lista con forma de árbol en una UI, implementar relaciones padre-hijo requiere mucho trabajo y estructuras de datos complejas.
• En bases de datos relacionales, se pueden usar CTE recursivos (Common Table Expressions) para obtener datos con estructura de árbol.

¿Los datos realmente tienen que ser una estructura de árbol?

• Hay que considerar si los elementos realmente necesitan tener una relación padre-hijo, o si solo necesitan verse así.
• Si no se necesita una relación real, se puede almacenar el árbol de forma simple usando los campos id, sort, indent y name.
• Este enfoque representa exactamente lo que se ve en pantalla, por lo que resulta mucho más sencillo crear una interfaz para renderizar y editar la lista.

Otro ejemplo usando "namespacing"

• En HissScript, si el nombre de un elemento contiene un punto (.), se recorta la primera parte y se aplica sangría al elemento para implementar la funcionalidad de namespacing.
• Para el editor del juego y el jugador, el namespacing es importante, pero en realidad no es más que un nombre simple.
• A menudo, las personas necesitan solo la apariencia de una estructura de árbol, no la estructura real.

Bonus: tree-list

• Imitando un árbol real, se almacenan rutas e información en una lista plana, y se ordenan las rutas para recorrerla en profundidad o en anchura.
• Las listas planas suelen ser más fáciles de manejar y más adecuadas para las computadoras.

Analogía física

• Al organizar un álbum personal de recortes, para una persona queda claro cómo funcionan los grupos, pero en el piso no existe ningún mecanismo físico que imponga esas relaciones.

Precaución: no hay una solución para todos los casos

• Hay que aplicar la técnica según el escenario específico, y si realmente se necesita una estructura de árbol, entonces se debe usar un árbol.
• Si es necesario conocer las relaciones reales entre los elementos, no conviene usar hacks como la sangría o contar símbolos dentro de una cadena.

Opinión de GN⁺:

• Este artículo propone una forma de simplificar las interfaces de usuario en el desarrollo de software usando sangría visualmente simple en lugar de estructuras de árbol complejas.
• Para desarrolladores, ofrece una estrategia efectiva para simplificar las estructuras de datos, ahorrar tiempo de desarrollo y facilitar el mantenimiento.
• El artículo subraya que una estructura de árbol no siempre es necesaria y que, a veces, una estructura visual familiar para el usuario es suficiente, ofreciendo así una nueva perspectiva para mejorar la experiencia de usuario de los desarrolladores.

[GN⁺]

Comentarios en Hacker News

• El primer enfoque, la "lista de adyacencia (adjacency list)", se considera "obviamente la única forma".

• El segundo enfoque es "una forma mucho más simple", una manera que no habían visto antes, y aunque tiene defectos evidentes, en algunos casos es lo suficientemente clara.

• El tercer enfoque, "namespacing", se conoce como "materialized path".

• Otra forma de representar árboles es con "nested sets", un método bien conocido de la época en que se trabajaba seriamente con bases de datos relacionales.

• Postgres ofrece un tipo de dato llamado ltree y operadores de búsqueda que permiten manejar estructuras de árbol de forma natural. Por ejemplo, se puede crear una tabla usando ltree, insertar datos y luego consultar la estructura del árbol con búsquedas simples.

• Los valores dentro de una estructura suelen ser una jerarquía de datos, no un árbol para mostrar. Probablemente quieras recorrer los datos, mostrar relaciones o reordenarlos. Guardar información visual dentro de la estructura de datos en la base de datos puede ser una visión de corto plazo.

• Hubo experiencia fundando una empresa que trabajaba con datos en forma de árbol. Es posible convertir una estructura de árbol en una lista indentada en tiempo O(n). Era una de las preguntas de entrevista, y en una base de datos SQL existen varias formas de obtener y renderizar rápidamente partes de un árbol sin consultas recursivas.

• Una forma de obtener datos con estructura de árbol desde una base de datos relacional usando SQL es escribir un CTE recursivo (Common Table Expression). Los CTE de hecho son divertidos y, una vez que te acostumbras, no hay nada que temerles.

• Con la experiencia se aprende que muchas veces la gente no quiere realmente un árbol, sino solo la apariencia de uno. HN y Reddit son distintos en esto. En HN, un comentario hijo aparece como el siguiente hermano del comentario padre, imitando la apariencia de un árbol al sumar un nivel de indentación al del padre. En cambio, en Reddit los comentarios hijo sí están realmente anidados dentro del comentario padre.

• La idea central del artículo es usar la estructura adecuada para el problema. Sin embargo, el desarrollo del argumento tiene fallas. No se necesita un CTE para recuperar un árbol desde la base de datos, y se puede traer una lista plana para construir el árbol localmente. Además, con árboles lo bastante grandes, mover ramas o cambiar profundidades puede generar un costo lineal.

• Al describir taxonomías u otras jerarquías, se aprendió un método simple y rápido usando el sistema de archivos local. Se usan los comandos mkdir y tree, y luego se copia y pega el resultado en correo, Slack, pastebin, etc.

• Si solo quieres guardar/cargar, una solución más simple puede ser serializar los datos en el formato que quieras (por ejemplo, JSON) y guardarlos como una cadena. Usar notación con puntos es similar a cómo la extensión de VsCode Dendron maneja las jerarquías de nombres.

• Hace algunos años hubo una revelación parecida con OpenGL: no hace falta renderizar un mundo de objetos 3D jerárquicos, sino simplemente dibujar una lista ordenada de triángulos. Eso hace que muchas optimizaciones sean muy fáciles.