Pull to refresh

Comments 16

«по одной лишь информации о user-agent невозможно определить мобильность, если пользователь использует, например, десктопный браузер, но сжал окно до «мобильного»размера»

Тут всё очень просто, на десктопе просто ограничиваем минимальную ширину в 960 пикселей и всё. Дальше горизонтальный скролл. Потому что на десктопе мобильная версия не нужна. Например я, когда читаю Википедию, постоянно сужаю максимально ширину браузера, чтобы текст не расползался по всей ширине экрана, отодвигаю горизонтальный скролл и спокойно продолжаю читать десктопную версию.

Заморочи с отображением мобильной версии на десктопе бессмысленны, вы хотя бы раз видели человека, не имеющего отношения к разработке, который специально сужает окно браузера, чтобы смотреть на мобильную версию? Я за многие-многие годы ни разу такого не видел.
Если есть возможность и нету таких требований, то действительно так будет проще.

У нас же есть требования поддержки «узкиx» разрешений на десктопах и наша аналитика говорит о том, что коло 8% пользователей с к экранами меньше 800px на десктопных ос. По этому нам приходится поддерживать.

Но ключевой момент именно в наличии или отсутствии возможности отказаться от разделения ui по ширине экрана, потому что при разделении только по user-agent, это во первых проще, а во вторых можно лучше оптимизировать код.
«8% пользователей с к экранами меньше 800px на десктопных ос»

Жесть какая, а они в каких браузерах сидят? Стандартные последние Chrome и хромоподобные?

Именно с экранами или с размером окна?

К сожалению у меня есть только статистика по экрану, по окну конечно корректнее судить
Наборот интересная статистика получается. Если по окну, то может быть любители не в фулскрине на большом мониторе.
не дергается 100500 раз при ресайзе, а только когда границу, заданную в query пересекает
Используете SSR? Что использовали для раутинга и как решали проблему Sode Splitting + SSR + Lazy Loading? Довелось в доке react-router видеть такую фразу:
Godspeed those who attempt the server-rendered, code-split apps.
Частично используем, но подружить код-сплиттинг с SSR пока не пробовали, но это и правда очень не простая задача, учитывая то, что ReactDOMServer не поддерживает пока Lazy и Suspense
и пишем CSS на styled-components


основной проблемой больших веб-приложений. Многие уже догадались: да, речь идет о длительности парсинга.


Может попробовать выкинуть styled-components? Они ж вроде как раз в рантайме считаются.
А вместо них перейти на css-модули, которые высчитываюся в «компайл-тайме».
По идее приложению станет «легче дышать».
cssInJS конечно добавляет Вес бандлу, но не думаю что значительный, для нас по крайней мере это не повод отказываться, уж слишком удобный он для наших задач. Было бы кстати интересно посчитать, сколько весят например стили в нашем приложении, может прикину на досугу
cssInJS конечно добавляет Вес бандлу

так даже не в весе дело, а в парсинге. В ж сами писали о проблеме длительности парсинга.

Классический css обычно скачался и всё; как только у браузера есть dom и cssom — он это дело «мержит» и готов что-то показать.

При cssInJS, качается js-бандл,… пааааарсится… и вот тут доп. нагрузка… кроме js самого приложения, нужно ещё высчитать стили в рантайме(!)… для абсолютно каждого компонента, и только потом получить cssom.

Это можно сравнить с показом картинки:
классический css === скачать картинку и показать в теге img
cssInJs === скачать картинку, js-ом вставить в канвас и отрисовать.
А что там удобного? Возможность использовать JS-переменные при формировании темы?
Sign up to leave a comment.