Decomposição do projeto para frontend

Vamos falar sobre o que você já sabe.

Este é o meu primeiro artigo sobre Habré e não sou escritor. Mas olhando para o Frontend 2018: os resultados do ano , as mãos chegaram ao sublime e começaram a escrever.

Qualquer tarefa difícil consiste em tarefas simples. A capacidade de decompor corretamente é uma obrigação .

Vou liderar a discussão sobre o exemplo da maioria dos projetos por experiência pessoal.

Tenho certeza de que você dirá: " Mas nós não temos e geralmente reagimos de forma rápida, lógica e legível, gerar estilos usando js não é um tipo de complemento, está na moda, mas os fornecedores de front-end não são necessários, porque o nosso fornecedor de back-end Feofan fez uma excelente forma em php "mas ainda.

Designação
G1 Os gênios que podem, são exceções, um caso magnífico especial.
M *. O pensamento

Isso não pode ser lido

Então, vamos começar!

M1 O código de duplicação está incorreto.

M2. Você deve sempre pensar 100 passos à frente.

Por exemplo, no início de um projeto, levamos em conta seu estado após cinco anos.

Obviamente, iniciando uma rede social, podemos dizer imediatamente que, além da versão web, haverá aplicativos móveis, aplicativos de desktop. Daqui ...

M3 A parte do servidor deve ser gravada apenas uma vez. (M1)

E como temos uma versão web, móvel, desktop, então ...

M4 O lado do servidor lida com dados.

O lado do servidor não deve decidir qual botão desenhar e que cor deve ser.

Um modelo de carta ou arquivo html que [can] é carregado quando uma página é carregada para indexação por um mecanismo de pesquisa também está trabalhando com dados. Infelizmente, você precisa manipular o html (devido a requisitos de indexação, por exemplo), mas esse é outro problema.

De fato, pode-se transferir o conjunto inicial de arquivos (html, js, css) e dados. I.e. e aqui a parte de trás não está envolvida no layout.

Aqui ocorreu o primeiro detalhamento do projeto: a parte do servidor foi interrompida. Não discutirei em que idioma está escrito, como a arquitetura é organizada (lembro-me gentilmente do MVC). Não é da minha conta ...

M5 Todos devem fazer suas próprias coisas.

Pilhas completas cobrem alguns dos projetos, e aqui você pode e argumentará com esse ponto, mas, referindo-se a (M2), minha posição aqui é formada: é mais barato ter dois profissionais em sua área do que reescrever o projeto em um ano. É claro que existem gênios (G1) que acompanham todos os lugares, mas existem essas unidades, o que significa que você não pode aceitá-las nos argumentos "Como deve ser".

Também vou cortar desta torta um ramo do Designer, Usabilidade e companhia.

Entenda corretamente, um fornecedor front-end normal pode implantar de maneira independente um marco, concentrando-se em um milhão de análogos e em sua imaginação, mas estamos falando de projetos sérios em (M2), portanto, não se iluda :) (G1)

Bem, temos dados (API, todos os métodos necessários etc.), temos layouts - e vamos começar.

Em vista das realidades modernas - eu introduziria outro ramo. Infelizmente, mas uma grande proporção de fornecedores front-end modernos não sabe trabalhar com layout ou não sabe js. Eu conduzi um grande número de entrevistas e é estranho observar. Portanto, as frentes podem ser divididas em "designers de layout" e "designers de layout não ??".

M6 O desenvolvimento deve estar em mais de um arquivo

Diga-me, obviamente? Sim, obviamente!

M7 A frente é dividida em 2 partes: a que trabalha com os dados e a que os exibe.

Podemos não ter essa ou aquela parte. Por exemplo: ser apenas exibição (página estática) ou ser apenas dados (script no console etc.).

Aqui sugiro abstrair e apresentar: você é uma pessoa de pizzaria. Você recebe chamadas, coloca o queijo lindamente e leva-o ao comprador. A lógica sugere que você não é particularmente eficaz (M1). Mas se mais duas pessoas trabalharem com você, seria muito mais legal! Um recebe chamadas (trabalha com dados), o segundo recebe de volta (apresentação), o terceiro distribui o queijo lindamente :) (estilização da apresentação)

Já ouço "CEP" de 2012, "obviamente", mas vamos novamente ...

M8 JS está trabalhando com dados.

Ele liga para o back-end, aceita a ordem e não importa para ele como o queijo é colocado lá. Talvez a pizza não exista, talvez ele apenas faça uma pesquisa sobre a pizza do ano?

M9 Representação HTML

Mostra pizza para o cliente e também aceita feedback (dinheiro, críticas) e as passa para o administrador (JS).

M10. CSS - estilo de apresentação

Recuar entre as duas fatias de queijo.

Observe que o administrador do telefone não diz como empilhar o queijo e a pizza não contém alguém falando ao telefone. Qualquer tentativa de manipular estilos usando js ou manipular js usando html é inicialmente um suplemento, inicialmente ruim. As aulas e a manipulação de eventos foram inventadas por um motivo.

Você pode fazer uma aula: calabresa, salame, mas não é da sua competência decidir como colocar queijo calabresa.

Você pode cancelar o vínculo: se você foi expulso, não pagou, informe ao administrador. Mas não empurre o administrador na pizza. Ele está sozinho e há muitas pizzas! Se você tiver tantas pizzas quanto operadores, então M1.

E assim, pelo qual js, css, html são responsáveis ​​- nós descobrimos isso.

Agora você pode fazer várias perguntas: como preparar pizza, como entregá-la de forma mais rápida e conveniente e como conversar com os clientes por telefone.

Eu quero definir de alguma forma a palavra agora na moda " Componente ". De fato, mesmo um botão regular já é um "Componente", mas vou redefinir isso com exemplos óbvios. Um botão é um botão e um componente:

1. Pós-visualização
2. Comentário
3. Visualização do arquivo
4. Votação no habr
5. O bloco "vagas"
6. Texto em HTML do post, resenhas, webinar
etc.

M11 Um componente deve ter a mesma aparência em todos os lugares.

Onde quer que você publique uma visualização de postagem, em qual página você a abre, ela deve ter a mesma aparência. A regra de três cores. Tudo deve ser reconhecível pelo usuário.

Modificações - alterações forçadas, se necessário. Feito usando css.

Ou é outro componente

(Por exemplo, a visualização da postagem na coluna da direita pode diferir da visualização da postagem na parte inferior da página).

M12. O componente consiste em [html], [js], [css].

Cada uma das partes é opcional.

M13 Independentemente do número de instâncias do mesmo componente, seus estilos devem ser registrados apenas uma vez

Por exemplo, a visualização da postagem à direita, a visualização da postagem abaixo, a visualização da postagem na notificação e os estilos são registrados apenas uma vez.

M14. Somente a base deve ser registrada no componente js

Por exemplo, manipuladores de eventos ao clicar nos botões, dados necessários para exibição. Tudo o resto deve ser renderizado.

M15 Um componente pode consistir em componentes

Por exemplo, uma lista de postagens.

M16. Estilos retirados em um arquivo separado

Esses arquivos são armazenados em cache; além disso, não haverá tentação de escrevê-los em linha, o que significa duplicar.

M17 Os estilos de componente devem ser vinculados por meio das classes pai e apenas

A página de qualquer site é como muitas caixas de tamanhos diferentes, que são como bonecas embutidas umas nas outras.

Uma caixa é um componente.

Você tem uma caixa com caixas e itens. Você nunca precisa pensar em como descrever o interior de uma caixa aninhada. Descreva apenas isso.

Aqui eles inventaram um monte de bicicletas, mas senhores, não haverá problemas com os nomes, assim que você determinar o conjunto de componentes para si mesmo. Se você abrir o VKontakte e contar o número de componentes lá, contará 30 peças. (Não conte no facebook, só existe dor).

Não consegue criar 30 nomes de classe? E com razão, não há nada para inventar:

M18. Outras pessoas lerão seu código.

Então o nome natural é o melhor nome

Por exemplo

1. lista de postagens
2. lista de comentários
3. lista de notícias
4. pós-visualização
5. pré-visualização de comentários
6. pré-visualização de notícias
7. pós-detalhe
8. comentário-detalhe
9. detalhe da notícia

Incrivelmente difícil, não é? E o principal é incompreensível e difícil de manter

E sobre o "ler outras pessoas" também cancelar a inscrição:

M19 Html, js, css devem ser armazenados separadamente!

Se você precisar combiná-los, encontre uma solução diferente do que gravá-los em um arquivo. Reagir é o mais nojento em termos de legibilidade que eu já vi!

A página em “Caixas” foi dividida, sobre como armazenar arquivos - discutida. O que mais?

M20. Quase não há casos especiais

E se isso acontecer, amanhã seus gerentes entrarão no trabalho e dirão que "é necessário modificar a implementação a pedido do cliente". Resolva tarefas da maneira mais ampla possível.

Por exemplo, em nosso trabalho, independentemente do projeto, separamos imediatamente algumas tarefas: calendários, formulários de entrada, pop-ups, menus de diversos recheios, visualização de arquivos e outros widgets que interagem com o usuário. Por assim dizer, "funções de caracteres"

M21 A escrita de estilo requer decomposição

O mundo não apenas nos deu o maravilhoso MENOS, SASS.

Seu projeto possui um conjunto fixo de fontes, cores, sombras, quase todos os projetos sérios têm esquemas de cores; portanto, ao escrever estilos, tudo isso é parametrizado. E aqui o seguinte é importante

M22 Se você quiser alterar a cor da fonte (etc.), faça edições apenas em um local

Concluindo, gostaria de mencionar um problema importante.

M23 A formulação correta do problema leva à solução correta.

Talvez não houvesse css-in-js, facebook e algo que não deveria ser chamado.

Tenham um bom dia a todos!