в таком случае какие проблемы с key в массивах?)

так может мне кто-то объяснить любовь к reselect? memoize по умолчанию - это же жесть. движки и так текут

А где ты увидел любовь? Есть такая штука, прикольная в ряде случаев, и не нужная в остальных 99%.

я не конкретно тут увидел. Вдруг тут есть адепты

в таком случае какие проблемы с key в массивах?)

от reuse это никак не спасает, в доках рекомендация так не делать

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

или у тебя ключ - действительно индекс в массиве, почему бы и нет?

вот несколько кейсов, где я делаю Object.entries(data).map(([name, values]) => <div/>)

ну и возьми name ключем, в чем проблема?

индекс реакт и сам проставляет, это лишнее и нерекомендуемое действие

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

смысл в том, чтобы в любой другой render предыдущий и новый key совпадали. Все. Как ты этого добьешься - твое дело

индекс реакт и сам проставляет, это лишнее и нерекомендуемое действие

А где это не рекомендуется?

index в качестве ключа не ок

точнее автоматический индекс, тот что react присваивает

что-то вот не могу найти этих слов. наверное, видел не в доке а в очередном “руководстве"

http://jaero.space/blog/react-performance-1

смысл в том, чтобы в любой другой render предыдущий и новый key совпадали. Все. Как ты этого добьешься - твое дело

вот краткая выжимка из статьи и доки реакта)

Кстати, возник еще вопрос: хорошая практика - зашивать в глупые компоненты варианты передаваемых обработчиков? Например, когда есть список айтемов, иметь возможность передать в компонент onItemClick, в который можно передать индекс. Или все-таки лучше писать как-то более абстрактно, передавая в блок какой-нибудь itemProps с нужными обработчиками, а индекс брать автомагически откуда-нибудь?

Кстати, возник еще вопрос: хорошая практика - зашивать в глупые компоненты варианты передаваемых обработчиков? Например, когда есть список айтемов, иметь возможность передать в компонент onItemClick, в который можно передать индекс. Или все-таки лучше писать как-то более абстрактно, передавая в блок какой-нибудь itemProps с нужными обработчиками, а индекс брать автомагически откуда-нибудь?

можешь ещё пояснить как-то?..)

можешь ещё пояснить как-то?..)

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

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

прошел этот туториал https://learnredux.com/view/237g5mcT8Ho

но там теперь сыплятся два варнининга, когда передаешь в чайлд компонент this.props..

гугл выдал на проблему шестидневной давности

сейчас не у компа, завтра могу скинуть ссылки..

можешь ещё пояснить как-то?..)

Смотри, у меня есть компонент input, в котором лежат всякие дивы и внутри настоящий input и есть вариант писать: 1) <div className="input"><input className="input__field" onFocus={props.onFocus}</div> 2) <div className="input" {...props}><input className="input__field" {...props.fieldParams} /></div>

Второй вариант пугает тем, что на каждый новый кейс надо лезть в компонент и добавлять туда что-то + есть вариант завязать себе самому узел, когда повесишь props.onClick куда-нибудь внутрь, а потом появляется необходимость повесить его же на родителя и вот ты уже выдумаешь названия или меняешь повсеместно

У меня просто с этим связана особая боль на работе) У нас не реакт, но одна библиотека блоков на несколько проектов и на такой рефакторинг при изменении компонентов не хватает времени)

https://github.com/facebook/react/issues/6653

кажится эта фишка, не знаю как решить, все isSue на эту тему просто закрываются..(

Второй вариант пугает тем, что на каждый новый кейс надо лезть в компонент и добавлять туда что-то + есть вариант завязать себе самому узел, когда повесишь props.onClick куда-нибудь внутрь, а потом появляется необходимость повесить его же на родителя и вот ты уже выдумаешь названия или меняешь повсеместно

то ли я всё же не очень понял, в чем проблема, то ли тебе вот это должно помочь https://facebook.github.io/react/docs/transferring-props.html#transferring-with-...-in-jsx

Может с реальным кодом понятнее будет:

https://www.dropbox.com/s/9k4zpn1otxuplfg/%D0%A1%D0%BA%D1%80%D0%B8%D0%BD%D1%88%D0%BE%D1%82%202016-05-17%2023.23.10.png?dl=0

это типа бэм-компонент что ли?

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

короче да, походу тебе именно эта ссылка нужна )

конструкцией const { specialProp, notForInput, ...other } = props; вытягиваешь специальные пропсы, остальное через {...other} инпуту передаёшь

Напрягает то, что может появиться второй элемент, которому нужно тоже уметь передавать обработчики. По сути у меня fieldParams, icon, suggest - чем то похожи

не надо fieldParams

в "other" должны остаться стандартные хтмл атрибуты

а если в компоненте нужно вешать onClick на 2 разных ноды?

в чем проблема?)

ну в other будет только один)

это разные клики, несут разный смысл, значит и называются в пропсах по-разному

ну в other будет только один)

не, не надо в other оставлять onClick. Говорю же, только стандартные атрибуты. Остальные явно вытащить)

спасибо) про это и спрашивал)

у меня панаройя похоже уже про абстрактность)

вброшу http://facebook.github.io/reason/

Понеслось

:D

не нужно

вброшу http://facebook.github.io/reason/

Что-то у меня прокрутка на этом сайт АДОВО тормозит (firefox, osx)

ага.. с gif animations перемудрили

вброшу http://facebook.github.io/reason/

Я правильно понял, что фейсбуковская OCaml-диаспора устала бодаться с INRIA и сделала свой OCaml с шахматами и поэтессами?

видимо так :) я сам пока не понимаю куда это все движется

все так

че с npm

у всех норм?

ну вроде пока это не свой окамл

но чего еще от них ожидать

это типа редактор кода пока что вроде

ERROR: S client not available

а, нет

уже началось

все очень плохо

но пока только парсер заменили

Ага: “Reason replaces part of the compiler toolchain with a completely new syntax parser that is more approachable, while still fully compatible with the rest of the compiler. “

Ничего интересного, в общем.

в общем, как и всегда :)

Для тех, кто начинает свой путь в мир React.js: https://github.com/petehunt/react-howto#learning-flux

Зачем в css-modules есть :local и :global? Ни разу не сталкивался с их необходимостью

глглобал нужен, что бы сделать глобальный css класс

Чтоб в разных модулях его юзать например? Или чтобы не обращаться к нему через style.globalClassname ?

Чтобы стили сбросить например

если ты используешь стороннюю либу в которой нет возможности что-то изменить, а там уже используется class="alibaba", тогда все что тебе остается :global(.alibaba) { color: red; }

Зачем в css-modules есть :local и :global? Ни разу не сталкивался с их необходимостью

Полагаю, потому что началось с идеи того, чтобы создавать "local" классы явно. И уже потом решили "а давайте сделаем вообще все классы local по умолчанию! Тогда не надо будет local писать". В качестве opt-out есть :global.

Кто может мне объяснить set(x) ? вот здесь - http://cl.ly/1d3o2U1v0z2U

рановато задал вопрос))

сорян, все стало понятно))

Что за статья?

https://medium.com/@gaperton/managing-state-and-forms-with-react-part-1-12eacb647112#.gsnbkdvas

от Vlad Balin

thinks

про паттерн Value Link

А что за синтаксис const TextInput(...) => ();

Stateless components

stateless component

https://facebook.github.io/react/docs/reusable-components.html#stateless-functions

не, я про языковую конструкцию

arrow function

я пишу так const TextInput = (...) => ();

возможно дело в отображении компонента в react tools