через for ?

Object.keys()

не,

?

так тоже можно

https://twitter.com/dan_abramov/status/759383530120110080

Это эдж кейсы, люди в состоянии себе поотстрелять ноги контекстом

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

я просто не понимаю что ты хотел этим сказать, какая жесть

Вычислительно затратный shallow compare это дико звучит, сама по себе это одна из быстрейших операций в js

Боюсь представить, что бы иначе было с Redux, который сам по себе целиком весь завязан на shallow compare

Вычислительно затратный shallow compare это дико звучит, сама по себе это одна из быстрейших операций в js

да причем тут это, ты вообще не в ту степь пошел. я говорил про то что не нужно на каждом компоненте это делать. если у тебя есть цепочка из 10 pure компонент, то проверка вызовется на каждом, когда вполне возможно она там и ну нужна. Pure надо с умом добавлять, в боттлнеках, это все же оптимизация, а не тупо везде пихать

shallow compare в каждом компоненте, думаешь это быстро?

@ZeroBiias ты тупо к слову быстро придрался что ли?)

очевидно ты даже не вник в контекст

А чем и как лучше валидировать форму?

А чем и как лучше валидировать форму?

если форма небольшая руками, большая попробуй https://github.com/christianalfoni/formsy-react

а как рендерить массив с массивами)))

няшки мои реактивные

очевидно ты даже не вник в контекст

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

"Забей и так сойдёт"

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

ты типа перфекционист что ли? для чего оптимизировать если итак хорошо работает?

Хорошее отношение к делу,, респект

Хорошее отношение к делу,, респект

кто это оценит? только для себя что ли? дрочить на код сидеть?

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

и если коллеги с легкостью поймут мой код

если его будет легко править

Хуяк хуяк и в прод, окей, ага

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

Проблема в том

Что workaround для этой проблемы читается и поддерживается лучше, чем такая мешанина из функций

но чего тут думать. когда фигачить надо, не правда ли

ты щас хочешь сказать что я фиговый код пишу?

Что workaround для этой проблемы читается и поддерживается лучше, чем такая мешанина из функций

какой workaround?

или как это связано с наличием PureComponent?

код без PureComponent автоматически херовый?

или как это связано с наличием PureComponent?

Ты начал человеку давать банально вредные советы, когда у него, собственно, был довольно резонный вопрос

Ты начал человеку давать банально вредные советы, когда у него, собственно, был довольно резонный вопрос

какой конкретно вредный совет я дал?

не заниматься преждевременной оптимизацией это херовый совет по твоему?

какой workaround?

recompose/withHandlers позволит вынести все эти функции отдельно и они больше не будут пересоздаваться каждый раз

https://github.com/acdlite/recompose

оно?

Да

спасибо, глчнк

ты щас хочешь сказать что я фиговый код пишу?

ПОШЛИ ВЫЙДЕМ ПОГОВОРИМ. Выводы предлагаю сделать самостоятельно

recompose/withHandlers позволит вынести все эти функции отдельно и они больше не будут пересоздаваться каждый раз

справделивости ради это не решает проблему с тем что человек не хочет пробрасывать index в дочерний компонент

ПОШЛИ ВЫЙДЕМ ПОГОВОРИМ. Выводы предлагаю сделать самостоятельно

ну я вот лично не понял этимх нападок и громких заявлений в мой адрес. к чему все это было?

ты хочешь сказать что проверка не отнимает совсем процессорного времени в отличие от рендера?

скорее всего отнимет меньше, если проверка дала false

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

видимо самое простое это тупо игнорировать onChange в shouldComponentUpdate

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

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

видимо самое простое это тупо игнорировать onChange в shouldComponentUpdate

а там @autobind или class props?

@mkusher в плане?

class MyComponent ... { onChange = (value) => this.setState({value})

автобинд да

класс пропс не юзаю ибо при наследовании не работает

а зачем вы наследуете компоненты о.о

ну потому что не все задачи решаются композицией

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

у меня штук 7 форм, у которых одинаковый методы

как это решить композицией?

cleanData странный

ну собстно вынести этот метод submit в компонент повыше

и передавать его в пропсах остальным

да, я смотрю на него и пытаюсь понять

нахрена

так

:)

ERROR: S client not available

а выше куда?

<Modal> <Form /> </Modal>

для начала попробуй не растягивать 12 слов на 4 сообщения

для начала попробуй не растягивать 12 слов на 4 сообщения

тут сам разберусь

ну, сделать hoc

да это по-сути и есть hoc

хотя

тебе тогда и тестировать их проще

и в каком-нибудь storybook смотреть

вместо submit пихаешь action("my form submitted")

блин, ты меня загрузил

поставил заметку на потом )

а то щас еще день в рефакторинге профукаю

Посоны

по поводу индексов, да пока сделаю тупо curryRight на onChange(value, index) а потом когда тормоза начнутся зафигачу shouldComponentUpdate

Тут такой вопрос: кто нибудь писал плагины для фотошопы?

о, кстати вопрос хороший

actions такое днище

Ну шоп поддерживает HTML/JS

А вот интересно можно ли реакт впхать туда ?

)

а есть ман? я не даже не очень понимаю что гуглить

Да я в доках к апихе колупаюсь

линк, плз

Шоповской апихе

Блин я с телефона

Ща попробую

оок

Сраный айфон же

http://www.adobe.com/devnet/photoshop/scripting.html

оно?

Ага