SwiftUI Série 06｜Divisão de componentes SwiftUI e capacidade de manutenção de código

Quando surge o tema “desmontagem de componentes”, a primeira reação é:

• Esta visualização é muito longa
• Divida-o em várias subvisualizações

Isto é certamente um começo, mas se o critério de divisão for apenas “muitas linhas de código”, é fácil acabar com outro tipo de confusão:

• Na verdade existem mais arquivos
• Mas a relação de status é mais difícil de entender
• Os nomes dos componentes estão se tornando cada vez mais abstratos
• Passe vários parâmetros entre pai e filho

Em outras palavras, a página não fica mais clara, apenas muda de um arquivo grande para vários arquivos quebrados.

Portanto, a divisão de componentes verdadeiramente eficaz é:

Torne os limites da estrutura, do estado e dos limites de reutilização mais claros ao mesmo tempo.

1. Primeiro diferencie: você está desmontando a estrutura ou reutilizando-a?

É comum que as duas coisas se misturem.

1. Divisão para legibilidade estrutural

O objetivo é tornar a hierarquia da página atual mais clara. Este tipo de divisão é completamente razoável, mesmo que seja usado apenas uma vez em uma página.

2. Divisão para reutilização entre páginas

O objetivo é extrair componentes reutilizáveis. Este tipo de divisão requer limites mais estáveis ​​e interfaces mais restritas.

Se estes dois tipos de finalidades não forem distinguidos, as consequências mais comuns são:

• Obviamente eu só queria deixar a página mais clara, mas acabei extraindo-a prematuramente como um “componente universal”
• Ou este padrão foi repetido muitas vezes, mas ainda é considerado uma subvisão parcial

Portanto, o primeiro passo na divisão de componentes é determinar que tipo de problema está sendo resolvido.

2. A razão pela qual muitas páginas ficam cada vez mais confusas é porque o View assume muitas funções.

Depois que uma página assume essas coisas ao mesmo tempo, é fácil expandir rapidamente:

• estrutura de layout
• Estado da IU local -Mapeamento de status de negócios
• Formatação de dados
• Montagem de ação interativa

Neste momento, você descobrirá que o código longo não é a causa raiz. O verdadeiro problema é:

• Qual lógica pertence ao View
• Que lógica deveria estar fora
• Quais estruturas locais merecem expressão independente

O valor real da divisão de componentes é forçar esse julgamento de limite a ser feito novamente.

3. O que mais vale a pena remover primeiro geralmente é “a peça com a semântica mais completa na página atual”

Uma situação comum é que assim que os componentes são desmontados, eles correm para encontrar a peça mais versátil. Mas no desenvolvimento real, uma abordagem mais estável é muitas vezes desmontar primeiro as peças que estão semanticamente completas na página atual.

Por exemplo:

• Área de cabeçalho de dados
• Cartão de resumo do artigo
• Definir linha do item
• Blocos vazios

Os benefícios dessas estruturas são:

• Eles são originalmente uma unidade independente na página
• A semântica estrutural ficará mais clara após ser removida
• Mesmo que você não reutilize por um tempo, você não perderá dinheiro

Isso é muito mais estável do que tentar bombear um “contêiner de células superuniversal” desde o início.

4. Depois que os componentes são removidos, a interface se torna um verdadeiro problema de design

Um dos maiores valores da divisão de componentes é que ela força você a pensar em interfaces.

Você descobrirá em breve:

• Este subcomponente deve usar o modelo original ou os dados de exibição formatados?
• Precisa saber pular após clicar, ou expor apenas uma ação
• Deve ter estado local ou ser controlado por uma camada pai

Se você não quiser entender essas questões claramente, o componente pode facilmente se tornar:

• Muitos parâmetros
• Semântica de negócios pouco clara
• A camada pai precisa saber tudo

Portanto, a divisão de componentes é um trabalho de design de interface.

5. Um mau cheiro muito comum: misturar “divisão parcial da estrutura” e “divisão da lógica de negócios”

Por exemplo, se um cartão de lista for removido, ele também será responsável por:

• Exibição de layout
• Formatação de dados
• enterre o ponto
• Julgamento comercial após clique

Embora esta componente seja independente, as suas responsabilidades ainda são mistas.

Uma abordagem mais estável é geralmente:

• Os componentes de exibição devem focar na exibição tanto quanto possível
• Mantenha as decisões de negócios em níveis mais altos, tanto quanto possível
• Os subcomponentes expõem eventos necessários sem engolir diretamente todo o processo de negócios

Caso contrário, quanto mais componentes forem desmontados, mais fragmentada será a lógica, mas a complexidade não diminuirá.

6. Quando você não deve se apressar em fumar “componentes gerais”?

Este é o ponto onde muitos projetos SwiftUI podem facilmente ser superprojetados.

Se um padrão aparecer atualmente apenas uma vez em uma página e:

• A estrutura empresarial ainda não está estável
• Os detalhes da IU ainda estão mudando rapidamente
• Ainda não tenho certeza sobre os limites

Neste momento, é mais apropriado dividi-lo em subvisualizações locais dentro da página, em vez de atualizá-lo imediatamente para um componente geral.

Porque a “reutilização prematura” muitas vezes traz uma consequência:

• A interface do componente torna-se muito ampla
• Para ser compatível com possíveis cenários futuros, muitas opções são incluídas primeiro

O resultado é que é mais difícil mantê-lo do que não desmontá-lo.

7. Um julgamento prático: Se esta subestrutura for removida sozinha, outros poderão dizer o que é?

Esta é uma forma muito comum de julgar.

Se uma determinada subestrutura for retirada, todos poderão dizer naturalmente:

• Este é um cabeçalho de perfil de usuário
• Esta é uma linha de configurações
• Este é um cartão de resumo do artigo

Então geralmente é adequado para desmontagem.

Se você retirá-lo, você só poderá dizer:

• Este é um “contêiner de combinação”
• Esta é uma “Visualização de bloco de conteúdo”
• Este é um “caixa de cartão multicena”

Isso provavelmente significa que sua semântica não é estável o suficiente e que o momento da divisão pode ainda não ter chegado.

8. Conclusão: O que realmente se busca com a divisão de componentes é ter limites mais claros.

Para resumir, eu diria:

O padrão verdadeiramente eficaz para dividir componentes SwiftUI é que, após a divisão, os limites da estrutura, dos estados e dos limites da interface ficam mais claros do que antes.

Só assim os componentes ficarão mais leves à medida que forem desmontados; caso contrário, facilmente se transformarão em mais arquivos e o sistema será mais difícil de ler.