Today I Learned

Using DocumentFragment does the trick because it isn't part of the active document tree structure.

This means it doesn't interact with the main document until mounted.

Hence, it doesn't impact the performance when changes occur to its contents.

// Setup
const outlet = document.getElementById('#myList');
const fragment = new DocumentFragment();
const results = fetchResults(); // returns Array<Result>

We then go through each result and prepare it properly:

results.map((result, index) => {
    const li = document.createElement('li');
    li.textContent = result;
    li.classList.add('result');
    // We append to the DocumentFragment
    fragment.appendChild(li);
 });

Finally, we append the end result to the list:

outlet.appendChild(fragment);

If we were to append each item to the list outlet within the map above, it would have triggered a repaint/reflow every time we performed the action.

If we have a component that contains an image or video, we may face the case in which the component takes a different size from the one that is expected in the loading phase. This is because, while the image is loading, the size of the image is unknown, therefore the component will not render the image initially. This topic will throw a lot of issues and it can affect the user experience in a negative way, because components may take unnatural shapes while in the loading process.

This problem can be overcome by temporarily rendering:

• an empty container with the estimated photo dimensions
• a low resolution preview of the photo
• a default blurred image that will show the user what to expect from the UI

In the case we want to temporarily render a empty div to the screen, we may need to mimic a responsive feel to the box, therefore "calc()" CSS function may come in handy:

.empty-div {
     background-color: transparent;
     background-size: 100% auto;
     width: calc(100vw - 100px);
     height: calc((100vw - 100px) * 0.46); /* decimal = height aspect ratio */
}

The default src attribute acts as fallback for a default image size for browsers that have no support for srcset:

<img src="/images/image.jpg">

The srcset attribute gives the browser a bunch of different sizes of the same image to choose from.

The name of the image doesn't matter, you could name them image-small, image-medium and so on, but the 375w part should match the real width of the image:

<img
    src="/images/image.jpg"
    srcset="/images/image-375.jpg 375w,
            /images/image-768.jpg 768w,
            /images/image-1440.jpg 1440w,
            /images/image-1920.jpg 1920w,
            /images/image-2560.jpg 2560w"
>

Adding the sizes attribute specifies what image size to choose at a specific breakpoint and above (min-width) or below (max-width) it:

<img
    src="/images/image.jpg"
    srcset="/images/image-375.jpg 375w,
            /images/image-768.jpg 768w,
            /images/image-1440.jpg 1440w,
            /images/image-1920.jpg 1920w,
            /images/image-2560.jpg 2560w"
    sizes="(min-width: 1920px) 1400px, (min-width: 1600px) 1000px, (min-width: 768px) 700px, 300px"
>

One thing to note here is that the browser will first calculate the device width and then look at the sizes attribute and choose the first matching condition.

If you set for example sizes="(max-width: 1920px) 1500px, (max-width: 768px) 600px, 300px", and the device width is 640px, the first matching condition will be max-width: 1920px, therefore it will choose the 1500px image width suggestion, rather than the 600 you most probably expected. The same can happen with the min-width if the order is not right.

Notice also that we are asking the browser to choose a 1000px wide image between 1600px and 1919px, but in the srcset sources, there's no image at 1000px. Here, the browser will choose the image with the exact size, if there is one, or the closest one if not, but higher in size than specified, in this case, 1000px. Therefore, the 1440px will be selected.

It can take a while to grasp how this works, but it's worth taking the time to understand it.

At some point you might end up with a challenge like this. You've got several items (we'll take an example of 3) laid out with flexbox.

<div class="container">
    <div class="item"></div>
    <div class="item"></div>
    <div class="item"></div>
</div>

The items have fixed width and they all fit on one row, but you want the third to jump on the second row.

Like this:

====item====item====
========item========

So how do you make them stack 2 on the first row, and the third on the second row, centered to the middle?

If you try flex-wrap: wrap, depending on the device resolution, it might do the trick or not. If all 3 fit on the same row, they won't wrap.

The solution is to force them by adding a collapsed row (height 0) which takes up the entire width of the container, making it occupy an entire row, thus pushing the 3rd item on the next row. Think of it like a <br> tag.

<div class="container">
  <div class="item"></div>
  <div class="item"></div>
  <div class="break"></div>
  <div class="item"></div>
</div>

.break {
  flex-basis: 100%;
  height: 0;
}

Neat trick, right?

And it can be adapted to other situations as well, not necessarily flexbox.

This is related to the MOOV atom that contains all the metadata and information about the frame locations other important information the browser needs to know about the video. For some reason, all other major browsers load it with no issues but Safari prefers to wait until the whole resource has downloaded in order to decide what to do with it.

For mp4 files, downloading FFMPEG and running the following command solved my issue:

./ffmpeg -y -i source.mp4 -movflags faststart dest.mp4

What it does is that it takes the MOOV atom from the end and adds it right at the start.