it works ?

https://pastebin.com/z1H2DvPr

how does it happen with another quote `

rather thatn single quote ’ or ” ?

@sweetmaanu https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals

@sweetmaanu https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals

thanks a lot a lot to learn ?

would you mind to help me for this please @egoarka

so late

ssry

i go sleep now

i go sleep now

ok no problem appreciated your help

thanks

?

вы переопределяете react/jsx-wrap-multilines правило? const Foo = () => ( <A> <B /> </A> )

vs. const Foo = () => <A> <B /> </A>

prettier без скобок вроде делает

Привет Suresh. Прежде чем писать, прочитай правила чата. Они есть в прикрепленном сообщении.

ходят слухи, что реакт 16 зарелизят прямо на (или мб немного до) React Rally

он будет быстрее vue?

он будет быстрее vue?

А тебе сильно нужна скорость?

А тебе сильно нужна скорость?

сейчас это конкурентное преимущество вью, он быстрее, хоть и не намного

Зачем тебе нужна скорость?

Почему выбрали и что не понравилось в сагах ?

Я redux-most юзаю, это почти то же самое. Костыльные "саги", не отвечающие даже своему названию, не нужны

У тебя там квантовая механика?

Зачем тебе нужна скорость?

Кокаинум

Да просто так

Конечно никому ыуе не нужен, даже с т.н. "скоростью"

Конечно никому ыуе не нужен, даже с т.н. "скоростью"

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

просто так, чтобы не было факта "вью быстрее"

Могу им только посочувствовать

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

В реакте ловится такое безумное количество эдж кейсов, что смысла в абстрактной скорости вуя не остаётся

просто так, чтобы не было факта "вью быстрее"

Фаллометрия

Валидные причины перехода на жуе: 1) Вы китаец 2) Вам 15 лет и вы нон-конформист 3) Вам не зашёл ангуляр

Валидные причины перехода на жуе: 1) Вы китаец 2) Вам 15 лет и вы нон-конформист 3) Вам не зашёл ангуляр

Ты про прод?

Типа того

С реакта на вью переходить сомнительно

Особенно в преддверии 16

Ага)

чем обновить state в редюсере, чтобы при обновлении стейта не затирались пропы второй вложенности types, но затиралось все что внутри types? { cache: false, filter: { ids: [], types: {} } }

combineReducers

это объект редюсера, он залетает в стор через combineReducers

хотелось бы чтобы types затирались при обновлении, а ids нет (если они не обновляются)

хотелось бы чтобы types затирались при обновлении, а ids нет (если они не обновляются)

...state

это объект редюсера, он залетает в стор через combineReducers

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

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

Вот, кстати, интересно, в какой момент разбивание на много режьюсеров начинает сажать производительность?

Ведь чем больше редьюсеров, тем больше вызовов на каждый экшен

Не нужна. Методология это всеголишь набор правил которым нужно следовать чтобы получить ожидаемый результат. В этом плане в CSS-in-JS пока нет таких универсальных устоявшихся правил, но они появятся.

CSS-in-JS?

Написать что ль либу, чтобы редюьсеры вызывались только на определенные экшены?

чем обновить state в редюсере, чтобы при обновлении стейта не затирались пропы второй вложенности types, но затиралось все что внутри types? { cache: false, filter: { ids: [], types: {} } }

{ ...state, filter: { ...state.filter, types: newTypes, }, }

Вот, кстати, интересно, в какой момент разбивание на много режьюсеров начинает сажать производительность?

combineReducers — быстрая операция, с линейными затратами производительности, поэтому скорее всего всегда будут более тяжёлые проблемы чем несколько комбинаторов)

combineReducers — быстрая операция, с линейными затратами производительности, поэтому скорее всего всегда будут более тяжёлые проблемы чем несколько комбинаторов)

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

Ну и что) Большинство из них всё равно ничего делать не будут

А они в стэк кладутся или через setTimeout?

В прочем, я могу и сорцы посмотреть?

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

в redux-actions же хешмэп, соответственно должны дёргаться только нужные

Ну и что) Большинство из них всё равно ничего делать не будут

Ты просто со своим функциональным спрашиваешь и там это не сыграет. А так редусеры на свитчах все равно сделают проверки на все экшены.

В прочем, я могу и сорцы посмотреть?

Ну вот да) В redux вообще простые и очевидные исходники, ето вам не реакт реконсилейшн ?

Ты просто со своим функциональным спрашиваешь и там это не сыграет. А так редусеры на свитчах все равно сделают проверки на все экшены.

Я про это и пишу. switch — пренебрежимо быстрая операция

combineReducers меж тем — это обычный цикл for i

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

В целом-то да, но если есть возможность уменьшить количество вызовов, то почему нет?

ERROR: S client not available

Не получится

Смысл redux в том, что любое поле любой вложенности может среагировать на любой экшн

Я про это и пишу. switch — пренебрежимо быстрая операция

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

Поэтому отсекать по скоупам всё равно не получится

Смысл redux в том, что любое поле любой вложенности может среагировать на любой экшн

Я знаю:)

Я про это и пишу. switch — пренебрежимо быстрая операция

Ну если бы это был 1 большой. А так там еще создание контекста натекает. Свитчи не так хорошо оптимизируются как это могло бы быть. В целом еще бы все в SMI и было бы нормально.

Но SMI дебажить трудновато

Поэтому отсекать по скоупам всё равно не получится

Точнее как, в общем случае не получится. Но никто не мешает делать свои какие-то артефакты под свои задачи)

У меня например есть иммутабельный redux list и indexed reducer)

Экась ты костыль-то обозвал артефактом

Да почему костыль) redux — это жёсткий базис, отправная точка, это нормально — делать что-то с ним под свои задачи)

У меня например есть иммутабельный redux list и indexed reducer)

Первый — это автоматизация подхода { ids: [], byId: {} }, ну типа нормализованного списка, второй на его основе — это редюсер, который применяется к каждому объекту в списке ? Получается как бы список с redux-моделями

Ну, как в recompos'е сделать, onlyCallForActions:)

Ну, никак ? Это у тебя уже прям memoized reducers получаются)

Затем строишь хэшмапу по экшенам, и когда приходит экшен - достаешь из хэшмапы массив редюьсеров, которые нужно вызвать

Почему никак?

Подскажите, пожалуйста, с 1 проблемой Пробую делать клиент для гиттер в целях обучения и делаю его на react-create-app (в описании уже прочитал, что скорей всего зря я так начал) Мне понадобилось добавить авторизацию (вот такую https://github.com/gitterHQ/gitter-demo-app) Я погуглил как добавить сервер к react-create-app (https://medium.com/@patriciolpezjuri/using-create-react-app-with-react-router-express-js-8fa658bf892d) и запихнул туда эту авторизацию в ней при успешной авторизации рендерится страница /home И я не понимаю как связать этот сервер и мое приложение Чтобы энтрипоинтом для реакта была не страница public/index.html, а срендеренный /home Наверное не очень понятно обьяснил, но может кто-то меня приблизительно понял и натолкнет на мысль/статью

Почему никак?

Ну он просто в другом месте же работает)

Ты просто со своим функциональным спрашиваешь и там это не сыграет. А так редусеры на свитчах все равно сделают проверки на все экшены.

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

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

use reselect

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

Вот это не проблема вообще.

Если посмотришь профилировщиком то оно времени не жрет. Типа 1мс супротив 4мс на диспатч.

Ну он просто в другом месте же работает)

Стоп, стоп, стоп. Мы же по сути заменим creareStore

И на сервере диспатч так то важнее :(

Стоп, стоп, стоп. Мы же по сути заменим creareStore

Ну да. Короче я видимо ещё не проснулся, не до конца улавливаю мысль ?

И на сервере диспатч так то важнее :(

Можно кстати по идее редуцировать ряд combineReducers в один линейный список операций: ну типа, раз каждый combineReducers — это цикл, то можно их все просто объеденить в один и не щёлкать контексты; это должно быть быстрее

как вы делаете SSR при этом используя css in js? Много подводных камней?

{ prop: true, filter: { ...state.filter, types: newTypes, }, }при обновлении prop, redux перезапустит цикл сверки не изменилось ли что-нибудь в filter? state меняю через { ...state, ...payload }

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

{ prop: true, filter: { ...state.filter, types: newTypes, }, }при обновлении prop, redux перезапустит цикл сверки не изменилось ли что-нибудь в filter? state меняю через { ...state, ...payload }

по моему даже если данные неизменными остаются, все равно будет ререндер

Написать что ль либу, чтобы редюьсеры вызывались только на определенные экшены?

Для работы с редьюсерами есть трандьюсеры