Front End Notes # 1

image



In this article, you will find some small frontend notes. Sometimes they will be short because the topic is fully revealed in a couple of sentences, and sometimes because the author does not have enough experience and knowledge to reveal them more fully. If you like it, I will write more and more fully, with links and research.



The idea to write an article arose while re-reading the correspondence with a friend-team lead-front-end (Lyokha, hello!), Who always generously shares his knowledge, ideas and problems with me.



Everything that is written is the personal opinion of a small group of people and hardly pretends to be true. Let's start.



Try not to use transition: all



Many people know this, but I recently came across another reason why you should be extremely careful when using the all value with the transition property.



Let's imagine we have a container with a transition property:



.content{
  color: red;
  transition: 1s;
}

      
      





On hover, the color changes:



.content:hover {
  color: blue;
}

      
      





If we wrap in this container, for example, svg, the fill property of which will be equal to currentColor , then on hover, the image light will change. But what if we specified such a property somewhere for all svg?



svg {
  transition: 1s;
  fill: currentColor;
}
      
      





On hover, the fill will change not 1 second, but about 2, because first the transition will be applied to change the color, and as I understand it, for every color change of the outer, a change to the inner will be triggered, but if anyone has a more accurate explanation , I will be glad to read it.



Solution: explicitly specify transition: fill for svg (if you specify color , then the situation will not change, hence the output above).



svg {
  transition: fill 1.5s;
  fill: currentColor;
}

      
      





Maintaining block proportions



I always thought that everyone, any experienced front-end developers, knows about the ancient hack that allows you to maintain the proportions of the block, it turned out that not all.



The padding property , if specified as a percentage, is based on exactly the width, which allows us to do this trick:



.image-container {
  height: 0;
  position: relative;
  /*       */
  padding-top: calc(100% * 9 / 16 );
}

      
      





Now we can put an image in this container, the height of which will be calculated by the width of the container.



.img {
  position: absolute;
  height: 100%;
  width: 100%;
  top: 0;
  left: 0;
  object-fit: cover;
}

      
      





aspect-ratio



Not so long ago, the aspect-ratio property was added, which allows you to make everything that you see from above in one line.



.image {
  aspect-ratio: 16 / 9;
}

      
      





The main, in my opinion, the differences and convenience of this property are that:



  1. We don't need a container
  2. If width OR height is specified, then the second value will be calculated based on the aspect-ratio value
  3. If width AND height is given, then the property is ignored


Aspect-ratio support is still far from the cherished 95%, so use with caution



Don't postpone pagination until later



It sounds, of course, strange, but as a person who made a front of several products from scratch, I will say that there is always a temptation to "score" on the pagination of lists, options in selectors, tables, etc. I decided for myself that I would never put it on the back burner, because as soon as users start generating data, the pages start to slow down, the search for the causes of the brakes, of course, is not too difficult, but when it comes to searching, the situation requires an immediate solution. and this is nerves, shit code and loss of credibility with the development department.



Controlling the appearance of components through css variables



Variables in css are already loved and respected by many, but interview experience has shown that few people use them, and even fewer people know about the true power of inheritance. Most of it remained in the part of the documentation where they talk about : root (and this is just a pseudo-class - an alias for the root of the tree, most often for html).



So, imagine that we have a button component with scoped styles (in the example I use Vue.js), which has the following styles:



.button {
  color: var(--text-color, #000);
  background-color: var(--bg-color, #444)
}

      
      





And then we can simply define the .dark class in the parent component:



.dark {
    --text-color: #fff;
    --bg-color: #333
}

      
      





And pass this class to the button component:



<my-button class="dark"/>

      
      





And now such a simple style control without overriding CSS styles in the parent is available using a powerful variable inheritance mechanism.



Funny and excruciating bugs



I want to summarize this article with a story about small but unpleasant front-line bugs that my colleagues and I caught.



Inserting images into wysiwyg editor



In text editors in the browser (we use quill) it is possible to insert an image from another site using ctrl + v. We didn't think about it, that everyone uses the implemented mechanism for inserting images, but users are such users. One site, especially sensitive to image borrowing, determined where the request came from, and if the domain was not his, gave an advertising banner of its own product, which is true, of course, but it came as a surprise to us. So if you are developing / using wysiwyg, watch what and where to insert =)



Vue SSR + Cloudflare = <3



The problem that the comrade mentioned earlier told me about.



Only when you go to a page that was generated and given by SSR and subsequent SPA navigation, all requests to the API were duplicated. For a long time they could not understand what was the matter. After careful research, it turned out that there is a standard field with the company's email in the footer, but cloudflare obfuscates the email (to protect against scrapers). When Vue on the server collects a tree in js, then gets another tree on the client (with mismatched mail), Vue rehydration broke and crashed, creating a new vue instance, but not killing the old incomplete one. As a result, under certain circumstances, 2 Vue instances were running on the page at the same time.



That's all. Comments, wishes, harsh criticism - I will be glad to read all this and draw conclusions.



All Articles