Comments 8
Если бы вы сами создавали каждый элемент, то вам не потребовалось бы потом искать на них ссылки в DOM (что не быстро).

https://codesandbox.io/p/sandbox/4m7r37?file=%2Fsrc%2Fapp.jsx
Верно, но гидратация везде и рядом. А так, да: кто-то создает элементы 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-атрибуты были как раз по умолчанию. Однако, потом пришлось столкнуться с практикой, когда было безумное количество верстки. Почему-то в тот момент решили, что такие атрибуты смотрятся как-то громоздко, после чего отбросили префиксы.
DOM-Scope: создание искусственных областей видимости и управление идентификаторами элементов