Nous écrivons front-end qui fonctionne. Ou comment devenir ingénieur d'un développeur. Partie 1

Un développeur est un concept fortement attaché à une technologie spécifique, et c'est lui qui détermine ce que vous allez développer. Un ingénieur est un concept beaucoup plus large, qui n'est initialement lié à aucun domaine. Tout d'abord, vous obtenez la soi-disant base d'ingénierie, sur la base de laquelle vous choisissez un créneau dans lequel vous travaillerez, par exemple, un ingénieur logiciel. Et ce n'est qu'après cela que l'ingénieur commence à se spécialiser dans l'une des technologies.

La base de l'ingénierie est plus sur la façon de penser, la capacité d'analyser et de systématiser, que sur la croûte de l'université. Quand vous pouvez raisonnablement justifier à la fois les décisions prises et les décisions qui ont été rejetées.

Ce n'est pas un secret que le frontend est l'une de ces poubelles, où si quelque chose fonctionne, alors il vaut mieux ne pas le toucher, et sinon, le réécrire complètement.

Mieux vaut voir une fois qu'entendre cent fois


Maintenant, il est devenu à la mode de créer une interface basée sur des cartes, alors examinons le cas où nous devons développer une carte qui peut être glissée et prise pour conserver certaines positions à la suite de ces traînées.

Introduction


  1. La carte doit pouvoir occuper l'un des trois postes. 1 - la carte est initialisée, 2 - l'utilisateur a tiré la carte vers le haut (l'ouvrit), 3 - l'utilisateur a glissé la carte vers le bas pour la retirer.


  2. La taille minimale de la carte est de 50vh, le maximum n'est pas limité (cela signifie la possibilité de faire défiler en position 2)

Après avoir reçu les exigences, le développeur essaie probablement déjà de décider du cadre à utiliser. Et l'ingénieur va essayer de décrire le processus plus en détail, et d'identifier les caractéristiques clés de cette description

Par exemple:



Un diagramme d'action de haut niveau ressemble à ceci, ce n'est pas très compliqué:



Considérez l'action DragUp:



Ici, vous pouvez immédiatement voir que l'action dragUp n'est impossible qu'à partir de la position lorsque la carte est défilée , à partir de toutes les autres positions, quelle que soit la taille de la carte, nous devons gérer l'action dragUp.

La difficulté n'est que le classement des cartes en taille. Nous devons classer la carte comme petite afin d'éviter qu'elle ne soit traînée au-dessus de 50vh, une carte de taille moyenne ne doit pas dépasser sa hauteur (sinon elle se bloque simplement en l'air), mais une carte de grande taille ne doit pas être traînée plus haut que Y = 0 (haut écran).

Un bon mathématicien est un mathématicien paresseux. Il est difficile de classer les cartes par taille et de déterminer la hauteur de traînée maximale, ici, il vaut la peine de réfléchir à la façon de présenter ces cartes plus facilement, de ne pas tout résoudre de front (c'est comme en mathématiques lorsque vous ramenez tout à un dénominateur commun).

À ce stade, nous pouvons imaginer que la carte est dessinée dans une fenêtre virtuelle qui peut se déplacer de haut en bas par rapport à la fenêtre réelle, la hauteur minimale de cette fenêtre virtuelle est de 50vh, la valeur maximale est de 100vh.



Maintenant, le paramètre général pour les cartes de toutes tailles dans toutes les positions (initées, ouvertes) est la réserve de marche.

Le diagramme de traitement de l'action dragUp peut être décrit comme suit:



Pour l'action dragDown, c'est encore plus simple (vous pouvez bien sûr recommencer avec les cercles Euler, mais c'est trop évident) - la seule condition bloquant dragDown est que la carte a été défilée et que l'action scrollDown sera exécutée, et pas glisser vers le bas.



Et le chef de file sans prétention aux conditions restrictives est le défilement. La seule chose à garder à l'esprit est que le défilement ne devient possible qu'en position ouverte, lorsque les fenêtres virtuelle et réelle se croisent complètement. (et nous implémentons cette condition via css, en spécifiant open overflow-y pour la position)



Et bien sûr, nous avons «manqué» quelque chose et cet événement dragEnd qui ferme notre interaction avec les cartes (et en fait avec la fenêtre virtuelle) et à la sortie détermine dans quelle position nous devrions être.



Total


À la suite de la première partie, où nous avons effectué une formation d'ingénieur, décrit les paramètres clés et le plan d'action, nous avons abordé en douceur la partie 2, où à partir de la position du développeur, nous mettrons en œuvre tout cela (des choses comme dragUp, actions dragDown, détermination de la réserve de marche, description des positions finales). En général, transformez les circuits en code.

All Articles