Get best of the week

Escrevemos front-end que funciona. Ou como se tornar um engenheiro de um desenvolvedor. Parte 1

Um desenvolvedor é um conceito fortemente vinculado a uma tecnologia específica e é isso que determina o que você desenvolverá. Um engenheiro é um conceito muito mais amplo, não vinculado inicialmente a nenhum campo. Primeiro, você obtém a chamada base de engenharia, com base na qual escolhe um nicho no qual trabalhará, por exemplo, um engenheiro de software. E somente depois disso o engenheiro começa a se especializar em qualquer uma das tecnologias.

A base da engenharia é mais sobre o modo de pensar, a capacidade de analisar e sistematizar, do que sobre a crosta da universidade. Quando você puder fundamentar razoavelmente as decisões tomadas e as decisões que foram descartadas.

Não é segredo que o front-end é um desses lixões, onde, se algo funcionar, é melhor não tocá-lo e, se não, reescrevê-lo completamente.

Melhor ver uma vez do que ouvir cem vezes


Agora ficou na moda criar uma interface baseada em cartões. Vamos dar uma olhada no caso em que somos obrigados a desenvolver um cartão que pode ser arrastado e levado para manter determinadas posições como resultado desses arrastamentos.

Introdutório


  1. O cartão deve ser capaz de ocupar uma das três posições. 1 - o cartão foi inicializado, 2 - o usuário puxou o cartão para cima (abriu), 3 - o usuário passou o cartão para baixo para removê-lo.


  2. O tamanho mínimo do cartão é 50vh, o máximo não é limitado (significa a possibilidade de rolar na posição 2)

Após receber os requisitos, o desenvolvedor provavelmente já está tentando decidir qual estrutura usar. E o engenheiro tentará descrever o processo com mais detalhes e identificar os principais recursos dessa descrição.Por

exemplo:



Um diagrama de ação de nível superior se parece com isso, não é muito complicado:



considere a ação DragUp:



aqui você pode ver imediatamente que a ação dragUp é impossível apenas a partir da posição quando a placa é rolada , de todas as outras posições, independentemente do tamanho do cartão, devemos lidar com a ação dragUp.

A dificuldade é apenas a classificação dos cartões em tamanho. Precisamos classificar o cartão como pequeno para impedir que ele seja arrastado acima de 50vh, um cartão de tamanho médio não deve subir acima de sua altura (caso contrário, fica suspenso no “ar”), mas um cartão de tamanho grande não deve ser arrastado acima de Y = 0 (parte superior tela).

Um bom matemático é um matemático preguiçoso. É difícil classificar as cartas por tamanho e determinar a altura máxima de arrasto; vale a pena pensar em como apresentá-las de maneira mais conveniente, para não resolver tudo de frente (é como na matemática quando você leva tudo para um denominador comum).

Nesse estágio, podemos imaginar que o cartão é desenhado em uma viewport virtual que pode se mover para cima e para baixo em relação à viewport real, a altura mínima dessa viewport virtual é de 50vh, a máxima é de 100vh.



Agora, o parâmetro geral para cartões de todos os tamanhos em qualquer posição (iniciada, aberta) é a reserva de energia.

O diagrama de processamento da ação dragUp pode ser descrito da seguinte maneira:



Para a ação dragDown, ainda é mais simples (é claro, você pode começar novamente com círculos de Euler, mas é muito óbvio) - a única condição de bloquear o dragDown é que o cartão foi rolado e a ação scrollDown será executada, e não dragdown.



E o líder em despretensiosidade a condições restritivas é o rolo. A única coisa a ter em mente é que a rolagem se torna possível apenas na posição aberta, quando as janelas de exibição virtual e real se cruzam completamente. (e implementamos essa condição via css, especificando o estouro aberto-y para a posição)



E, é claro, “perdemos” algo e esse evento dragEnd que fecha nossa interação com cartões (e de fato com viewport virtual) e na saída determina em que posição devemos estar.



Total


Como resultado da primeira parte, onde realizamos o treinamento de engenharia, descrevemos os principais parâmetros e o plano de ação, abordamos a parte 2, onde a partir da posição do desenvolvedor implementaremos tudo isso (coisas como dragUp, ações dragDown, determinação da reserva de energia, descrição das posições finais). Em geral, transforme os circuitos em código.

More articles:


All Articles