Get best of the week

We write front-end which works. Or how to become an engineer from a developer. Part 1

A developer is a concept strongly attached to a specific technology, and it is it that determines what you will develop. An engineer is a much broader concept, not initially tied to any field. First, you get the so-called engineering basis, on the basis of which you choose a niche in which you will work, for example, a software engineer. And only after that the engineer begins to specialize in any of the technologies.

The engineering basis is more about the way of thinking, the ability to analyze and systematize, than about the crust from the university. When you can reasonably substantiate both the decisions made and the decisions that have been discarded.

It’s no secret that the front-end is one of those garbage dumps, where if something works, it’s better not to touch it, and if not, to rewrite it completely.

Better to see once than hear a hundred times


Now it has become fashionable to make an interface based on cards, so let’s take a look at the case where we are required to develop a card that can be dragged and taken to hold certain positions as a result of these drags.

Introductory


  1. The card must be able to occupy one of three positions. 1 - the card was initialized, 2 - the user pulled the card up (opened it), 3 - the user swiped the card down to remove it.


  2. The minimum card size is 50vh, the maximum is not limited (it means the possibility of scrolling in position 2)

After receiving the requirements, the developer is most likely already trying to decide which framework to use. And the engineer will try to describe the process in more detail, and identify key features from this description

For example:



A top-level action diagram looks something like this, it’s not very complicated:



Consider the DragUp action:



Here you can immediately see that the dragUp action is impossible only from the position when the card is scrolled , from all other positions, regardless of the size of the card, we must handle the dragUp action.

The difficulty is only the classification of cards in size. We must classify the card as small in order to prevent it from being dragged higher than 50vh, a medium-sized card should not rise above its height (otherwise it just hangs in the “air”), but a large-sized card should not be dragged higher than Y = 0 (top screen).

A good mathematician is a lazy mathematician. It’s difficult to classify cards by size and determine the maximum drag height, here it’s worthwhile to think about how to present these cards more conveniently, not to solve everything head on (it’s like in mathematics when you bring everything to a common denominator).

At this stage, we can imagine that the card is drawn in a virtual viewport that can move up and down relative to the real viewport, the minimum height of this virtual viewport is 50vh, the maximum is 100vh.



Now the general parameter for cards of all sizes in any positions (inited, opened) is the power reserve.

The processing diagram of the dragUp action can be described as follows:



For the dragDown action, it is still simpler (you can, of course, start again with Euler circles, but it's all too obvious) - the only condition blocking dragDown is that the card has been scrolled and the scrollDown action will be executed, and not dragdown.



And the leader in unpretentiousness to restrictive conditions is scroll. The only thing to keep in mind is that scrolling becomes possible only in the open position, when the virtual and real viewports completely intersect. (and we implement this condition via css, specifying open overflow-y for the position)



And of course, we “missed” something and this dragEnd event that closes our interaction with cards (and in fact with virtual viewport) and at the output determines what position we should be in.



Total


As a result of the first part, where we carried out engineering training, described the key parameters and the action plan, we smoothly approached part 2, where from the position of the developer we will implement all this (things like dragUp, dragDown actions, determining the power reserve, description of the end positions). In general, turn circuits into code.

More articles:


All Articles