тогда и будет новый проход по циклу

Почитай как работает реакт и редакс

И вопросы отпадут

раз читал доки реакта, два редакса, и один react-redux

одноправленный поток данных

не изменять

а

{ ...state, *}

или

Object.assign

открой то место, где connect в редаксе

https://github.com/alibaba/rax

Алибаба написала свой реакт?

Подскажите, пожалуйста, еще раз) Есть пример корзины https://github.com/reactjs/redux/tree/master/examples/shopping-cart . В нем редьюсеры корзины и товаров работают раздельно и объединены через combineReducers. Внутри одного редьюсера нельзя получить доступ к данным другого, не прибегая к каким-то хакам (типа написания своего combineReducers или использования reduce-reducers). Как можно разрешить ситуацию, когда допустим нужно удалить товар из списка товаров, и одновременно удалить его идентификатор из корзины? Насколько адеватно в данной ситации ипользовать redux-thunk для отправки двух экшенов? Или лучше дать возможность редьюсеру товаров знать о содержиом корзины и при удалении товара убирать из нее отсутствующие идентификаторы?

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

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

dispatch({ type: deleteLot, payload: id }))

А на этот экшн просто реагируют редюсеры списка товаров и корзины

А потом через action.type отловить его в двух редьюсерах. Спасибо))

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

В продолжении оптимизации размера бандла: yarn install && webpack // bundle.js === 940 kb (min) ... npm install && webpack // bunble.js === 807 kb (min) вообщем картина такая: immutable: ^3.8.1 draft-js: свой форк, └── immutable: ~3.7.4 draft-js-plugins-editor: 2.0.0-beta1 ├── immutable: ^3.8.1 └── draft-js: >=0.9.1 └── immutable: ~3.7.4 c yarn я получаю 2 draft-js и 3 immutable c npm я получаю 1 draft-js и 2 immutable вот так, заглядывайте внутрь ваших бандлов ))

https://github.com/facebookincubator/create-react-app/issues/1397 по-моему это об этом https://github.com/yarnpkg/yarn/issues/2306 + https://twitter.com/dan_abramov/status/821079469997834241

нахрена вам ярн?

скучно живется без лишних абстракций и багов?

Более удобный shrinkwrap изкоробки

Скорость

ахаха

ясн

-_-

Сказал бы уж что-нибудь

скучно живется без лишних абстракций и багов?

this

+ прокся фб

+ прокся фб

Вот это вот мне не очень нравится

а баги тебе ок?

что шринквра обещанный не работает

что вообще все херово работает

this

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

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

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

я не использую ярн пока, точнее, просто не использую, без "пока", но наблюдаю

Может быть. Как минимум они составляют конкуренцию и чуваки в npm зашевелились.

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

это было одно из обещаний их

Может быть. Как минимум они составляют конкуренцию и чуваки в npm зашевелились.

вопрос мой звучал как "нахрена вам ярн?"

короче. у yarn хорошая идея, но плохая реализация. мы сразу попытались прикрутить его к нашему проекту, денёк порадовались скорости. а потом как посыпались баги. лучше потерпеть медленный npm, чем ждать сюрпризов от yarn

вопрос мой звучал как "нахрена вам ярн?"

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

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

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

и один замечательный ребейз был

тоже огонь

с пуш форс

я тут еще кой чо принес https://twitter.com/chicoxyzzy/status/821167460879659008

InnerHTML плохо потому что санитизация тогда ложится на плечи разработчика :) вместо того чтобы использовать средства реакт :) если в innerHTML попадают данные от пользователя, получите XSS :)

а если не используется innerHTML, то гарантируется защита от XSS? :)

Возникла идея, чтобы в компонентах использовать только получение данных из redux-store, а всю логику уже писать отдельно, т.е. если при запросе get-some-stuff получаешь пустой массив, то стор решает что нужно подгрузить данные с апи, такое вообще практикуется? Есть какая инфа?

Возникла идея, чтобы в компонентах использовать только получение данных из redux-store, а всю логику уже писать отдельно, т.е. если при запросе get-some-stuff получаешь пустой массив, то стор решает что нужно подгрузить данные с апи, такое вообще практикуется? Есть какая инфа?

лучше подстраховаться через флажки типа notAsked и error на случай если пустой набор данных может быть валидным ответом. иначе есть возможность уйти в бесконечный цикл

Такой вопрос. Есть форма с несколькими инпутами, хочу создать компонент инпут и переиспользовать его, но у инпутов есть разные свойства, например где-то есть data-name свойство а где-то нет. Могу ли я просто добавлять это свойство там где оно мне нужно?

я тут еще кой чо принес https://twitter.com/chicoxyzzy/status/821167460879659008

acdlite писал что в релизе fiber они не будут трогать context api, поскольку не хотят усложнять миграцию. Но когда все более-менее перейдут, то начнут пилить подобные изменения.

Такой вопрос. Есть форма с несколькими инпутами, хочу создать компонент инпут и переиспользовать его, но у инпутов есть разные свойства, например где-то есть data-name свойство а где-то нет. Могу ли я просто добавлять это свойство там где оно мне нужно?

стандартная практика - пропсы от родителя разбираются в виде const { prop1, prop2, ...rest } = props; render <Component {...rest} childProp1={} childProp2={} /> {...rest} может менять позицию. т.е. идти в конце а не в начале, например, в зависимости от.

то что прямо не утилизируется чайлдом проваливается через rest, соответственно

Кстати, влезу еще с одним вопросом. Есть какой-нибудь компонент для добавления функционала isVisible в react? Нужно проводить действия только для видимых компонентов, иначе приложение с 300+ сущностей умрет от пересчетов

Кто-нибудь юзает sugarss, как линтите?

А такая запись допустима? data-name={this.props.data-name}

Кстати, влезу еще с одним вопросом. Есть какой-нибудь компонент для добавления функционала isVisible в react? Нужно проводить действия только для видимых компонентов, иначе приложение с 300+ сущностей умрет от пересчетов

если это какое-то подобие таблицы то можно поюзать react-virtualized есть еще react-waypoint если надо отслеживать попадание компонента во вьюпорт

уже юзаю waypoint

вроде то что нужно

А такая запись допустима? data-name={this.props.data-name}

очевидно что нет

Спасибо за помощь

ERROR: S client not available

this.props['data-name'] — такая допустима, но пример с rest выше более react-way

я тут еще кой чо принес https://twitter.com/chicoxyzzy/status/821167460879659008

Теперь понятно, почему контекст местами стал поломан в 16.0.0

Понятно, сделал с использованием rest

this.props['data-name'] — такая допустима, но пример с rest выше более react-way

нахрена вам ярн?

Когда проект в стадии активной разработки, и тебе надо по 10 раз переустанавливать разные пакеты, то yarn решает проблему скорости. И да, я хорошо понимаю все минусы. Когда активная разработка закончится то там будет npm и время установки меня волновать не будет. В моем конкретным случаее yarn сделал более правильно, т.к. мой форк draft-js не соответствует версии приходящей в зависимостях другой либы. Логику npm тоже можно обьяснить т.к. в package.json моего форка была указанна та же версия. Кстати и 3 и 4 npm ведут себя одинаково.

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

Как ты успеваешь за всем следить? о.о

вопрос мой звучал как "нахрена вам ярн?"

https://github.com/facebookincubator/create-react-app/issues/1397 еще такой ишью появился, где поломан ярн и начинает устанавливать множество дубликатов и размер ноде_модулес превышает гигабайт)

Когда проект в стадии активной разработки, и тебе надо по 10 раз переустанавливать разные пакеты, то yarn решает проблему скорости. И да, я хорошо понимаю все минусы. Когда активная разработка закончится то там будет npm и время установки меня волновать не будет. В моем конкретным случаее yarn сделал более правильно, т.к. мой форк draft-js не соответствует версии приходящей в зависимостях другой либы. Логику npm тоже можно обьяснить т.к. в package.json моего форка была указанна та же версия. Кстати и 3 и 4 npm ведут себя одинаково.

Так npm только доставит новые, какая проблема будет со скоростью?) Или у вас каждый час новый проект и все заново ставить?

Так npm только доставит новые, какая проблема будет со скоростью?) Или у вас каждый час новый проект и все заново ставить?

добавил одну либу, вторую, третью, все удалил и т.д. я только когда изучал свою проблему раз 20 сносил папку node_modules и пока ждешь npm отрыл чатик и ... пол часа про##ал )) причем yarn cache clean && rm yarn.lock && rm -f node_modules && yarn install ощутимо быстрее rm -f node_modules && npm install

Ну это специфичный кейс. У нас со скоростью многое решило локальный npm)

Ну это специфичный кейс. У нас со скоростью многое решило локальный npm)

Мы тестили, большую часть времени тратило на распаковку архивов, в итоге на кажом билде делаем снапшот, а потом prune & install

Мы тестили, большую часть времени тратило на распаковку архивов, в итоге на кажом билде делаем снапшот, а потом prune & install

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

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

У нас тоже похожие проблемы были и ярн был медленее npm

this.props['data-name'] — такая допустима, но пример с rest выше более react-way

Нет

this.props['data-name'] — такая допустима, но пример с rest выше более react-way

Не надо так

Не надо прокидывать все пропсы без разбора

Не надо прокидывать все пропсы без разбора

Why not?

без разбора, вообще, не надо ничего делать. разобрали что нужно а остальное прокинули

@chicoxyzzy изоморфных ocaml-фреймворков ещё не встречал?

чот было

но в плохом состоянии

Я чёт залип на окамле

Все таки гораздо круче скалы

скала чот портится, да( все же влияет что там студенты одни пишут кроме Одерски(

пишут, защищаются и уходят, а на их место другие 5. и так раз в 1-2 года

хотя там говорят еще на фуллтайме целых 3 человека?

Скалу портит джава

Я чёт залип на окамле

тебе надо с Андреем Поппом пообщаться. у него такое же заболевание)

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

когда начинаю пробовать

Это все от флоу

Скалу портит джава

ну не