в смысле одно дело написать компонент под широкий спектр задач и совсем другое - под конкретную задачу в твоей жире

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

Может у родителя в коннекте каждый раз что-то меняется в стейте?

ну у родителя меняется, так как он же содержит в себе все дочерние

больше он ничего не содержит

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

у нас же всегда родитель меняется

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

Создаете заново массив массиов? Immutability? если так то вполне логично что все перерисовывается

да, создаю заново. а как не создавать в редаксе?

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

самое простое - в map key не index, а какой-то уникальный ключ объекта

спасибо, ща проверю

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

react-select, но он говно)

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

https://github.com/JedWatson/react-select/issues/612

юзабилити 0

https://github.com/JedWatson/react-select/issues/612

а зачем вообще это нужно?

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

а зачем вообще это нужно?

потому что некоторые не знают, что есть ctrl/cmd+v

Интересно, с точки зрения производительности первый вариант сильно медленней второго? 1. const finalURL = `${SITE_URL}?${queryString}` 2. const finalURL = SITE_URL + '?' + queryString

http://esprima.org/demo/parse.html?code=%2F%2F%20Life%2C%20Universe%2C%20and%20Everything%0A%60%24%7Ba%7Dasdsad%24%7Bb%7D%60

я не об этом, а про сам сценарий. зачем копировать текст в селекте?

я как-то раз сломал кнопу send у чатика. Пользователь написал - аааа, как мне отправлять сообщения) Про enter он не знает)

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

Впс где хостился?

я не об этом, а про сам сценарий. зачем копировать текст в селекте?

не, в селект

а

ну вообще поддержка clipboard’а на уровне js работает в ограниченных браузерах

Но я понял тебя.

она работает в инпуте, а компонент ломает инпут. В этом смысл issue

https://github.com/JedWatson/react-select/issues/612

Ни фига себе

решить проблему, кстати, можно перейдя на флексбоксы и выкинув react-input-autosize или как там

Впс где хостился?

hetzner)

hetzner)

У популярных провайдеров сканируют постоянно их диапазоны на разные сервисы

а есть же еще штуки вроде shodan

чтобы сделать Promise.all

зачем тебе rx если ты промисы не можешь в нем сделать ?

самое простое - в map key не index, а какой-то уникальный ключ объекта

не прокатило

юзабилити 0

Но вообще одного юзкейса маловато, чтобы сказать, что юзабилити - 0. Есть там что-то еще?

Но вообще одного юзкейса маловато, чтобы сказать, что юзабилити - 0. Есть там что-то еще?

ну, может я погорячился) Меня напрягает, что почти год нету ответа автора, например)

ну, может я погорячился) Меня напрягает, что почти год нету ответа автора, например)

Согласен про год

Hi2all Пара нубских вопросов про React. Буду благодарен если ответите: 1. Использую React+Redux. Стоит ли добавлять в стор все состояния? К примеру, есть компонент состоящий из навбара и кнопки его скрывающей/показывающей. Стоит ли состояние навбара(скрыт-нет) хранить в сторе? Или норм просто в стейте компонента? 2. Стоит ли все экшены прогонять через редьюсер? К примеру, есть список элементов, хранится в сторе. Хочу по нажатию кнопки его сортировать. Стоит ли прогонять сортировку в редьюсере или норм его отсортировать прям в компоненте?

Имхо в сторе стоит хранить все, что связано с данными + те ui состояния, которые могут пригодиться для рендеринга нескольких компонент

Hi2all Пара нубских вопросов про React. Буду благодарен если ответите: 1. Использую React+Redux. Стоит ли добавлять в стор все состояния? К примеру, есть компонент состоящий из навбара и кнопки его скрывающей/показывающей. Стоит ли состояние навбара(скрыт-нет) хранить в сторе? Или норм просто в стейте компонента? 2. Стоит ли все экшены прогонять через редьюсер? К примеру, есть список элементов, хранится в сторе. Хочу по нажатию кнопки его сортировать. Стоит ли прогонять сортировку в редьюсере или норм его отсортировать прям в компоненте?

1. Зависит от ситуации. Обычно это стоит выносить если это часть бизнес логики - если тебе важно знать состояние навбара и уметь им управлять вне самого навбара 2. Стоит. Если нужно элементы отсортировать, отсортируй в Store и потом уже отображай. Опять же при условии что это важно с точки зрения бизнес логики

По-моему, ответ "да" на оба вопроса. И не играет роль, насколько оно существенно для бизнес логики.

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

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

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

+1

Мне в соседнем треде пару видео подсказали. Посмотрю, может яснее станет =)

можно удобно взять react-redux-form и использовать его modeled reducers

правда получится не совсем традиционный редакс

Есть еще прикладной вопрос - как сделать спиннер который показывать при *всех* запросах к api? (использую axious если важно)

можно удобно взять react-redux-form и использовать его modeled reducers

спс, посмотрю что за зверь

а я все в сторах держу)

Есть еще прикладной вопрос - как сделать спиннер который показывать при *всех* запросах к api? (использую axious если важно)

если все запросы идут через экшны (как и должно быть), то удобнее всего сделать один стор, который бы слушал все FETCH_*

пока решил задачу мутным способом. у меня просто после рендера компонента вызывается рендер графика сторонней библиотекой (в componentDidUpdate). В итоге вкомпоненте сделал кэш значений, и если не поменялось, то не перерисовываю график. не очень красиво, зато работает

Всем привет! Переежал сюда из скайп группы, говорят тут поживее )

если все запросы идут через экшны (как и должно быть), то удобнее всего сделать один стор, который бы слушал все FETCH_*

Да, через экшены. Т.е. перед каждым запросом генерить FETCH_* экшен показывая спиннер и после SUCCESS или FAIL убирать его?

пока решил задачу мутным способом. у меня просто после рендера компонента вызывается рендер графика сторонней библиотекой (в componentDidUpdate). В итоге вкомпоненте сделал кэш значений, и если не поменялось, то не перерисовываю график. не очень красиво, зато работает

а что не так-то) в shouldComponentUpdate только сравнение запихни и будет вполне канонично

Но это как то много писать, или я какой-то момент с экшнами пропустил?

У тебя экшены как уходят?

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

@nektodev Как вариант, можно сделать врапер для axios в котором перед выполнением запроса и на then/fail будет диспатчится экшин, котоырй слушается стором fetch, это если не через мидваре ходят запросы к апи

У тебя экшены как уходят?

в компоненте: api.getSmth() в api: export function getSmth() { axios.get('host/api/smth') .then(response => { var smthAction = getSmthSuccessAction(response.data); store.dispatch(smthAction); return smthAction; }); }

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

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

Ну я не знаю, можешь попробовать собирать в стейт статусы всех запросов, тупо true / false, потом убирать кружавчик, если true нет больше.

Middleware это прослойка между экшенами и редюсерами, емнип.

ERROR: S client not available

Если конкретно к редаксу применять.

Поправьте, если что.

ну, первое, что приходит в голову - добавлять в экшн еще один атрибут - spinner=true/false и обрабатывать редьюсером спиннера

это если совсем быстро

А зачем заранее пихать?

Если есть класы экшенов STARTED, SUCCESS и FALSE, то можно тупо юзать их как флаги.

started - spinner = true,

success / fail - spinner = false

ну, первое, что приходит в голову - добавлять в экшн еще один атрибут - spinner=true/false и обрабатывать редьюсером спиннера

Не, не сработает. Экшен же после вызова апи вызовется

Мы например на проекте перед запросом к апи отсылаем %Request_kind%_started

_перед_

Показываем так локально спинеры на каждый ресурс.

Не трудно будет сделать редюсер который будет просто матчить экшены по маске.

И тогглить.

Ага, понял идею. Но тут тогда все вызовы надо обернуть чтобы перед ними вызвался экшен STARTED

Достаточно в getSmth перед вызовом axios сделать dispatch

Или подключить что-то вроде thunk-а.

Печально =( У меня под сотню обращений к api =(

https://gist.github.com/Deiru2k/a734b89bbc621cf1308d37437369d0e2 У нас вот так выглядят экшены.

Бойлерплейт, правда, бгг.

Но мы вроде уходим от него.

Забавно. Нь мнер больше идея с враппером на axious понравилась. описать враппер который сам такие ивенты генерит (на основании URI и параметров) и пройтись search-and-replace axious на axiousWrapper

Ну можешь и так сделать!

Суть одна - чтобы _перед_ запросом уходил экшен о намерении запроса.

Да, спасибо!

http://prgssr.ru/development/komponenty-vysshego-poryadka.html

ребзь. вот скажите мне. кто нибудь вообще юзает эти самые функции высшего порядка в проде ? Неужели у нас итак проблем мало?

у нас же итак обёртка в обёртке обёрткой погоняет и саги сбоку. :) на каждый чих по два компонента. презентационный и контейнер. Так ещё вон предлагают чтобы функция высерала функцию, и преподносят это так, будто бы это ваще киллер-фитча

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

Кто-нибудь делал последовательный рендер элементов списка? То есть не ждать, пока все зарендеряться, а по одному?

Кто-нибудь делал последовательный рендер элементов списка? То есть не ждать, пока все зарендеряться, а по одному?

Зачем?