Раз раз раз ето ребас

Раз раз раз ето ребас

Ты уже так шутил

Загугли "ето ребасс"

На чистую воду!

Кек

Вычо за мной записываете уже? ?

парни, вопрос

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

посмотрел в профайлер, там вот такое добро

ивент — клик в меню

и чет огромный промежуток от ивента до gc, в который вроде никаких действий не выполняется

причем такая херня только в фф, и не ясно вообще, что лаг вызывает

как такое вообще дебажить?

Functions are not valid as a React child что я делаю не так? const EnhancedForm = ({ data }) => ( withFormik({ mapPropsToValues: () => ({ ...data }), handleSubmit: (values, { setSubmitting }) => { console.log('submit', values) } })(Form) ) <EnhancedForm data={changingData} />

Сейчас не модно что ли писать onClick={this.props.onClick} а модно так. Что-то я пропустил? onClick={() => this.props.onClick()} https://cdb.reacttraining.com/react-inline-functions-and-performance-bdff784f5578

Сейчас не модно что ли писать onClick={this.props.onClick} а модно так. Что-то я пропустил? onClick={() => this.props.onClick()} https://cdb.reacttraining.com/react-inline-functions-and-performance-bdff784f5578

не надо писать так onClick={() => this.props.onClick()}

насколько я понял из сегодняшнего курса по реакту, дело не в моде. his.props.onClick() используется когда надо присунуть параметры и не хочется это делать через .bind()

но вот в статейки пишут что устарело

https://www.youtube.com/watch?v=pgAvVxowaYU

этот чертяка дотошно разбирает все аспекты

react-dropzone кто-нибудь использует? Они там что-то накосячили с дефолтным экспортом и начиная с какой-то версии импорт не работает, приходится использовать компонент в виде <Dropzone.default />

но конкретно этот я не помню. возможно уже в платной части разбирал

Но это ладно бы, но в production сборке и это не работает ?

но вот в статейки пишут что устарело

что устарело?

лол

Устарело писать так. onClick={this.props.onClick} Может я конечно не вкурил.

И он разбирает другой кейс. (проброс пропса сверху)

Устарело писать так. onClick={this.props.onClick} Может я конечно не вкурил.

А как надо писать? О_о

https://t.me/javascript_jobs

Устарело писать так. onClick={this.props.onClick} Может я конечно не вкурил.

если параметры не нужны то не устарело

Ребят, подскажите, плез, по мобиксу, чет тупак словил class State { @observable a = 1; @observable b; constructor() { reaction(() => this.a, a => this.b = a) } } при цикле GC reaction помрет, если объект больше нигде не юзается?

Ребят, подскажите, плез, по мобиксу, чет тупак словил class State { @observable a = 1; @observable b; constructor() { reaction(() => this.a, a => this.b = a) } } при цикле GC reaction помрет, если объект больше нигде не юзается?

Редакс

Сейчас не модно что ли писать onClick={this.props.onClick} а модно так. Что-то я пропустил? onClick={() => this.props.onClick()} https://cdb.reacttraining.com/react-inline-functions-and-performance-bdff784f5578

ты каждый раз кидаешь новую пропсу во втором варианте

Сейчас не модно что ли писать onClick={this.props.onClick} а модно так. Что-то я пропустил? onClick={() => this.props.onClick()} https://cdb.reacttraining.com/react-inline-functions-and-performance-bdff784f5578

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

Сейчас не модно что ли писать onClick={this.props.onClick} а модно так. Что-то я пропустил? onClick={() => this.props.onClick()} https://cdb.reacttraining.com/react-inline-functions-and-performance-bdff784f5578

При каждом рендере создает новый контекст для функции и это плохая практика. Но это не точно, может ктото уточнить?

Всем привет. Как для img в .tsx использовать file-loader а для .css url-loader?

Вроде и не мертвый чат. А на вопросы мои никогда никто не отвечал)

Сейчас не модно что ли писать onClick={this.props.onClick} а модно так. Что-то я пропустил? onClick={() => this.props.onClick()} https://cdb.reacttraining.com/react-inline-functions-and-performance-bdff784f5578

что значит модно/не модно сам же привёл статью, где всё аргументировано хорошо

Сейчас не модно что ли писать onClick={this.props.onClick} а модно так. Что-то я пропустил? onClick={() => this.props.onClick()} https://cdb.reacttraining.com/react-inline-functions-and-performance-bdff784f5578

пара советов есть на эту тему но все они сводятся к контексту использоания () => this.handleClick() юзается если ты описал хендлер как метод, а не как проперти ещё юзается, когда порядок аргументов не устраивает. например есть некоторые библиотеки которые в onClick бросают value, props, event и тебе хочется поменять порядок onClick={(value, props, event) => props.someClick(event, value)} но всё это полностью убивает PureComponent, так как на каждый рендер будет новая функция. И не дай бог ты в замыкании хендлера прокинул какие-то важные данные, например список. А в sCU компонента этот пропс с функцией не проверяешь, то будут ОЧЕНЬ странные эффекты. кейс onClick={props.handlerClick} лучше использовать в большинстве возможных случаев, он легко проверяется в Pure и sCU. Не городит новых функций. Но в нем сложнее отследить пробрасываемые параметры. У себя в проекте я решил, что в хендлерах всегда должен пробрасывать первым аргументом event

При каждом рендере создает новый контекст для функции и это плохая практика. Но это не точно, может ктото уточнить?

никакой "новый контекст" не создаётся, почитай про стрелочные функции. У них правильнее сказать "нет контекста" А новая функция каждый раз создаётся, да

Всем привет. Как для img в .tsx использовать file-loader а для .css url-loader?

@typescript_ru

никакой "новый контекст" не создаётся, почитай про стрелочные функции. У них правильнее сказать "нет контекста" А новая функция каждый раз создаётся, да

контекст для функций вообще странное слово у фунций есть замыкание и некое this значение, которое может быть прибинденным или же динамическим (ну и аргументы тоже) в v8 FunctionContext содержит в себе все три куска функции: arguments, this, closure а функция состоит из FunctionBody и FunctionContext

ну и принято это самое this называть "контекстом", как по мне так вроде нормально это

@typescript_ru

Я понял. Спасибо

Ну так лишние замыкание создвется ? или нет?

контекст для функций вообще странное слово у фунций есть замыкание и некое this значение, которое может быть прибинденным или же динамическим (ну и аргументы тоже) в v8 FunctionContext содержит в себе все три куска функции: arguments, this, closure а функция состоит из FunctionBody и FunctionContext

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

Ну так лишние замыкание создвется ? или нет?

замыкание создается только когда ты обращаешься к переменным за пределом функции

(a) => a — нет замыкания (a) => a + b — есть замыкание

Ну так лишние замыкание создвется ? или нет?

вопрос в том, что ты теряешь Когда мы пишем <SomeComponent className="container" /> то о нет, на каждый рендер создаётся строка "container" Можно тоже сохранить в переменную и обращаться для экономии...нулевой экономии)

onClick={()=> this... this получается за пределом

непонятно...

вопрос в том, что ты теряешь Когда мы пишем <SomeComponent className="container" /> то о нет, на каждый рендер создаётся строка "container" Можно тоже сохранить в переменную и обращаться для экономии...нулевой экономии)

примитивы не по ссылке сравниваются, а по значению

примитивы не по ссылке сравниваются, а по значению

и что? Я про сравнение ничего не говорил) а про создание

люди-то переживают обычно, что новая функция создаётся

ERROR: S client not available

onClick={()=> this... this получается за пределом

в данном случае замыкания нет, так как this равен месту объявления фукцнии

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

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

@javascript_jobs

Корректно описанные компоненты не должны обновляться от () => fn() в onClick

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

Вебпаковский?

Потому что onClick рано или поздно попадает в стандартные react-dom компоненты, а им вообще до лампочки что там с функцией

в данном случае замыкания нет, так как this равен месту объявления фукцнии

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

Потому что onClick рано или поздно попадает в стандартные react-dom компоненты, а им вообще до лампочки что там с функцией

ну это не всегда если компонент сложный и вообще не комильфо на каждый тык в инпут перерендеривать все поэтому появляется sCU и в этом sCU не проверяется хэндлер

Что значит всё? Я про это и пишу

<input /> по барабану на обновления функции

В этом и суть

Только юзерские компоненты могут триггериться от новой функции в пропсах

у меня был такой компонент, описывает массив значений, с возможностью поменить один как дефолтный можно добавлять ещё значений и удалять

всё в большой форме

и если не добавлять проверок, то начинаются дикие лаги

ну это не всегда если компонент сложный и вообще не комильфо на каждый тык в инпут перерендеривать все поэтому появляется sCU и в этом sCU не проверяется хэндлер

> и вообще не комильфо на каждый тык в инпут перерендеривать все Ну спорно, реакт появился, проталкивая мысль что как раз ничего страшного (если под словом "ререндер" мы подразумеваем вызов методов рендер, а не реальный ререндер DOM'а) Это не значит, что SCU не нужен вообще, это значит, что он нужен только там, где он действительно нужен) И надо помнить, что вполне реален случай, когда проверки в sCU могут быть даже медленнее. И так же просто надо иметь в виду, что если эти проверки чаще возвращают false, чем true, то это тоже потенциальный источник падения производительности

> и вообще не комильфо на каждый тык в инпут перерендеривать все Ну спорно, реакт появился, проталкивая мысль что как раз ничего страшного (если под словом "ререндер" мы подразумеваем вызов методов рендер, а не реальный ререндер DOM'а) Это не значит, что SCU не нужен вообще, это значит, что он нужен только там, где он действительно нужен) И надо помнить, что вполне реален случай, когда проверки в sCU могут быть даже медленнее. И так же просто надо иметь в виду, что если эти проверки чаще возвращают false, чем true, то это тоже потенциальный источник падения производительности

я с тобой не хочу спорить, ты прав. я вообще редко описываю pure и sCU (shouldComponentUpdate)

> и вообще не комильфо на каждый тык в инпут перерендеривать все Ну спорно, реакт появился, проталкивая мысль что как раз ничего страшного (если под словом "ререндер" мы подразумеваем вызов методов рендер, а не реальный ререндер DOM'а) Это не значит, что SCU не нужен вообще, это значит, что он нужен только там, где он действительно нужен) И надо помнить, что вполне реален случай, когда проверки в sCU могут быть даже медленнее. И так же просто надо иметь в виду, что если эти проверки чаще возвращают false, чем true, то это тоже потенциальный источник падения производительности

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

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

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

ну в таких случаях PureComponent to the rescue конечно :)

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

ну в таких случаях PureComponent to the rescue конечно :)

не поможет если есть функции генерируемые))) а я не могу гарантировать этого

не поможет если есть функции генерируемые))) а я не могу гарантировать этого

Можно написать свой пюре который будет трекать изменения всего кроме функций

Можно написать свой пюре который будет трекать изменения всего кроме функций

ахах)) я уже думал сделать такое ?

кто идет на митап? ребзи, все прям ко времени туда придут?