TGLIST.COM.UA
"One React mistake that's slowing you down
"Натрапив на цікавий пост про проектування API компнентів. Часто бувають ситуації, коли необхідні дані для компонента знаходяться десь вгорі по ієрархії компонентів. Й для того, щоб передати щось вниз, дані мають пройти декілька слоїв. Що з цим роботи?Давайте здалеку.
Це одна із проблем, яка виникає, коли ви працюєте з React. Насправді, така проблема виникає в принципі в програмуванні. Наприклад, коли нам необхідно передати колбек в функцію, й нам потрібен доступ до стейту(змінних), то нам допомогають замикання. Якщо ж замикання не підтримуються мовою (Java чи інше), то ми тут можна обрати інше рішення:1. Міняти API колбека, щоб він приймав стейт зовні й передавати його від викликаючої функції. В React це схоже на випадок, коли ми передаєм пропси через дерево компонентів. 2. Зберігати стейт в глобальних змінних. В React це схоже на випадок з контекстом.3. Інкапсулювати стейт в ООП-ному об'єкті й передавати об'єкт з внутрішнім стейтом й зробити метод call/execute/run/handle/whatever. Й це буде аналог замикання. Навіть є такий патерн - "команда", або функтори (ті, що callable objects) в Python. В React це схоже на передачу children.4. ІншеЩо обрати? Як кажуть - "it depends". Автор статті радить передавати children й, в контексті його прикладу з лейаутом, я з ним згоден. Але завжди зважуйте на свій конкретний випадок. Загальна ідея, коли ви проектуєте API React компонента така сама, як й проектування будь-якого іншого API. API компонента залежить від його відповідальності. Припустимо, що у нас є TweetsFeed й всередені є дві колонки твітів. Ієрархія може виглядята так:TweetsFeed => RightContent => TweetDetails Це не відповідальність RightContent зібрати дані для якогось TweetDetails, який ми вирішили розмістити з правого боку, але й можливо це й не відповідальність TweetDetails збирати дані (оскільки він тільки візуалізує). Тоді можна зробити врапер навколо TweetDetails, який вятигне дані, але можливо взагалі відповідальність всього TweetsFeed тільки в візуалізації й ніхто в TweetsFeed не має тягнути дані зовні самостійно. Всі ці "можливо" це про відповідальність компонента й коли ми проектуємо, ми спочатку думаємо про відповідальність компонента, а потім вже думаємо про API й як передати дані.СТАТТЯ: https://epicreact.dev/one-react-mistake-thats-slowing-you-down/
"Натрапив на цікавий пост про проектування API компнентів. Часто бувають ситуації, коли необхідні дані для компонента знаходяться десь вгорі по ієрархії компонентів. Й для того, щоб передати щось вниз, дані мають пройти декілька слоїв. Що з цим роботи?Давайте здалеку.
Це одна із проблем, яка виникає, коли ви працюєте з React. Насправді, така проблема виникає в принципі в програмуванні. Наприклад, коли нам необхідно передати колбек в функцію, й нам потрібен доступ до стейту(змінних), то нам допомогають замикання. Якщо ж замикання не підтримуються мовою (Java чи інше), то ми тут можна обрати інше рішення:1. Міняти API колбека, щоб він приймав стейт зовні й передавати його від викликаючої функції. В React це схоже на випадок, коли ми передаєм пропси через дерево компонентів. 2. Зберігати стейт в глобальних змінних. В React це схоже на випадок з контекстом.3. Інкапсулювати стейт в ООП-ному об'єкті й передавати об'єкт з внутрішнім стейтом й зробити метод call/execute/run/handle/whatever. Й це буде аналог замикання. Навіть є такий патерн - "команда", або функтори (ті, що callable objects) в Python. В React це схоже на передачу children.4. ІншеЩо обрати? Як кажуть - "it depends". Автор статті радить передавати children й, в контексті його прикладу з лейаутом, я з ним згоден. Але завжди зважуйте на свій конкретний випадок. Загальна ідея, коли ви проектуєте API React компонента така сама, як й проектування будь-якого іншого API. API компонента залежить від його відповідальності. Припустимо, що у нас є TweetsFeed й всередені є дві колонки твітів. Ієрархія може виглядята так:TweetsFeed => RightContent => TweetDetails Це не відповідальність RightContent зібрати дані для якогось TweetDetails, який ми вирішили розмістити з правого боку, але й можливо це й не відповідальність TweetDetails збирати дані (оскільки він тільки візуалізує). Тоді можна зробити врапер навколо TweetDetails, який вятигне дані, але можливо взагалі відповідальність всього TweetsFeed тільки в візуалізації й ніхто в TweetsFeed не має тягнути дані зовні самостійно. Всі ці "можливо" це про відповідальність компонента й коли ми проектуємо, ми спочатку думаємо про відповідальність компонента, а потім вже думаємо про API й як передати дані.СТАТТЯ: https://epicreact.dev/one-react-mistake-thats-slowing-you-down/
