Comments 9
Вот кстати да, про тёмную тему. Да.
Есть ли она на хабре?
(конечно, "использую её везде, где она есть" - проголосовала)
Нет, к сожалению, ночного режима на хабре нет.
Но хаброжителей это не останавливает, и можно найти расширенные копии хабра. Одна из лучших реализаций описана в статьях Владислава Якушева:
первая часть и вторая.
"Мне 17 лет и я уже несколько месяцев делаю клон мобильного приложения Хабра, назвав его соответствующе, модно, со стилем и пафосной точкой в конце — habra. Получилось реализовать несколько фич, которых пока нет ни в официальном приложении из плей маркета, ни на самом сайте."
Одной из фич является как раз темизация. Возможно вам будет интересно.
P.S сам не пользуюсь, наверно слишком привык к интерфейсу оригинальной версии
На хабре нет, но есть DarkReader для большинства популярных браузеров.
Спасибо за инфу, отличная штука - поставила себе.
Однако с тёмными есть засада, причём, я так думаю, она каким-то образом разрешима. Возможно, никто просто не догадывался этим заняться.
Я про наличие на экране нескольких тёмных окон одновременно. Тёмные темы не перекрашивают край интерфейса. В браузере я понять могу ещё как-то - возможно, у джаваскрипта (на котором вот это всё делается, как я понимаю) нет доступа к свойству "цвет внешнего контура интерфейса" браузера.
У телеграма есть точно. Но там всё та же засада - контур отсутствует.
В итоге, когда на экране пять-шесть окон и все тёмные, вы перестаёте видеть, где телеграм, где хабр, где идеешка.
В светлом виде они хорошо отчерчены.
Я бы поняла, если бы контуры тёмных тем становились бы толстенькими и белыми. Такой внешний контур у интерфейса, белый прямоугольник пикселя в три шириной. Сразу было бы видно, где у ужа кончается голова и начинается хвост. Куда можно ткнуть в экран, чтобы попасть на ту же телегу, вместо того, чтобы разбираться в иконках (на винде всегда есть вариант кликнуть иконку для всплытия приложения). У меня иконок этих по низу экрана штук двадцать пять. Белые контуры тёмных интерфейсов были бы сильно удобнее.
я правильно понимаю что серверный рендеринг работает только 1 раз для первой загружер1 страницы, а далее всё через клие
Судя по вашему комментарию ("1 раз для первой загруженной страницы, а далее всё через клиента" - это может означать только SPA на клиенте) вы подразумеваете next / nuxt / sapper.
В таком случае ответ и да и нет.
Да – полноценный рендер в html происходит только для первой страницы, это верно. Вместе с html придёт весь клиентский код для этой страницы и на клиенте создастся виртуальный дом, в дальнейшем все изменения на этой странице будут происходить на клиенте. Исключением могут быть ленивые компоненты.
Нет – как написал выше - клиентский код приходит для текущей страницы. При переходе* на другую страницу с сервера будет получен объект, описывающий следующую страницу и также будет содержать полученные для этой страницы props-ы (например после обращения к БД или из файловой системы). Ленивые компоненты также загружаются по мере необходимости.
* Обычно (для этого есть дополнительная опция в api инструментов) это работает не при переходе на другую страницу, а при наведении на ссылку.
Автор сравнивал скорость spa и ssg. Так вот на примере сложнее чем туду лист, ssg существенно выигрывает в скорости. Хотя бы потому что прилетает готовый html.
Отчасти вы правы, поэтому перед метриками стоит дисклеймер: Метрики приведённые ниже никак не отражают действительности в отношении производительности конкретных вариантов. Примеры приведены только для того, чтобы показать относительную скорость и пользовательский опыт от взаимодействия с сайтом в контексте темизации.
А в контексте приведенных примеров дела обстоят примерно так. (Буду использовать условные единицы для обозначения трудозатрат)
При совпадении темы в SPA:
Загрузка приложения (10у.е.) -> определение темы на клиенте (1у.е.) -> рендер приложения (8у.е.) = 19у.е.
При несовпадении темы в SPA:
Загрузка приложения (10у.е.) -> определение темы на клиенте (1у.е.) -> рендер приложения (8у.е.) = 19у.е.
При совпадении темы в SSG:
Загрузка приложения (14у.е.) [мы грузим дополнительно весь html] -> определение темы на клиенте (1у.е.) -> сравнение реального и виртуального dom (2у.е.) [все совпадает, ничего дальше не происходит] = 17у.е.
При несовпадении темы в SPA:
Загрузка приложения (14у.е.) [мы грузим дополнительно весь html] -> определение темы на клиенте (1у.е.) -> сравнение реального и виртуального dom (2у.е.) -> ререндер клиентской части приложения (4у.е.) = 21у.е.
Повторюсь, это работает так только для конкретного примера - все зависит от проекта. И даже сложные проекты могут повторять ситуацию описанную выше (когда после определения клиентских данных приложение должно быть перерендерено).
А вообще, в идеале, тема должна быть полностью абстрагирована от кода, но все-таки обычно это не так.
Темизация. Часть 2. Новые браузерные API. Темизация при SSR. Выбор между SPA, SSR и SSG