После того как произойдёт дебоунс текст восстановится

у тебя там ангуляр что ли?

React

сделай мьютекс

ну думаю это решаемо, cWP => setState, в debounce чекай стейт

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

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

Сложно

ну думаю это решаемо, cWP => setState, в debounce чекай стейт

И как правильно это сделать?

ну так у тебя асинхронные действия и очевидный рейс кондишн, как ты без мьютекса вообще живешь?)

Мьютексы плохо

@ Системный архитектор

Системный архитектор значит или идиот или что-то знает, чего не знаем мы

Экшоны можно, наверное, как-то в очередь складывать

в сагу

так пивас говорит экшены медленные слишком

Да

debounce хорошая идея, но без мьютексов не рабочая

К тому же это неочевидно, как реализовать

Скорее всего я создам Redux для компонентов

Глобальный EventEmitter

В которой будут сыпаться события для общения между компонентами

Что думаете?

@sergeysova

@sergeysova

Не знаю. Глобалы чаще всего плохо выходят

Можно реализовать на подобии Redux

Чтобы тоже через HOC

Ребят, подскажите. Есть форма с кучей полей и сложной логикой валидации, доступности и отображаемости полей: https://gist.github.com/nikolaas/bfe354b58026b06ae185c0c867f18591 Практически в каждом поле требуется employer. Сам employer приходит из редакса. Сейчас сделано так, что employer пробрасывается в каждое поле через свойства. Но мне это не очень нравится, потому что в дальнейшем это тяжело будет поддерживать. Как правильнее сделать: 1) оставить проброс через свойства 2) завернуть каждое поле в connect и брать employer напрямую из редакса 3) положить employer в контекст формы и в полях вытаскивать его оттуда

из гиста нихера не понятно что ты хочешь )

в EmployerForm есть переменная FormFields которая нигде не используется

Ребят, подскажите. Есть форма с кучей полей и сложной логикой валидации, доступности и отображаемости полей: https://gist.github.com/nikolaas/bfe354b58026b06ae185c0c867f18591 Практически в каждом поле требуется employer. Сам employer приходит из редакса. Сейчас сделано так, что employer пробрасывается в каждое поле через свойства. Но мне это не очень нравится, потому что в дальнейшем это тяжело будет поддерживать. Как правильнее сделать: 1) оставить проброс через свойства 2) завернуть каждое поле в connect и брать employer напрямую из редакса 3) положить employer в контекст формы и в полях вытаскивать его оттуда

Контекст?

Контекст?

контекст редакса

а почему не хочешь подключить сам филд к редаксу?

почему у тебя Field знает что такое employer?

Не, я про то, что ты эмплоера можешь через контекст пробрасывать

почему у тебя Field знает что такое employer?

потому что там у каждого Field есть логика завязанная на employer

получается у тебя Field это smart компонент?

получается у тебя Field это smart компонент?

ага. Field это Hoc над реальными инпутами

Не, я про то, что ты эмплоера можешь через контекст пробрасывать

аа. ну так вот я и не знаю стоит ли так делать. Вроде не рекомендуют использовать контекст

раз он HOC зачем ему в пропсы пихать employer?

аа. ну так вот я и не знаю стоит ли так делать. Вроде не рекомендуют использовать контекст

Не рекомендуется не значит, что никогда не пригодится

раз он HOC зачем ему в пропсы пихать employer?

Это HoC, который принимает конфиг поля в виде { disabled: ({employer}) => //тут логика зависящая от employer }

ох чето прям попахивает

Вы не можете использовать HOC, как компонент, поэтому это либо не HOC, либо ваш Gist нерабочий

В общем каждое поле готовится примерно так const enhance = pipe( createEmployerField('INN', 'ИНН'),//HoC который прячет в себе разметку вокрут инпута withBackendConfiguration('INN'),//HoС, который дополняет параметрами пришедшими с бекенда withComputableProps({//HoC, который вычисляет динамические свойства disabled: ({employer}) => employer.status === 0; }) ); export const INN = enhance(props => ( <FormText {...props} validators={{ required }} /> ));

потом я использую их <INN employer={employer}>

но пробрасывать каждый раз employer не удобно.

Если у ва есть необходимое и достаточное количество параметров, для определения в mapStateToProps employee, до withComputedProps, то используйте в композиции connect. Если employee завязан на internal state, то передавайте props. Если employee требуется на глубоких уровнях дерева компонента, то используйте context.

Если у ва есть необходимое и достаточное количество параметров, для определения в mapStateToProps employee, до withComputedProps, то используйте в композиции connect. Если employee завязан на internal state, то передавайте props. Если employee требуется на глубоких уровнях дерева компонента, то используйте context.

employee не завязан на internal state. и глубокой вложенности нет. employer нужен только в withComputableProps. Получается что надо юзать connect. А это не будет напряжно - на каждое поле вешать connect?

Можете использовать. Reselect, безусловно connect достаточно комплексный HoC, но даже при 1000 компонентах присоединённых к redux работает все шустро. Думаю у вас в целом есть архитектурная ошибка, в связи с чем появилась такая странная с первого взгляда зависимость.

Можете использовать. Reselect, безусловно connect достаточно комплексный HoC, но даже при 1000 компонентах присоединённых к redux работает все шустро. Думаю у вас в целом есть архитектурная ошибка, в связи с чем появилась такая странная с первого взгляда зависимость.

Ок. Понял. А вот про архитектурную ошибку можно поподробнее еще? А почему зависимость странная? И в какую смотреть чтобы поправить ее.

У меня есть объек employer, который я редактирую с помощью этой формы. И логика редактирования зависит от него же

Где мне ее описывать. В самой форме я не хочу этого делать потому что будет дофигища кода в ней

поэтому я попытался как-то разделить логику

Возможно в сторону декомпозиции employee и передачи в Field только нужной информации. Нужно более близко знакомиться с внутренностями

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

Возможно в сторону декомпозиции employee и передачи в Field только нужной информации. Нужно более близко знакомиться с внутренностями

Хорошо. спасибо. буду думать.

Хорошо. спасибо. буду думать.

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

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

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

ладно. щас попробую упростить композицию своих Hoc-ов потом посмотрю что получится

кто-то может помочь? function subscribe(socket) { return eventChannel(emit => { socket.on('client message', res => { emit(addMessage(res)) }); return () => {} }) } срабативает action addMessage, но он не идет дальше в reducer, почему так?

А диспатч прописан?

можно пример?

с put все работает, а здесь нет

addMessage откуда берётся? Мы же про redux да?

ERROR: S client not available

export function addMessage(message) { return {type: ADD_MESSAGE, message} }

action

MapDispatchToProps есть?

Или просто импортируешь и херачишь?

импортирую и херачу

Плохо

Нужен @connect

с put работает

в saga

А, сага

Там своя атмосфера

Я ей не пользуюсь :)

Но 100% где-то диспатч проебан кмк)

я находил пример с ней

в нем все нормально било

ы

без диспатч

Тебе виднее)

И как правильно это сделать?

имел ввиду типа такого https://codesandbox.io/s/gLxp8r0nr

может есть какие-то hoc'и которые делают что-то похожее...

может есть какие-то hoc'и которые делают что-то похожее...

Это прикольно, но работает не правильно

Хотя

Как он это делает?

В чём магия?

что именно? там в cWRP есть debounce.cancel

и между cWRP и onChange (что сначала пишет в стейт) есть флаг this.state.pending

Ааа

всё

вижу

Да, классно

Но это костыль