Привіт, дякую за відео, дуже корисне! У мене є питання, чому ти тут не використав "рендер пропс"? Якщо його використовувати, ми дамо більше свободи між дефолтним станом і кастомним.
Дякую! Дуже доречне питання! Ти прав, те саме можна зробити і через render props. Є 3 способа: передавати сам компонент, готовий елемент, та render prop. Останній спосіб працює краще коли host component (VideoPreview у моєму прикладі) має мати можливість змінювати поведінку компоненту, який йому передали у пропси, використовуючи для цього свій стейт (тобто передавати свій стейт як інпут у render prop функцію). У моєму випадку це не дуже потрібно, але я думаю що торкнусь цього питання у відео про ISP.
Треба ще не забувати рекомендацію реакту, для логіки яка повинна бути тільки в середині компонента - Hook names always start with use. Звичайно це робота для лінтера і в цьому прикладі такого немає, але десь може запутати)
Привіт, як на мене, то передавати все в пропси стає трохи незручно. Я б, наприклад, хотів мати на рівні аплікації щось типу такого: const App = ({}) => (
); Чому саме так? Тому, що дуже ймовірно, що нам знадобиться передавати додкові налаштування до VideoPreviewImage та/або до (Stream|Video)Description, і тоді у випадку з описаним підходом мені доведеться, або створювати зайві обгортки для компонентів PreviewImage/Description, або прокидати пропси до цих компонентів через VideoPreview, що вже буде дуже сильно порушвати SRP. Чи ідеальний такий спосіб, як я описав. Ні, неідеальний, через те, що він потребує використання контексту, але з точки зору зручності подальшого розвитку та і використання -- це найбільш зручний варіант. ну і, маленьке зауваження, щодо неймінгу. Навіть, якщо хука передається через пропси, то краще, щоб її назва все одно починалося з "use", це дозволить лінтеру без додаткових налаштувань відстежувати незмінність порядку виклику хуків.
Дякую! Передавати все через children нажаль не завжди можливо, тому що хост компонент може додавати своі обгортки та лейаут. Якщо так можна зробити, то children звичайно краще, бо дозволяє декларативно кастомізувати контент, як у вашому прикладі. Про лінтер не знав, це дуже доречно, дякую!
@@dimitro.cardellini, мушу сказазати мені теж такий варінт був більше довподоби і я навіть переписав початковий варіант на slot-props + context. Але чи то при slot-props, чи при children виникають проблеми, коли доводиться звертатися до ISP (а це прийдеться зробити, бо як @AleksandrSugak правильно пояснює, ми компоненти на кшталт VideoPreviewImage без ISP не перевикористаємо). Тобто в результаті все одно доведеться або написати вреппер який буде прокидати потрібні пропси з контексту в умовний VideoPreviewImage, або знов ж таки використати render props. Тобто виглядає так, що render props це все одно найбільш зручний і гнучкий варіант коли мова йде про reusability UI компонентів.
![У нас є такі ж сигнали вдома [fine-grained reactivity та react]](/img/1.gif)
Дякую! Успіхів
Дуже доречний приклад
Гарна аналогія з імютабл даними, сам до такого не дійшов 😅
Крутяк! Дякую!
❤
Щиро дякую за відео! Також не мало корисної інформації в коментарях.
Так, в коментарях познається істина :), дякую!
можете будь ласка додавати посилання на код. дуже дякую
Привіт, дякую за відео, дуже корисне! У мене є питання, чому ти тут не використав "рендер пропс"?
Якщо його використовувати, ми дамо більше свободи між дефолтним станом і кастомним.
Дякую! Дуже доречне питання! Ти прав, те саме можна зробити і через render props. Є 3 способа: передавати сам компонент, готовий елемент, та render prop. Останній спосіб працює краще коли host component (VideoPreview у моєму прикладі) має мати можливість змінювати поведінку компоненту, який йому передали у пропси, використовуючи для цього свій стейт (тобто передавати свій стейт як інпут у render prop функцію). У моєму випадку це не дуже потрібно, але я думаю що торкнусь цього питання у відео про ISP.
Треба ще не забувати рекомендацію реакту, для логіки яка повинна бути тільки в середині компонента - Hook names always start with use.
Звичайно це робота для лінтера і в цьому прикладі такого немає, але десь може запутати)
Дякую, так, в наступних відео я здається виправив це.
Привіт,
як на мене, то передавати все в пропси стає трохи незручно.
Я б, наприклад, хотів мати на рівні аплікації щось типу такого:
const App = ({}) => (
);
Чому саме так? Тому, що дуже ймовірно, що нам знадобиться передавати додкові налаштування до VideoPreviewImage та/або до (Stream|Video)Description, і тоді у випадку з описаним підходом мені доведеться, або створювати зайві обгортки для компонентів PreviewImage/Description, або прокидати пропси до цих компонентів через VideoPreview, що вже буде дуже сильно порушвати SRP.
Чи ідеальний такий спосіб, як я описав. Ні, неідеальний, через те, що він потребує використання контексту, але з точки зору зручності подальшого розвитку та і використання -- це найбільш зручний варіант.
ну і, маленьке зауваження, щодо неймінгу. Навіть, якщо хука передається через пропси, то краще, щоб її назва все одно починалося з "use", це дозволить лінтеру без додаткових налаштувань відстежувати незмінність порядку виклику хуків.
Дякую! Передавати все через children нажаль не завжди можливо, тому що хост компонент може додавати своі обгортки та лейаут. Якщо так можна зробити, то children звичайно краще, бо дозволяє декларативно кастомізувати контент, як у вашому прикладі. Про лінтер не знав, це дуже доречно, дякую!
@@AleksandrSugak так, тоді можна використовувати slot-porops, тобто пропси з react-елементами:
@@dimitro.cardellini, мушу сказазати мені теж такий варінт був більше довподоби і я навіть переписав початковий варіант на slot-props + context. Але чи то при slot-props, чи при children виникають проблеми, коли доводиться звертатися до ISP (а це прийдеться зробити, бо як @AleksandrSugak правильно пояснює, ми компоненти на кшталт VideoPreviewImage без ISP не перевикористаємо). Тобто в результаті все одно доведеться або написати вреппер який буде прокидати потрібні пропси з контексту в умовний VideoPreviewImage, або знов ж таки використати render props. Тобто виглядає так, що render props це все одно найбільш зручний і гнучкий варіант коли мова йде про reusability UI компонентів.