тем что он не отражает реальной ситуации

например?

ну вот плохая идея это :( http://webaim.org/blog/user-agent-string-history/

Норм идея. 90% случаев возьмет, а остальные 10 - реакт разрулит сам

например?

например мобильный браузер может посылать useragent который выглядит как десктопный

или появится новый браузер, который ты не учёл

часто такое бывает у мобил?

Ну значит неудачник:)

ага

Зачем нам неудачники?

ну мы отметаем случаи, когда кто-то специально меняет юзерагент.

они не наша ЦА )

ну мы отметаем случаи, когда кто-то специально меняет юзерагент.

да это понятно

может есть библиотечки, которые определяют по ЮА и хорошо поддерживаются/обновляются ?

express-device ?

да, но не только для сервера

А для клиента зачем? Там уже window.width

чтоб изоморфично

подключил где-нибудь в странице или рутах и забыл

Нет, так не выйдет:)

И не нужно

ну допустим мне нужно менять набор компонентов на уровне страницы под рутером в зависимости от ЮА.

то есть при переходе по другому руту, рендерить будет только клиент

а при обновлении страницы — сервер

писать разные условия для разных случаев?

но вся грустная история в общем-то тут описана http://webaim.org/blog/user-agent-string-history/ такие решения несут вред и авторам сайтов, и создателям браузеров feature detection самое адекватное решение ssr конечно да... Вроде кстати я что-то читал про то, что браузеры собираются информацию о размерах экрана посылать на сервер, кто-то знает про это?

мы определяем на сервере с помощью https://www.npmjs.com/package/mobile-detect рендерим, отдаем клиенту, если ошиблись, реакт просто перерендерит

писать разные условия для разных случаев?

В стопе лежит is_desktop. На сервере он детектится по юа, на клиенте - по ширине экрана

В сторе

Да, отлично! Спасибо всем. Можем считать вопрос закрыт

На сервере по ЮА, на клиенте перепроверяем по фичам

@superlaziness Ну и стоит ещё раз задуматься о том, насколько реально необходимо делать разные компоненты. Немаловероятно что получится найти ухищрение, которое позволит один компонент использовать )

На сервере по ЮА, на клиенте перепроверяем по фичам

кстати да Очень хороший вариант

Я понимаю прекрасно. Но вот именно такая задача )

кто-то тестил отключение анимаций, например, используя это API?

кто-то тестил отключение анимаций, например, используя это API?

зачем? ( если не сикрет )

зачем тестить, или зачем нужно такое делать?

если второе - чисто теоретически, если отсутствуют анимации, браузеру надо меньше делать, батарейка не так сильно садится

возможно еще что-то можно в приложении отключать. Метрики слать не раз в 5 секунд, а раз в минуту. Ну я не знаю, у всех своя бизнес логика)

из интересных применений, я видел только в whatsapp web, и то, там с телефона берется заряд батареи)

ок, не хотите эту тему обсудить - другой наброс)

кто тут с typescript живет, как вы вообще живете? звои тайпинги пишете?

не работают же ваще

кто тут с typescript живет, как вы вообще живете? звои тайпинги пишете?

https://telegram.me/typescript_ru

не работают же ваще

все работает :)

не работают же ваще

все работает.

все работает

ERROR: S client not available

/все_работает

#всеработает

@vsyo-rabotaet

это

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

@javascript_jobs

solved

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

Нет, не забанят

?

Братишки

И сестренки

Я знаю что многие тут катают 2.1.x бетку вебпака в продакшене

А как вы решали вопрос с peerDependencies, разным пакетам нужен разный вебпак

И это все в конечном счете не зашринкврапить

А как вы решали вопрос с peerDependencies, разным пакетам нужен разный вебпак

на удивление, кроме warning-ов при npm install проблем не возникало

ну пиры показываются как ворнинга при npm i, это да

но я не смертник, и предпочитаю лочить версии пакетов нативным shrinkwrap’ом

и вот для него эти ворнинги становится блокерами для создания файлика с версиями

а шринкврап умеет лочить devDependencies?

да, с флажком —dev

мы просто dev не лочим и с такой проблемой не столкнулись)

ну у нас просто архитектурно это опасно, деплой может стать роковым