Хороший урок. Только одна заметка. refs довольно използваемая щука. Я занимался с react native и там за мой проект употреблял часто refs. дело в том что иногда render довольно медленной. Часто приходилось използуват прямой доступ до елемент с метод типа SetNattiveProps. Я вам честно скажу, что иногда не хватает концепция "сделай возможно болше компонентов чтоб ускорить рендеринг и обновляй только то что нужно". Часто с цель performance приходилось прямий доступ чрез refs. Кроме того можно реализирует механизм за доступ от родителских компонент к елементов внутрии дочерного компонента (за React Native, за React я не знаю).
@@Вебануться-ф7т можно вот так в конструкторе класса прописать: const refs = ['inputRef', 'areaRef'] .forEach(item => ( this[item] = React.createRef() ));
у меня ругается редактор на то что inputRef textreaRef и selectRef not defind. почему у вас не ругается, а у меня ругается? и не могу применить такой вариант inputRef = React.createRef()
Хм, да, мы избавились от тех прохожих методов, но при этом у нас теперь будут перерисовываться все 3 компонента при изменении одного из них. На данном примере это не ощутимое различие, а вот в более крупном проекте думаю может ударить по производительности
А мне так не кажется. В конце концов страницы с формами пытаются всегда сделать как можно меньше, что бы они не пугали юзера. Поэтому я думаю что ничего критического в производительности произойти не должно
Возможно я чего-то не понимаю, но как по мне ничего не изменилось. В первом случае с методами, мы сетили в стейт значение для каждого элемента отдельно, что в свою очередь перезапускало рендер и перерисовывался элемент, для которого изменилось значение в стейт. Остальные оставались без изменений, то есть перерисовывался 1 элемент. Во втором случае мы сетим значения со всех элементов вместе. После чего срабатывает рендер и перерисовывается опять таки один элемент в которого изменилось значение в стейте. Для остальных элементов значения которые хранятся в стейте остались прежними и виртуал дом должен их пропустить и не перерисовывать. Получается что перерисуется опять только 1 элемент. Поправьте меня если ошибаюсь.
Ну во-первых, у нас не 3 компонента, а 1, и в любом случае, каким способом ты не повесь обработчики, метод render у компонента Form будет вызываться каждый раз при изменении любого из полей. Это первое. Во-вторых, даже если вы замените поля на отдельные компоненты (что вы скорее всего имели в виду), то при вызове setState на компоненте-родителе все render'ы на дочерних компонентах обязательно вызовутся. Так задумано в React изначально. Чтобы не отрисовывать дочерние компоненты, вам нужно в их методе shouldComponentUpdate вернуть false, а это уже другая история и это не зависит от того, будет ли один обработчик для всех полей или будет на каждое поле свой обработчик. Чтобы сэкономить на лишних рендерах, вам нужно в дочерний компонент пробросить через пропсы value, а в методе shouldComponentUpdate сравнить текущий value у пропс, с тем, который прилетит при изменении стейта родителя.
@@stlyak Все правильно сказал про setState, просто ref помогает свести кол-во обработчиков к минимуму но его лучше не использовать где попало тк React это все таки декларативный подход.
Даже понять не могу Кто же ети люди, что за такой качевственний контент ставят дизлайки. Спасибо за видео!
Спасибо за отзыв)
это не дизлайки, а лайки, которые ставят австралийцы :)
Спасибо за то, что вы потратили время и усилия на создание этого видеоурока. 💪 Это действительно помогло мне улучшить мои знания по теме. 📈
Спасибо большое
Сколько у тебя полезных роликов. Спасибо!
Пожалуйста
Круто, спасибо большое за качественный контент!
Спасибо и вам за обратную связь
Хороший урок. Только одна заметка. refs довольно използваемая щука. Я занимался с react native и там за мой проект употреблял часто refs. дело в том что иногда render довольно медленной. Часто приходилось използуват прямой доступ до елемент с метод типа SetNattiveProps. Я вам честно скажу, что иногда не хватает концепция "сделай возможно болше компонентов чтоб ускорить рендеринг и обновляй только то что нужно". Часто с цель performance приходилось прямий доступ чрез refs. Кроме того можно реализирует механизм за доступ от родителских компонент к елементов внутрии дочерного компонента (за React Native, за React я не знаю).
Согласен, у ref больше возможностей чем описано, есть ещё вариант записывать и хранить данные в ref, так как это быстрее
отличное видео. спасибо)
Пожалуйста
Есть ролик про useCallback и useMemo?
В плейлисте React videocast
Спасибо за видео! НО есть вопросы к такому хендлингу форм, зачем использовать controlled и uncontrolled (в совокупности) подход к работе с формами?
Возможно, я допустил ошибку. Нету плюсов такого подхода - форма всегда должна контролироваться
Подскажите пожалуйста, а если я динамически через цикл создаю элементы DOM. Как динамически мне также создать все refs (createRef())?
Да, можно и так. Хотя, как я и говорил ref желательно использовать по минимуму.
@@YauhenKavalchuk Спасибо за ответ, но я именно спрашивал про способ реализации :) Не совсем понимаю как createRef() можно в цикле прописать
@@Вебануться-ф7т
можно вот так в конструкторе класса прописать:
const refs = ['inputRef', 'areaRef']
.forEach(item => (
this[item] = React.createRef()
));
у меня ругается редактор на то что inputRef textreaRef и selectRef not defind. почему у вас не ругается, а у меня ругается? и не могу применить такой вариант inputRef = React.createRef()
Перепроверьте версию Реакта, которую вы используете. Плюс, в описании видео есть ссылка на GitHub репозиторий, так что можете свериться
@@YauhenKavalchuk спасибо, большое!
Как насчет такого?
state = {
name: "",
phone: "",
};
handleChange = (values, event) => {
this.setState({ [values]: event.current.value });
};
onChange={this.handleChange.bind(this, "name")}
onChange={this.handleChange.bind(this, "phone")}
Тоже вариант
state = {
firstName: "",
secondName: ""
}
handleChange = (e) => {
const {name, value} = e.target;
this.setState({
[name]: value
})
}
render() {
const {firstName, secondName} = this.state;
return (
)
}
не знаете как получить детей на рефу? например current.childNodes ничего не видит
А что мешает прицепить ref на все нужные элементы?
@@YauhenKavalchuk это не возможно сделать т.к. дети моего компонента находятся во внешней библиотеке, к ним нет доступа
Переделать звучит грубо, обидно, а вот проабдейтить или зарефакторить самое то)
Учту
во, и МЖЦ тут описал. Вот бы так в прошлом видео
Тогда бы получилось, что 2 раза рассказал одно и тоже)
Хм, да, мы избавились от тех прохожих методов, но при этом у нас теперь будут перерисовываться все 3 компонента при изменении одного из них. На данном примере это не ощутимое различие, а вот в более крупном проекте думаю может ударить по производительности
А мне так не кажется. В конце концов страницы с формами пытаются всегда сделать как можно меньше, что бы они не пугали юзера. Поэтому я думаю что ничего критического в производительности произойти не должно
Возможно я чего-то не понимаю, но как по мне ничего не изменилось.
В первом случае с методами, мы сетили в стейт значение для каждого элемента отдельно, что в свою очередь перезапускало рендер и перерисовывался элемент, для которого изменилось значение в стейт. Остальные оставались без изменений, то есть перерисовывался 1 элемент.
Во втором случае мы сетим значения со всех элементов вместе. После чего срабатывает рендер и перерисовывается опять таки один элемент в которого изменилось значение в стейте. Для остальных элементов значения которые хранятся в стейте остались прежними и виртуал дом должен их пропустить и не перерисовывать. Получается что перерисуется опять только 1 элемент.
Поправьте меня если ошибаюсь.
Ну во-первых, у нас не 3 компонента, а 1, и в любом случае, каким способом ты не повесь обработчики, метод render у компонента Form будет вызываться каждый раз при изменении любого из полей. Это первое.
Во-вторых, даже если вы замените поля на отдельные компоненты (что вы скорее всего имели в виду), то при вызове setState на компоненте-родителе все render'ы на дочерних компонентах обязательно вызовутся. Так задумано в React изначально. Чтобы не отрисовывать дочерние компоненты, вам нужно в их методе shouldComponentUpdate вернуть false, а это уже другая история и это не зависит от того, будет ли один обработчик для всех полей или будет на каждое поле свой обработчик. Чтобы сэкономить на лишних рендерах, вам нужно в дочерний компонент пробросить через пропсы value, а в методе shouldComponentUpdate сравнить текущий value у пропс, с тем, который прилетит при изменении стейта родителя.
@@stlyak Все правильно сказал про setState, просто ref помогает свести кол-во обработчиков к минимуму но его лучше не использовать где попало тк React это все таки декларативный подход.
+