И что юзать стейж 0 в проде это несмешной пиздец

смешной

Ну да, когда тебе на каждое изменение пропосала половину кода приходится выкидывать это охереть как смешно

спс за ответы, добавил "plugins": ["transform-object-rest-spread"] и все заработало

какие шутки) наблюдение

ага, observer

смешной

))

JokeObserver

а, видимо env включает только spread для списков, а не для объектов, правильно понимаю? https://babeljs.io/docs/en/babel-plugin-transform-es2015-spread

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

а почему ты думаешь что изменения пропсов или сет-стейт не вызовет тот-же самый ререндер всего дерева и собственно почему тебя это вообще волнует. Ключевой пойнт архитектуры реакта в том что проблема не в первоначальном рендере, проблема в мутациях состояния. И если мы сможем писать код, как если бы с нуля рендерили приложение какждый раз, то смогли бы избежать многих проблем в разработке UI. Поэтому идеалогия реакт что все дерево всегда перерендеривается. Но тк производительность при этом была бы ужасная к этой идее прикрутили виртуальный дом и алгоритм "reconciliation" Если инетересно https://github.com/acdlite/react-fiber-architecture

Ну это в теории, на практике идеология реакта что все дерево всегда перерендеривается не рабочая - даже с виртуальным домом и его "reconciliation" алгоритмом реальное приложение будет тормозить если на каждое изменение вызывать "reconciliation" всего приложения. Поэтому реакт сам же отступает от своей идеологии и вводит shouldComponentUpdate и взваливает на голову разработчиков проблему обнаружения и реагирования на какие изменения данных какие компоненты должны обновиться. И из-за этого как раз и появилась куча стейт-менеджеров с различными подходами к управлению данных потому что представить изменения данных и реагировать на них тоже можно по разному с разной эффективностью

Ну это в теории, на практике идеология реакта что все дерево всегда перерендеривается не рабочая - даже с виртуальным домом и его "reconciliation" алгоритмом реальное приложение будет тормозить если на каждое изменение вызывать "reconciliation" всего приложения. Поэтому реакт сам же отступает от своей идеологии и вводит shouldComponentUpdate и взваливает на голову разработчиков проблему обнаружения и реагирования на какие изменения данных какие компоненты должны обновиться. И из-за этого как раз и появилась куча стейт-менеджеров с различными подходами к управлению данных потому что представить изменения данных и реагировать на них тоже можно по разному с разной эффективностью

Pure component, не, не слышали? Идея react-waterfall прошла мимо?

Ребят, как правильно готовить react-router, если надо отобразить что-то вроде <Tabs value={this.state.viewIndex} onChange={...}> <Tab label="..." component={Link} to="/url1/"> <Tab label="..." component={Link} to="/url2/"/> <Tab label="..." component={Link} to="/url3/"/> Получается без локальной переменной this.state.viewIndex, говорящей какая щас "вьюха" активна, все равно не обойтись

Либо писать фабричные методы которые в каждый <Route> подставляют таббар с нужным индексом активного таба

Либо писать фабричные методы которые в каждый <Route> подставляют таббар с нужным индексом активного таба

Редакс есть?

Есть, но там ничего что бы относилось к ui

Есть, но там ничего что бы относилось к ui

Тогда 2 варианта, - пиши в редакс и на его базе лови - раздели текущий компонент на 2, передавай активный пропом и Tab фигачь циклом (хотя, это в любом случае надо б так сделать)

И, сам таб замени на явный Link из роутера

Тогда 2 варианта, - пиши в редакс и на его базе лови - раздели текущий компонент на 2, передавай активный пропом и Tab фигачь циклом (хотя, это в любом случае надо б так сделать)

Ок, придётся нарезать ещё немножко компонент

Спс

Спс

Ну, не знаю что у тебя там под капотом, но попробуй может сначала Tab -> Link сделать

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

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

От стейта, стейта чего - уже дело твое

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

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

Роутер даёт тебе хэш, он не даёт стейта в "привычном" виде, поэтому хэш ты превращаешь в стейт (если redux-router, то уже, считай оно есть)

Ну это в теории, на практике идеология реакта что все дерево всегда перерендеривается не рабочая - даже с виртуальным домом и его "reconciliation" алгоритмом реальное приложение будет тормозить если на каждое изменение вызывать "reconciliation" всего приложения. Поэтому реакт сам же отступает от своей идеологии и вводит shouldComponentUpdate и взваливает на голову разработчиков проблему обнаружения и реагирования на какие изменения данных какие компоненты должны обновиться. И из-за этого как раз и появилась куча стейт-менеджеров с различными подходами к управлению данных потому что представить изменения данных и реагировать на них тоже можно по разному с разной эффективностью

Видимо ваш субъективный опыт сильно отличается от моего

Кто нибудь дружил final-from и react-dates? Валидация работает а вот meta.touched не меняется :c

Видимо ваш субъективный опыт сильно отличается от моего

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

Я не пытаюсь сказать что sCU не нужен, но единственный проект из тех что я участвовал и он был по делу это react-devtools в обычных веб/мобилках я не сталкивался с нуждой что с ним делать, но опять же повторюсь - считаю свой опыт субъективным и вероятно у других участников сообщества другие задачи

Кто нибудь дружил final-from и react-dates? Валидация работает а вот meta.touched не меняется :c

вручную выставляй это значение touched при смене значения

Если там так можно, офк

Я формик-бой

Если там так можно, офк

да вроде разобрался, просто react-dates пропсы не прикидывает вниз, я просто обернул его в еще один див и навесил на него уже onBlur

Господа, судя по последним обсуждениям, чаще никто sCU особо не юзает, а значит правильно ли я думаю, что легче PureComponent везде писать и радоваться жизни?

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

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

У вас в PureComponent не должно быть лямбда выражений ещё, иначе в нём нет смысла и у вас всё равно будет этот компонент перерендериваться

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

Pure нужен лишь затем, что все его потомки не вызовут перерендера, но и не смогут его вызвать.

Тут флоу постигаю, товарищи с флоу юзать propTypes норм? flow выпиливается в рантайме, или хорошо отслеживает косяк без рантайма?

Тут флоу постигаю, товарищи с флоу юзать propTypes норм? flow выпиливается в рантайме, или хорошо отслеживает косяк без рантайма?

Флош на компиляции, проп тайпс в ран тиме

Засветит неправильную пропсу в IDE - и в рантайм ходить не надо

Тут флоу постигаю, товарищи с флоу юзать propTypes норм? flow выпиливается в рантайме, или хорошо отслеживает косяк без рантайма?

Я флоу покрываю те части, которые не относятся к реакту напрямую, компоненты проптайпс

Засветит неправильную пропсу в IDE - и в рантайм ходить не надо

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

Я флоу покрываю те части, которые не относятся к реакту напрямую, компоненты проптайпс

да хорошая мне кажется комбинация)

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

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

Я делал и так и сяк, флоу хорош, но пиздить тапками проще с проптайпами

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

Разные штуки хендлит проптайпс и флош

А еслм флоу в рантайме запускать? Он заменит проптайпс?

Я во флоу не врубился, это типа надо всегда типы писать дополнительно ко всему или чё?

Тайпскрипт на костылях?

Тайпскрипт на костылях?

Флош норм

Тайпскрипт на костылях?

Это не костыли, это альтернатива. Флоу не обязывает тебя юзать .ts повсеместно, им ты можешь типизировать те куски кода, которые требуют этого

Также Климов говорит, что флоу умнее ts

Хотя бы из-за двусторонней проверки

Также Климов говорит, что флоу умнее ts

Звучит дико

Также Климов говорит, что флоу умнее ts

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

Если ты начал использовать Typescript, то придется его использовать везде, если ты используешь flow, то он не обязывает тебя юзать его везде, это "точечная" типизация, как бы

Плюс один - definitely typed намного больше flow typed

Плюс один - definitely typed намного больше flow typed

Никто не мешает покрывать flow абсолютно все, история в другом, в компиляции этого добра

Халлоу товарисчи. Ткните носом кто-нибудь в реализацию oauth2 через фейсбук

Если ты начал использовать Typescript, то придется его использовать везде, если ты используешь flow, то он не обязывает тебя юзать его везде, это "точечная" типизация, как бы

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

ERROR: S client not available

Охуенный пример

То то в тс то конечно всю рамду затипизировали, с расширенными оверлоадами и тайп классами

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

Я не успел, читай выше

Преведение типов?

То то в тс то конечно всю рамду затипизировали, с расширенными оверлоадами и тайп классами

ок, у меня норм объедениния типов не пашут, вечно какая то жопа да вылезет

Всё, что вам нужно знать про подход тайпскрипта

ок, у меня норм объедениния типов не пашут, вечно какая то жопа да вылезет

Есть вероятность что она там была всегда

Есть вероятность что она там была всегда

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

ну эт мой опыт

Я очень рад за твою неосведомлённость

при какой тут неоведомленность?

Ну если ты ничего не слышал, то кто в этом виноват

Ну если ты ничего не слышал, то кто в этом виноват

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

Киньте ему мут уже

Киньте ему мут уже

по какому такому нарушению?

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

мда уж.... о чем можно говорить тут

мда уж.... о чем можно говорить тут

коструктив так и прет, спасибо, очень полезно)

коструктив так и прет, спасибо, очень полезно)

ну если тебе сложно просто найти в гугле сравнительный анализ ts vs flow

За карго-культ, который ты разводишь, топя за технологию, которую не знаешь, и топя против технологии, которую не знаешь

ну если тебе сложно просто найти в гугле сравнительный анализ ts vs flow

я сказал о своем опыте, але

я сказал о своем опыте, але

у тебя нет никакого опыта судя по всему

За карго-культ, который ты разводишь, топя за технологию, которую не знаешь, и топя против технологии, которую не знаешь

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

@snatvb если ты это видишь впервые, то судить о чем-либо ты не имеешь права

Ой

у тебя нет никакого опыта судя по всему

смешненько, спасибо

Не на того меншн

@snatvb если ты это видишь впервые, то судить о чем-либо ты не имеешь права

что не так с описанием?