Pull to refresh

Comments 8

Верно, но гидратация везде и рядом. А так, да: кто-то создает элементы DOM из кода, кто-то предпочитает приконнектится к сгенерированному контенту.

Тоже верно.

Я вот сейчас подумал. Если фронтэнд библиотеки минимальны, код приложения в JSX, всё это собрать в один сжатый HTML файл, и отдавать его на первый запрос. То получается разница с гидрацией (первый показ) будет минимальна - пасинг HTML в DOM против создание DOM через JS. Зато начало взаимодействия будет сразу которое у гидрации начнется неизвестно когда. Понятно что не всем проектам это подойдет.

Дело не в сео даже, особенно на медленных сетях загрузка страницы без верстки (это те, которые динамически формируются скриптом) сильно отличается от загрузки страницы с версткой. Мне это бросается в глаза. Даже небольшой промежуток времени пустого экрана (то есть без контента вообще) убивает моего внутреннего перфекциониста, потому что создается ощущение "тормозов". В таких случаях уж лучше спиннер нарисовать, но точно не показывать пустой экран.

В общем, я предпочитаю, чтобы сразу, без пауз, отображалась полезная информация пользователю. А скрытые по умолчанию элементы, например модальные окна, можно уже формировать скриптом: JSX или иным способом, не важно на самом деле.

Что касается тезиса лучше динамически создавать сразу элементы и получать ссылки, чем искать их, то тут тоже есть нюанс:

если вы создаете тысячи, десятки тысяч элементов на странице, то конечно стоит искать наиболее быстрые способы отображения. Однако, для меня это редкий кейс, потому что я стараюсь в DOM хранить только те узлы, которые нужно видеть на странице прямо сейчас. Если на странице полно модальных окон, то я предпочитаю удалять их узлы, после того, как окно закроется. И это безопасно, потому что состояние храню отдельно и могу спокойно восстановить его в компоненте/фрагменте DOM. То есть какие-то различия в перфомансе именно в этом месте будут, но они не значительны.

Делал рисерч пару лет назад, все крупные поисковики умели JS сайты анализаровать, сегодня значит еще лучше, так что да, СЕО не в счет.

Кстати, спинер можно туда же в единый файл HTML бандла, в самом начале разместить. А скрытые элементы и большие списки, можно лениво подгужать по мере надобности.

В любом случае, думаю что при правильной организации первого показа, его скорость можно сделать на равне с гидрацией.

В общем, поиграйтесь с разными типами сайтов: админки, блоги/новостные, лендинги. Увидите, куда можно вставить этот спиннер (прелоадер), а где лучше сразу отобразить контент побыстрее потоком. Увидите разницу.

Вижу в разметке использование атрибутов ref, scope-ref и custom-scope-attribute. Понимаю, что это для удобства разработки. Но это противоречит стандарту HTML, в котором описаны возможные способы безопасного расширения. Иными словами, у любых пользовательских атрибутов должен быть префикс data-*, если только это не пользовательские элементы.

Такое использование атрибутов создаёт проблему для авторов стандартов, которые со временем могут добавлять новые функции. Если в интернете будет какое-то количество использований атрибута, им придётся искать другое, возможно, менее удобное название. Так было с атрибутом popover, который изначально должен был называться popup.

Хорошее замечание! Чтобы быть ближе к стандартам можно просто вызвать функцию useDataAttributes().

import {
    createFromHTML,
    selectRefs,
    useDataAttributes,
} from "dom-scope";

const root = createFromHTML(/*html*/ `
    <span data-ref="a">1</span>
    <span data-ref="b">1</span>

    <div data-scope-ref="another_scope">
        <span data-ref="a">2</span>
        <span data-ref="b">2</span>
        <span data-ref="c">2</span>
    </div>

    <span data-ref="c">1</span>
`);

useDataAttributes();

const annotation = {
    a: HTMLSpanElement,
    b: HTMLSpanElement,
    c: HTMLSpanElement,
};

let refs = selectRefs(root, annotation);
const { a, b, c } = refs;

console.log(a.textContent, b.textContent, c.textContent);
// outputs: 1 1 1

document.body.appendChild(root);

Плюс, можно глобально определить свои кастомные атрибуты с помощью функции setDomScopeOptions(options).

Вообще, в первых релизах DomScope data-атрибуты были как раз по умолчанию. Однако, потом пришлось столкнуться с практикой, когда было безумное количество верстки. Почему-то в тот момент решили, что такие атрибуты смотрятся как-то громоздко, после чего отбросили префиксы.

Sign up to leave a comment.

Articles