да

ой

так это ж шелоу клон

а не дип

вот дип

и в рамде тоже шелоу клон

нет

объект => destination = { ... объект } destination[property] return destination;

и в рамде тоже шелоу клон

там 2 логируется, если что

а сорри

ещё вопрос, если сделать копию объекта и удалить в нём поле, это иммутабельная операция будет?

так что ответ зависит, какую копию ты делаешь )

шелоу или дип

шалоу через {...}

я юзаю для таких операцию dot-prop-immutable

что бы не сделать случайно ошибку

нахоил, но решил сделать свою реализацию, т.к. мне нужно сохранить типы в typescript

я юзаю для таких операцию dot-prop-immutable

я юзаю object-path-immutable

судя по всему один хрен

там их много

Если б была рамда то рамбду юзал

И тут сова)

?

/stat@combot

combot.org/chat/-1001032883247

В Object.assign поменяй местами переменные, все заработает ?

Ребзи можете объяснить shouldComponentUpdate в чем отличается его работа в PureComponent и в обычном компоненте

в чистом компоненте он предопределяется

по сути в нём идёт проверка изменились ли пропы компонента

не только пропы, стейты тоже проверяются. а так да.

ну это я понял что не надо уже руками писать props.someValue === nextProps.someValue

и это все ? PureComponent вроде не может принимать children ?

Всем привет. Подскажите плиз, а то что-то туплю. Есть API бэкенда, причем статика не сервится через, например nginx, а имеет свои свои методы API, которые возвращают Content-Type:image/gif. Причем, необходимо наличие csrf хедера. Как из этого получить src аттрибут, или как-нибудь отрендерить? Так понимаю, что header не поставишь в аттрибут src html тега.

Ребзи можете объяснить shouldComponentUpdate в чем отличается его работа в PureComponent и в обычном компоненте

В обычном компоненте shouldComponentUpdate по дефолту возвращает true всегда. В Pure shouldComponentUpdate - уже реальная функция, которая производит строгое сравнение (не глубокое) значений старых и новых props и state. В обоих случаях shouldComponentUpdate можно переопределить, соответственно

В обычном компоненте shouldComponentUpdate по дефолту возвращает true всегда. В Pure shouldComponentUpdate - уже реальная функция, которая производит строгое сравнение (не глубокое) значений старых и новых props и state. В обоих случаях shouldComponentUpdate можно переопределить, соответственно

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

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

yup

Pure стоит использовать с важностью помня о двух вещах: 1) Если в компонент не поступают пропсы, изменения в которых может быть в глубине 2) Если родитель перерендеривается заметно чаще чем Pure компонент. Вообще я пришел к выводу, что Pure хорош, с учетом аспектов выше, + если в рендере много калькуляции. Иначе не стоит

лучше не полагаться на пьюр и писать шуд апдейты где они надо

+

т.к обычный onClick={()=>{ ///}}

все сломает

А не надо так делать :)

не всегда выходит так не делать

можно NonFunctionPureComponent

Pure через себя children может пропускать ?

За мои последние тысяч 5 строчек кода делал стрелку в рендере единожды, ибо в тот момент лень накинулась что-то

можно NonFunctionPureComponent

ShallowEqualsTwoLevelAndNonFunctionPureComponent

Pure через себя children может пропускать ?

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

За мои последние тысяч 5 строчек кода делал стрелку в рендере единожды, ибо в тот момент лень накинулась что-то

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

Хорошо, а чего () => в рендере его ломают

Хорошо, а чего () => в рендере его ломают

это всегда новая функция

ну да

Новая ссылка на функцию!

(()=>{}) === (()=>{}) // false

все понял

вообще ()=>{} в рендере плохая практика ?

ShallowEqualsTwoLevelAndNonFunctionPureComponent

да

вообще ()=>{} в рендере плохая практика ?

читал статью на 3 страницы текста, где в конце вывод что не стоит этим запариваться

и просто писать шуд апдейты если это критично)

просто так удобней иногда

и просто писать шуд апдейты если это критично)

++

Кстати, а кто сталкивался с перформанс проблемами при спользовании рендер колбеков

?

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

вот например

Ну это же тот же пропс, не?

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

тоже так делаю

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

чот такое

пора проблем не замечал

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

чем плохо когда метод возвразает jsx

?

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

все же лучше в реакте юзать композицию, а не наследование для такого

угу

Я видел другую идею для такого же

+

чем плохо когда метод возвразает jsx

выше же положил

пихаем компоненты в контекст и резолвим их с контекста

если есть куча методов рендера — значит компонент слишкром большой

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

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

и протестировать отдельно

Да конечно так лучше не делать, это же вообще в слепую получается, в какой-то момент, код пишешь. При цепи наследования

ну это да если методов много

Да конечно так лучше не делать, это же вообще в слепую получается, в какой-то момент, код пишешь. При цепи наследования

ненене, в рот мне ноги