getSnapshotBeforeUpdate(prevProps, prevState) {

getSnapshotBeforeUpdate(prevProps, prevState) {

Но он может юзать this.props и this state

Не, там все верно

А зачем лишние присваивания? Сделай так: const { values } = props; if( !values ) return null; Дальше все как было, только без условной операции

да, я чот туплю

А зачем лишние присваивания? Сделай так: const { values } = props; if( !values ) return null; Дальше все как было, только без условной операции

Да мб ошибся сегодня проверю логику

тогда вообще все ок

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

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

Ну, если у меня стейтлесс компонента

Например

Ну, если у меня стейтлесс компонента

Ничего не говорит

А мне не нужно ее каждый раз обновлять

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

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

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

Изменения произошли в редаксе? Т.е. произошли они через экшн-криэйторы (...мидлвары...)? Почему там не разруливать логику от этих изменений?

Зачем в компоненты логику пихать?

А мне не нужно ее каждый раз обновлять

Селекторы

Изменения произошли в редаксе? Т.е. произошли они через экшн-криэйторы (...мидлвары...)? Почему там не разруливать логику от этих изменений?

Потому что не всегда адекватно логику делать в другом месте

Потому что не всегда адекватно логику делать в другом месте

Почему?

@Candidate7 у тебя же что-то типа селекта с автодополнением или опшены которого зависят от чего-то внешнего. Тут нужно три компонента или два. Один принимает значения стора и значение переменной от которой зависят опшены, если значение изменилось, то нужно вызвать экшон и загрузить новые опшены. Опшены также находятся в этом компоненте и доставляются в него из стора. После в рендере в селектор нужно передать только конечные данные

Зачем повышать связанность модулей \ ф-й \ компонентов?

А ты как я понял пытаешься сделать всё в одном компоненте и прислать данные и определить как их отображать

Это же нарушает односторонний датафлоу (в какой-то степени). А главное ухудшает дебаг, увеличивает вероятность ошибки

Ничего это не нарушает

Не придумывай

@Candidate7 у тебя же что-то типа селекта с автодополнением или опшены которого зависят от чего-то внешнего. Тут нужно три компонента или два. Один принимает значения стора и значение переменной от которой зависят опшены, если значение изменилось, то нужно вызвать экшон и загрузить новые опшены. Опшены также находятся в этом компоненте и доставляются в него из стора. После в рендере в селектор нужно передать только конечные данные

Это в том случае, если ты точно знаешь, сколько и какие именно опшны тебе нужны. А в моем случае я просто добавляю <Select name="someName" entity="SomeEntity" context={ someFieldsValues } /> и точно знаю, что все опшны для SomeEntity подгрузятся. И если я вдруг решу этот селект удалить, то я его просто удаляю из формы и не грею себе мозг воспоминаниями "а не грузил ли я где-нибудь значения для него?"

Изменения произошли в редаксе? Т.е. произошли они через экшн-криэйторы (...мидлвары...)? Почему там не разруливать логику от этих изменений?

Изменения произошли где угодно

Нахуй на редакс завязываться?

Нахуй на редакс завязываться?

Ну в примере пропсы от редакса

Это в том случае, если ты точно знаешь, сколько и какие именно опшны тебе нужны. А в моем случае я просто добавляю <Select name="someName" entity="SomeEntity" context={ someFieldsValues } /> и точно знаю, что все опшны для SomeEntity подгрузятся. И если я вдруг решу этот селект удалить, то я его просто удаляю из формы и не грею себе мозг воспоминаниями "а не грузил ли я где-нибудь значения для него?"

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

Нахуй на редакс завязываться?

Потому что эти зависимые поля могут динамически добавляться. Например, мне нужно грузить улицы в зависимости он населенного пункта. А у дома может быть несколько адресов (угловой дом, улицу переименовали и т.д.)

Ну в примере пропсы от редакса

А я тебе уже в который раз говорю что редакса у меня нет

У меня тоже архитектура хуевая?

Это в том случае, если ты точно знаешь, сколько и какие именно опшны тебе нужны. А в моем случае я просто добавляю <Select name="someName" entity="SomeEntity" context={ someFieldsValues } /> и точно знаю, что все опшны для SomeEntity подгрузятся. И если я вдруг решу этот селект удалить, то я его просто удаляю из формы и не грею себе мозг воспоминаниями "а не грузил ли я где-нибудь значения для него?"

https://github.com/Wroud/react-painlessform/blob/master/src/components/Field.tsx

И даже когда был держать все говно приложения я не собирался

Потому что куча случаев когда локальный стейт удобнее

Это в том случае, если ты точно знаешь, сколько и какие именно опшны тебе нужны. А в моем случае я просто добавляю <Select name="someName" entity="SomeEntity" context={ someFieldsValues } /> и точно знаю, что все опшны для SomeEntity подгрузятся. И если я вдруг решу этот селект удалить, то я его просто удаляю из формы и не грею себе мозг воспоминаниями "а не грузил ли я где-нибудь значения для него?"

Тебе нужен компонент провайдер и компонент самого селекта, мне так кажется

Тебе нужен компонент провайдер и компонент самого селекта, мне так кажется

У меня так и есть

@syabro Я говорю о том, что пропы приходят от какого-то стейта, не важно какого. Стейт меняется через какой-то хендлер. И вот зависимость от нового стейта должна в этом же хендлере (или мидлваре какой-то) и обрабатываться. Зачем делать изменения стейта, а потом их пускать куда-то вних к компоненту, что бы он решил что с этими изменениями сделать и опять дернул что-то для работы со стейтом, зачем увеличивать количество элементов в причинно-следственных связях?

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

Это вполне себе может быть обычный самодостаточный компонент на реакте, который при смене значения пропса может менять свой стейт.

Это вполне себе может быть обычный самодостаточный компонент на реакте, который при смене значения пропса может менять свой стейт.

Слишком абстрактно. Дайте конкретный пример

Слишком абстрактно. Дайте конкретный пример

react-router + страница пользователя

rr передает id из урла

через пропсы

при смене id надо дернуть апи

вот тебе простой пример

У меня так и есть

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

при смене id надо дернуть апи

Где. Меняется.Id? Кто его меняет? Единственный, реально уникальный кейс - это нажатие кнопки назад в браузере, которую мы как бы не контролируем. Но это прям исключение. Все остальное в приложении контролируется через обработчики, которые мы пишем руками

да кто угодно

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

смена урла может быть откуда угодно

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

ребята

чтоб вы делаете с этим : Uncaught Error: only one instance of babel-polyfill is allowed

?

смена урла может быть откуда угодно

ее можно отследить и этим должен заниматься отдельный модуль

смена урла может быть откуда угодно

Эт разве хорошо? Ну типа менять урл в рандомных местах?

Слишком абстрактно. Дайте конкретный пример

Например компонент который рендерит канвасом текст. Текст передаётся в пропсы компоненту. Чтобы его отрендерить, нужно заранее посчитать размеры канваса. В cDU при смене пропса с текстом пересчитываем размеры и применяем их к канве. Можно усложнить данный пример. Давайте обусловимся, что у нас моноширный шрифт и пересчитывать размеры нужно только в том случае, если кол-во символов в тексте изменится. Вот дабы не пересчитывать эти размеры каждый раз, будем в cDU реагировать только на изменение кол-ва символов в тексте.

ее можно отследить и этим должен заниматься отдельный модуль

начинается

нихуя не должен никакой отдельный модуль ничем заниматься

Эт разве хорошо? Ну типа менять урл в рандомных местах?

а в чем проблема?

начинается

да потому что сравнение старых и новых пропсов - костыль

да потому что сравнение старых и новых пропсов - костыль

хуйню несешь

это источник данных с которым можно работать

если ты с ним работать не умеешь — твои личные проблемы

ERROR: S client not available

так и будешь миддлом сидеть всю жизнь

да потому что сравнение старых и новых пропсов - костыль

разве не компоненту решать когда дёргать call, а когда нет?

да потому что сравнение старых и новых пропсов - костыль

Это не ответственность компонента. Есть сущность - стор, она содержит: стейт, подписку \ отписку и хендлеры для изменения стора. Сущность стор отвечает за логику и должна быть обособлена

блядь

НЕТ СТОРА

да потому что сравнение старых и новых пропсов - костыль

С Т Р И М Ы

ЛОКАЛЬНЫЙ

НЕТ СТОРА

я не про редакс. Я про абстрактную сущность стор

да, прикинь, компонент и есть стор

Может быть, да

стор: 1) стейт 2) подписка \ отписка 3) хендлеры

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

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

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

>_< Ты противоречишь сам себе. пропсы приходят от какого-то стора = уже не 1 обособленный компонент. У тебя абстракция не с той стороны

ты заебал

перечитай выше

пропсы приходят из RR

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

Добрый день. Подскажите, как в safari отключить скрол в модалке? В данный момент использую scroll-lock. Он отрабатывает хорошо везде кроме как safari.

Всем здрасьте!)

Добрый день. Подскажите, как в safari отключить скрол в модалке? В данный момент использую scroll-lock. Он отрабатывает хорошо везде кроме как safari.

.container::-webkit-scrollbar { display: none; } ??‍♂️

.container::-webkit-scrollbar { display: none; } ??‍♂️

это не про то

Добрый день. Подскажите, как в safari отключить скрол в модалке? В данный момент использую scroll-lock. Он отрабатывает хорошо везде кроме как safari.

попробуй костыли с ограничением высоты

Добрый день. Подскажите, как в safari отключить скрол в модалке? В данный момент использую scroll-lock. Он отрабатывает хорошо везде кроме как safari.

Так-то не про CSS группа

Так-то не про CSS группа

понимаю,оффтоп

тебе событие надо отменить или что?

это не про то

почему? если визуально нудо убрать, то поможет

почему? если визуально нудо убрать, то поможет

Когда открывается модалка, нужно убрать возможность скролить контент под модалкой. В сафари есть баг, при котором контент скролится.

не баг а фича!

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

и ниче живем