ReactCodeSmells: Не зберігайте похідні дані в стейті.
ฝัง
- เผยแพร่เมื่อ 15 ก.ย. 2024
- 👉 Перший випуск React Code Smells. Говоримо про те чому не потрібно зберігати похідні дані в State та що робити щоб їх не зберігати.
✉️ Telegram: t.me/reactbegi...
❤️ Підтримати канал: opencollective...
💡Всі матеріали курсу: github.com/Dra....
Тобто нам не реба юзеффект? Це шикарно! Моє життя нн буде як раніше)😂
Інформативно, стисло, зрозуміло. Дякую!
Велике дякую за корисний україномовний контент 😎
Чекаю з нетерпінням на чергове дуже корисне відео👍
Подивився вже 2 ваших відео, чудово викладений матеріал, гарні приклади.
Я б додав, що головна проблема таких зв'язаних станів в тому, що коли змінюємо стан firstName або secondName, то треба також змінювати стан fullName вручну, а інакше fullName буде не актуальним.
Є принцип DRY який каже що будь-яка частина інформації в системі має мати тільки одне авторитетне місце. У випадку з fullName і firstName в нас firstName зберігається в системі в 2-х місцях які не зв'язані між собою і не знають один існування один одного, хоч і знаходяться на сусідніх строках коду. Тож похідні стани порушують принцип DRY. Принципи DRY, KISS і YAGNI стоять в основі всього. Весь поганий код через їх порушення.
Дякую!
Здається зрозумів, як виправити всі свої незліченні інпути, дякую. Будуть ще питання пізніше, можливо теж підійдуть для коротенького відео як ідея ;)
Таке питання. Обрахування будуть робитися на кожний рендер, але якщо ці обрахування досить "важкі", то не хотілось би робити їх, якщо перерендер стається з іншої причини, не пов'язаною зі зміною того стану, для якого потрібні ці обрахування.
Мабуть тоді ці обчислення краще зробити в useMemo ?
@@maksymleonidov7059 Так, якщо у вас є дійсно складні обчислення (і ви це поміряли) тоді useMemo або будь-яка інша реалізація мемоізації стане у нагоді
Тільки почала дивитись і хотіла запитати. Є таке правило, що якщо ти не не повинно змінюватись те, на що не впливає юзер, тобто сайдефект якийсь. Це з принципу СОЛІД здається. Так от питання над яким я давно задумалась полягає в тому ,що чи не є порушенням цього правила зберігання даних юзерНейма і імейла наприклад в одному стетйті в об'єкті як у вас. Чи це типу як дані однієї сутності.
Можливо ви говорите про I - interface segregation. Але я звик тримати пов'язані дані разом. Звісно, якщо дані не стосується одне одного тримати їх в одному стейті і не правильно і не зручно
@@reactdev так про нього. Дякую
дякую за короткі відоси, бо дивитись часові щоб взяти щось потрібне че ту мач
Нужно ли всегда использовать обработчик onChange для полей ввода. Я создавал калькулятор в учебном задании и юзал такое, без использования onChange. Я просто меняю состояние, а затем значение ввода также меняется. Это правильный путь? Или я должен всегда использовать onChange всякий раз, когда я работаю с полем ввода?
Є два підходи. Контрольовані інпути (onChange або onBlur + state) або не контрольовані, коли ми взагалі в стейті нічого не зберігаємо, а на сабміті вичитуємо форму. Правильно обидва варіанти, але перший розповсюдженіший
використати юзмемо, а в депенденсі арей вписати стейти імені та прізвища
Перед тим, як використовувати useMemo - потрібно поміряти скільки реального часу він вам зекономить, а потім вже його додавати. (Ну або якщо розмір елементів не обмежений)
Хлопцы получается шё, когда мы меняем значение ввода путем изменения состояния, а затем отправляем событие изменения, тогда React регистрирует как setState, так и событие, считает его повторяющимся событием и потом обрабатывает его?Я правильно вас понял?
Можливо якщо переформулювати питання, на нього буде легше відповісти.