Árvores falsas: usando indentação para uma UI mais simples

Árvores falsas: interface simples usando indentação

• Quando se quer uma lista em forma de árvore na UI, implementar relações de pai e filho exige muito trabalho e estruturas de dados complexas.
• Em bancos de dados relacionais, é possível obter dados em estrutura de árvore usando CTEs recursivas (Common Table Expressions).

Os dados realmente precisam ser uma árvore?

• É preciso considerar se os itens realmente precisam ter relações de pai e filho, ou se apenas precisam parecer assim.
• Se a relação real não for necessária, a árvore pode ser armazenada de forma simples usando os campos id, sort, indent e name.
• Como essa abordagem representa exatamente o que aparece na tela, fica muito mais simples criar uma interface para renderizar e editar a lista.

Outro exemplo usando "namespacing"

• No HissScript, quando o nome de um item contém um ponto ("."), a primeira parte é removida e o item é indentado, implementando assim uma funcionalidade de namespacing.
• Para o editor e o player do jogo, o namespacing é importante, mas na prática continua sendo apenas um nome simples.
• Muitas vezes, as pessoas precisam apenas da aparência de uma árvore, e não de uma estrutura de árvore real.

Bônus: árvore-lista

• Imitando uma árvore real, caminhos e informações são armazenados em uma lista plana, e os caminhos são ordenados para percursos em profundidade ou em largura.
• Em geral, listas planas são mais fáceis de manipular e mais adequadas para computadores.

Analogia física

• Ao organizar um scrapbook pessoal, para uma pessoa fica claro como os grupos funcionam, mas no chão não existe nenhum mecanismo físico que imponha de fato essas relações.

Atenção: não existe solução universal

• É preciso aplicar a técnica de acordo com cada cenário específico, e quando uma estrutura de árvore real for necessária, deve-se usar uma árvore.
• Se for necessário conhecer a relação real entre os itens, não se deve recorrer a hacks como indentação ou contagem de símbolos dentro de strings.

Opinião do GN⁺:

• Este artigo apresenta uma forma de simplificar interfaces de usuário em desenvolvimento de software usando indentação visualmente simples no lugar de estruturas de árvore complexas.
• Para desenvolvedores, isso oferece uma estratégia eficaz para simplificar estruturas de dados, economizar tempo de desenvolvimento e facilitar a manutenção.
• O artigo destaca que uma estrutura de árvore nem sempre é necessária e que, às vezes, apenas uma estrutura visual familiar ao usuário já é suficiente, oferecendo uma nova perspectiva para melhorar a experiência do usuário.

[GN⁺]

Opiniões do Hacker News

• A primeira abordagem, a "lista de adjacência (adjacency list)", é considerada a "forma obviamente correta".

• A segunda abordagem é uma "forma muito mais simples", algo que a pessoa nunca tinha visto antes; ela tem falhas evidentes, mas em alguns casos é clara o suficiente.

• A terceira abordagem, "namespacing", é chamada de "materialized path".

• Outra forma de representar árvores é com "nested sets", um método bem conhecido da época em que bancos de dados relacionais eram tratados com mais seriedade.

• O Postgres oferece um tipo de dado chamado ltree e operadores de busca que permitem lidar com estruturas em árvore de forma natural. Por exemplo, é possível criar uma tabela com ltree, inserir dados e depois consultar a estrutura da árvore com buscas simples.

• Os valores dentro da estrutura muitas vezes representam a hierarquia dos dados, e não a árvore exibida. Você provavelmente vai querer percorrer os dados, mostrar relacionamentos ou reordená-los. Armazenar informação visual na estrutura de dados dentro do banco pode ser uma visão de curto prazo.

• Houve experiência em fundar uma empresa que lidava com dados em forma de árvore. É possível converter uma estrutura de árvore em uma lista indentada em tempo O(n). Isso era uma das perguntas de entrevista, e há várias formas de buscar e renderizar rapidamente partes da árvore em bancos SQL sem consultas recursivas.

• Uma forma de buscar dados em árvore em um banco de dados relacional com SQL é escrever uma CTE recursiva (Common Table Expression). CTEs são realmente divertidas e, depois que você se acostuma, não há nada a temer.

• Com a experiência, aprende-se que as pessoas muitas vezes não querem uma árvore de verdade, só a aparência de uma árvore. HN e Reddit diferem nisso. No HN, um comentário filho aparece como o próximo irmão do comentário pai, imitando a aparência de árvore ao adicionar um nível de indentação ao do pai. Já no Reddit, os comentários filhos ficam realmente aninhados dentro do comentário pai.

• A ideia central do artigo é usar a estrutura adequada para o problema. No entanto, o desenvolvimento do argumento tem falhas. Não é preciso usar CTE para buscar árvores no banco de dados; é possível obter uma lista plana e montar a árvore localmente. Além disso, em árvores suficientemente grandes, mover ramos ou alterar profundidades pode gerar custo linear.

• Ao descrever taxonomias ou outras hierarquias, foi aprendido um método simples e rápido usando o sistema de arquivos local. Usa-se os comandos mkdir e tree e depois cola-se o resultado em e-mail, Slack, pastebin etc.

• Se a intenção for apenas salvar/carregar, uma solução mais simples pode ser serializar os dados no formato desejado, como JSON, e armazená-los como string. O uso de notação por pontos é semelhante à forma como a extensão Dendron para VSCode lida com hierarquias de nomes.

• Alguns anos atrás, houve uma percepção parecida em relação ao OpenGL: não é necessário renderizar um mundo de objetos 3D hierárquicos, basta renderizar uma lista ordenada de triângulos. Isso torna muitas otimizações muito mais fáceis.