И помечу //FIXME сделать по науке

> не верстка, а компоновка имени класса на основе пропсов Почему не вынести метод компОновки имени класса в отдельный файл composeClassName = ({ param1, param2 }) => return classnames(param1 && class1, param2 && class2)

Dmitry ping

Dmitry ping

Да да так и сделаю

И помечу //FIXME сделать по науке

Вот только не надо fixme )) Как раз просто вынести функцию и есть правильно А ты нагородить хочешь и на реакт завязаться..)

))

https://www.youtube.com/watch?v=ZGVwMkrL2n0 это не тот видос, о котором тут говорили в чате и обещали скинуть?

к слову, ничего нового не узнал.

на реакт митапе просили код бенчмарков

https://twitter.com/AGambit95/status/852455789075845120

Гриша выложили

возник вопросец. this.props.children я могу заюзить как <children lalala="lololo"/> ?

в случае если в чилдрене именно элемент *а не массив

https://twitter.com/AGambit95/status/852455789075845120

> redux-mobx-state-tree што

?

так это ж этот ваш автор мобикса и придумал

ему и штокайте

он придумал mobx-state-tree

а тут ещё всажен ридакс

нахрена? :D

тогда доклад смотри

ваще там сравнение

redux = super mobx = power redux+mobx = superpower

Можно просто заменять стор, есть страндартная функция - для мока. То есть полностью все от Redux, кроме стора и редюсеров

Но оно еще сырое, я говорил, но сейчас допиливается

redux = super mobx = power redux+mobx = superpower

а есть что-то, что приравнивается к white?

?

https://github.com/grammarly/focal - вот еще раз по пиарю, пилю сейчас) Там в бранче Examples есть примеры уже компонентов с Rx.js, если кому то интересно. А так же styled-components в котрый можно фигачить observable в качестве пропсов и он будет слушать изменения

а подскажет кто-нибудь примеры библиотек с реактом и тайпскриптом?

не "пример кода", а именно библиотеку/пакет бы посмотреть как сборку лучше сделать

@typescript_ru

тут еще спроси

а, спасибо

Подскажите где можно почитать по рабате с API

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

редакс?

flux/redux/mobx

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

flux/redux/mobx

Спасибо!

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

бери setState

Парни подскажите, нужно дождаться пока промис зарезолвиться а потом только выполнить рендер. Пример: componentWillMount() { import(this.props.src).then(cmp => { this.setState({ cmp }) }) } На стороне клиента как бы ок, но нужно заставить работать это внутри renderToString.

а зачем? подготовь данные на сервере и передай через пропсы

:+1:

Поправил выше пример. Не так все просто, мне нужно чтобы не было статического импорта компонента, а внутри HOC я вызвал динамический импорт. С помощью плагина для babel такая конструкция на стороне сервера транспайлиться в обычный require. Теперь осталось превратить async flow в синхронный внутри renderToString. Без предварительной подготовки данных или дерганья статического метода компонента.

еще раз

sup

как вы решаете проблему с context vs shouldComponentUpdate?

Это называется неочень хорошее проектирование. Вместо того, чтобы статически и синхронно шаблонизировать данные, которые уже пришли с сервера, ты растягиваешь это за счет дозагрузки дополнительнных данных и обращений к серверу

Это называется code splitting, есть большая часть приложения которая используется в 20 % случаев, смысла ее грузить asap нету. Можно было бы забить и оставить догрузку на клиенте, но нужно чтобы все работало с выключенным JS, из чего вывод что SSR тоже должен отрабатывать это import.

на мой взгляд подобные решение в будущем плохо на работоспособности сервиса под нагрузкой

Это называется неочень хорошее проектирование. Вместо того, чтобы статически и синхронно шаблонизировать данные, которые уже пришли с сервера, ты растягиваешь это за счет дозагрузки дополнительнных данных и обращений к серверу

а ты считаешь лишние обращения к серверу это плохо?

как вы решаете проблему с context vs shouldComponentUpdate?

https://youtu.be/niRATPKKF40?t=869 вот чувак рассказывает как это побороть можно, но сам я не пробовал, мы стараемся изменяемые данные с сторе редакса хранить

@mkusher @ochervak @ZeroBias @sergeysova вы как то решали такю проблему?

https://youtu.be/niRATPKKF40?t=869 вот чувак рассказывает как это побороть можно, но сам я не пробовал, мы стараемся изменяемые данные с сторе редакса хранить

спасидш

https://youtu.be/niRATPKKF40?t=869 вот чувак рассказывает как это побороть можно, но сам я не пробовал, мы стараемся изменяемые данные с сторе редакса хранить

не у всех есть ридакс

но это верно

а ты считаешь лишние обращения к серверу это плохо?

я не считаю это чем-то хорошим, т.к. не вижу смысла дозапрашивать заново какие-то данные.

но я понимаю, что это просто в плане реализации

вернее не так. поправил коммент

@mkusher @ochervak @ZeroBias @sergeysova вы как то решали такю проблему?

не, контекст юзаю для того, что умеет говорить про обновления

либо не обновляется)

спасидш

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

ERROR: S client not available

на мой взгляд подобные решение в будущем плохо на работоспособности сервиса под нагрузкой

все кэшируется, один лишний запрос не проблема. а вот 300 kb лишних в основном бандле это проблема

все кэшируется, один лишний запрос не проблема. а вот 300 kb лишних в основном бандле это проблема

вот мне тоже так кажется

не, контекст юзаю для того, что умеет говорить про обновления

если сверху хоть один компонент скажет shouldComponentUpdate() { return true } то тебе ниже по дереву не прижёт контекст

чем меньше первичная загрузка - тем лучше

чем меньше первичная загрузка - тем лучше

+ 1

Тем более нагрузку на бекенд можно маштабировать. Для клиента все должно быть моментально

ну это все начинается в одном месте, а потом таких запросов многожество, когда проект разрастается

а не ждать когда он загрузит все справочники при загрузке.

опять же время на соединения

время на соединения не видны пользователю. Бекенд отлично маштабируется.

Если не так - то вам надо менять бекенд ;)

ок

Учтите, пользователь может работать с тостера

тут дело как раз в проектировании, мы заведомо знаем что эта часть приложения нужна в маленьком проценте случаев, а остально должно грузиться моментально даже на очень медленном интернете

или вообще из под браузера который ту часть не поддерживает

там грубо говоря IE10+, а остально приложение IE8+

adazzle data grid как вам?

тут дело как раз в проектировании, мы заведомо знаем что эта часть приложения нужна в маленьком проценте случаев, а остально должно грузиться моментально даже на очень медленном интернете

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

да когда зайдет в этот раздел, что как-бы ожидаемо и получить в UI соответсвующий лоадер

если сверху хоть один компонент скажет shouldComponentUpdate() { return true } то тебе ниже по дереву не прижёт контекст

Оо

да когда зайдет в этот раздел, что как-бы ожидаемо и получить в UI соответсвующий лоадер

может тогда на клиенте дотащить эти данные?

засада в том что на клиенте может быть выключен JS, поэтому SSR тоже должен отрисовывать это раздел ровно также как и клиент

а это реальный сценарий? кто-то выключает JS?

да

И дальше просто смотрит на то, как красиво все выглядит, но ничем пользоваться не может?)

а это реальный сценарий? кто-то выключает JS?

для публичного сайта - более чем)

Часть работает, причем даже формы

что за мифические люди которые серфят без жс-а?

Оо

ты не знал? https://github.com/facebook/react/issues/2517

Есть подозрение, что пользователь не знает, какая часть должна работать, а какая нет и после пары тычков в неработающий интерфейс забьет на это дело