ReactCodeSmells: Не зберігайте похідні дані в стейті.
2023 ж. 14 Ақп.
3 112 Рет қаралды
👉 Перший випуск React Code Smells. Говоримо про те чому не потрібно зберігати похідні дані в State та що робити щоб їх не зберігати.
✉️ Telegram: t.me/reactbeginners
❤️ Підтримати канал: opencollective.com/farstar
💡Всі матеріали курсу: github.com/Drag13/react-learn...
Тобто нам не реба юзеффект? Це шикарно! Моє життя нн буде як раніше)😂
Велике дякую за корисний україномовний контент 😎
Інформативно, стисло, зрозуміло. Дякую!
Чекаю з нетерпінням на чергове дуже корисне відео👍
Подивився вже 2 ваших відео, чудово викладений матеріал, гарні приклади. Я б додав, що головна проблема таких зв'язаних станів в тому, що коли змінюємо стан firstName або secondName, то треба також змінювати стан fullName вручну, а інакше fullName буде не актуальним. Є принцип DRY який каже що будь-яка частина інформації в системі має мати тільки одне авторитетне місце. У випадку з fullName і firstName в нас firstName зберігається в системі в 2-х місцях які не зв'язані між собою і не знають один існування один одного, хоч і знаходяться на сусідніх строках коду. Тож похідні стани порушують принцип DRY. Принципи DRY, KISS і YAGNI стоять в основі всього. Весь поганий код через їх порушення.
Дякую!
Здається зрозумів, як виправити всі свої незліченні інпути, дякую. Будуть ще питання пізніше, можливо теж підійдуть для коротенького відео як ідея ;)
Нужно ли всегда использовать обработчик onChange для полей ввода. Я создавал калькулятор в учебном задании и юзал такое, без использования onChange. Я просто меняю состояние, а затем значение ввода также меняется. Это правильный путь? Или я должен всегда использовать onChange всякий раз, когда я работаю с полем ввода?
Є два підходи. Контрольовані інпути (onChange або onBlur + state) або не контрольовані, коли ми взагалі в стейті нічого не зберігаємо, а на сабміті вичитуємо форму. Правильно обидва варіанти, але перший розповсюдженіший
Тільки почала дивитись і хотіла запитати. Є таке правило, що якщо ти не не повинно змінюватись те, на що не впливає юзер, тобто сайдефект якийсь. Це з принципу СОЛІД здається. Так от питання над яким я давно задумалась полягає в тому ,що чи не є порушенням цього правила зберігання даних юзерНейма і імейла наприклад в одному стетйті в об'єкті як у вас. Чи це типу як дані однієї сутності.
Можливо ви говорите про I - interface segregation. Але я звик тримати пов'язані дані разом. Звісно, якщо дані не стосується одне одного тримати їх в одному стейті і не правильно і не зручно
@@reactdev так про нього. Дякую
дякую за короткі відоси, бо дивитись часові щоб взяти щось потрібне че ту мач
Таке питання. Обрахування будуть робитися на кожний рендер, але якщо ці обрахування досить "важкі", то не хотілось би робити їх, якщо перерендер стається з іншої причини, не пов'язаною зі зміною того стану, для якого потрібні ці обрахування.
Мабуть тоді ці обчислення краще зробити в useMemo ?
@@maksymleonidov7059 Так, якщо у вас є дійсно складні обчислення (і ви це поміряли) тоді useMemo або будь-яка інша реалізація мемоізації стане у нагоді
використати юзмемо, а в депенденсі арей вписати стейти імені та прізвища
Перед тим, як використовувати useMemo - потрібно поміряти скільки реального часу він вам зекономить, а потім вже його додавати. (Ну або якщо розмір елементів не обмежений)
Хлопцы получается шё, когда мы меняем значение ввода путем изменения состояния, а затем отправляем событие изменения, тогда React регистрирует как setState, так и событие, считает его повторяющимся событием и потом обрабатывает его?Я правильно вас понял?
Можливо якщо переформулювати питання, на нього буде легше відповісти.