АБ
мне кажется это вообще где то выше изначально надо было разделить чтобы не было одной функции с тремя аргументами от обновления которых зависит то как функция должна вызываться
Size: a a a
2020 July 09
O
у меня так в одной энтерпрайзе было, там все uiComponent exetens SomeHugeComponent были, причем, 3 года назад в "базовом" было 12 строк, к 2019 стало больше 800. Как решить? Правильно, убираем экстендс и декаплим на зависимости нормально, вуаля.
O
мне кажется это вообще где то выше изначально надо было разделить чтобы не было одной функции с тремя аргументами от обновления которых зависит то как функция должна вызываться
пока мы не узнаем юзкейс - ниче нормального не посоветуем. Тут на 100% архитектурная фигня, надо "сделать по-другому"
АБ
лять не был бы ты аутсорсером, я б только ради твоих стендапов пошел к тебе работать:D
O
лять не был бы ты аутсорсером, я б только ради твоих стендапов пошел к тебе работать:D
у меня продуктовая компания, ви чего
АБ
O
АХАХАх:D
серьезно :) я заебался и работаю над продуктом сейчас, под него по-тиху и команда набирается
АБ
знаем плавали, заливали мне про то что мы на самом деле ПРОДУКТ, продукт помогающий нашим клиентам решать их проблемы)))
O
знаем плавали, заливали мне про то что мы на самом деле ПРОДУКТ, продукт помогающий нашим клиентам решать их проблемы)))
ноуп, в уй клиентов
O
я лучше потеряю 50% базы, чем буду снова заниматься херней тип "ВОТ ТУТ МОЖНО ТИКЕТ ОТМЕТИТЬ КАК ЗАВЕРШЕН, А МНЕ НАДО ЗАВЕРШЕН И ЗАВЕРШЕН ДЛЯ МЕНЯ"
и все такие: ой, да, ну нужно ему 2 статуса, давай, ты чо, пусть будет
нннннааааааааа
и все такие: ой, да, ну нужно ему 2 статуса, давай, ты чо, пусть будет
нннннааааааааа
O
знаем плавали, заливали мне про то что мы на самом деле ПРОДУКТ, продукт помогающий нашим клиентам решать их проблемы)))
я те больше скажу - я около 2 лет не планирую брать заказы :)
YN
мне кажется это вообще где то выше изначально надо было разделить чтобы не было одной функции с тремя аргументами от обновления которых зависит то как функция должна вызываться
Да, скорее всего так и нужно было сделать. В общем юзкейс в том, что первый аргумент - строка с инпута, а все остальное "фильтры" (заполняются через Context API), которые уходят в запрос через единую функцию
O
Да, скорее всего так и нужно было сделать. В общем юзкейс в том, что первый аргумент - строка с инпута, а все остальное "фильтры" (заполняются через Context API), которые уходят в запрос через единую функцию
какие фильтры?
DS
Такая ситуация: есть функция example(val1,va2,val3), которая вызывается в useEffect, а аргументы функции добавлены в зависимости. Проблема в том, что скажем, если меняется val1, функция должна выполняться с задержкой, но изменения в остальных зависимостях должны вызывать функцию сразу же. Вроде как можно это разделить на два useEffect'a, но тогда я получу warning'и о пропущенных зависимостях. Можно каким-то образом определить какая именно зависимость поменялась, но это вроде как дольше. Может кто уже сталкивался, подскажите каким путем пойти?
А как это с задержкой? И главное зачем?
И
Да, скорее всего так и нужно было сделать. В общем юзкейс в том, что первый аргумент - строка с инпута, а все остальное "фильтры" (заполняются через Context API), которые уходят в запрос через единую функцию
Context API? Ух и огребёшь же ты сейчас
YN
А как это с задержкой? И главное зачем?
Задержка с запросом, дать юзеру дописать строку, а не отсылать запрос после каждого изменения
АБ
Да, скорее всего так и нужно было сделать. В общем юзкейс в том, что первый аргумент - строка с инпута, а все остальное "фильтры" (заполняются через Context API), которые уходят в запрос через единую функцию
лучше б ты не палил что у тебя Context ))
YN
Context API? Ух и огребёшь же ты сейчас
Проект маленький для стейт менеджеров
И
Да, скорее всего так и нужно было сделать. В общем юзкейс в том, что первый аргумент - строка с инпута, а все остальное "фильтры" (заполняются через Context API), которые уходят в запрос через единую функцию
С нормальным стейт-менеджером у тебя не было бы этой проблемы