Комментарии 4
Когда у вас на странице есть тяжелые компоненты (например, интерактивные графики или карты), их рендеринг на сервере может существенно замедлить ответ.
Такие вещи вообще не работают на сервере, о чем вообще речь?
И еще: есть более лаконичный вариант заставить работать компонент только на клиенте: *.client.vue
В целом, статья имеет место быть. Разве что, есть несколько нюансов
По пунктам:
3 пункт из производительности: да, ClientOnly можно использовать как компонент для избежания проблем гидратации, в том случае, когда компонент ведёт себя по-разному на клиенте и сервере. Вот только загвоздка в Вашем примере. Объясню: кейсов, когда компонент ведёт себя по-разному на клиенте и сервере, ничтожно мало и большинство из них просто ошибка разработчика. В Вашем примере используется isMobile, который по своей логике проверяет, с какого устройства заходит клиент. Это можно сделать и на сервере (например при помощи user-agent). Тут тоже есть нюанс, т.к. определение устройства с помощью user-agent не является точным. Вообще, в идеале вёрстка должна быто одинакова и разделяться на мобильную/десктопную/какуювамнадо через медиа запросы в css, но, такое, к сожалению, тоже не всегда возможно. В общем, пример довольно спорный и не соответствует, так скажем, «лучшим практикам», но, в целом, жизнеспособен
2 пункт из безопасности: опять же, из примера — проверка «на админа» должна корректно производиться и на сервере, так что бот этого и без ClientOnly не увидит, т.к. директива просто не даст этому блоку «создаться». Единственное, в чём может быть суть примера — если проверка «на админа» довольно затратна и её хочется «убрать» из серверной обработки. Но и в этом случае ClientOnly не понадобится, т.к. переменная, которая в себе содержит флаг, админ это или нет — изначально должна быть false и изменяться на true уже на клиенте
Все пункты из «реальных кейсов использования» так же не совсем корректны. Чаще всего такие компоненты обособлены (как и у Вас в примере). Если сделать обернуть рут в ClientOnly, то весь setup всё равно будет выполнен на сервере (да, за исключением клиент-хуков, понятно дело), что тоже может повлечь какие-либо накладные расходы на стороне сервера. Так что внутри компонента особо нет смысла оборачивать рут в ClientOnly (даже если компонент везде должен использоваться только на стороне клиента) — оборачивать в ClientOnly нужно сам компонент по месту его использования
В общем, суть проста: если статья для «новичков», то и примеры должны быть корректны и сопоставимы с реальностью. Ведь многие, читая примеры в казалось бы «хорошей статье», используют данные в ней примеры «напрямую» без раздумий, к сожалению
Ну это больше просто как пример, а то без кода как то грустно, а так вы в целом правы.
Ну вообще если говорить тогда уж серьезно, я бы использовал Nuxt Module для определения viewport, он как раз таки это делает через user agent а потом на стороне клиента уже от брейкпоинтов отталкивается. Скорее всего вы знаете про этот модуль так что гундеть не буду, да и сразу видно что вы опытный разработчик если что загуглите.
По поводу админки, да тоже согласен. В идеале вообще использовать middleware, а так же useState чтобы сохранить состояние isAdmin.
Спасибо за хороший развернутый комментарий. Возможно реально следовало сделать примеры не просто ради примеров, а реальные кейсы
Магия ClientOnly: повышаем производительность и безопасность в Nuxt-приложениях