Хорошее видео, показывает реализацию DIP в реакте, однако, пример с UserList и UserCard кажется не совсем удачным. В конце было сказано, что "дружные" компоненты могут иметь прямые импорты, а не зависеть от абстракций, это как раз этот случай. Думаю, более правильно было бы показать компонент List, который инкапсулирует в себе всю общую логику, вроде той же пагинации, и в качестве пропсов уже принимает функцию по рендеру каждого элемента, тогда компонент UserList (композиционный, как ты назвал) будет рендерить абстрактный List, передавая функцию, рендерящую конкретное отображение UserCard.
Да, хорошее замечание. Для меня было главное показать, что renderProp это уже реализация DIP и для этого не нужны какие то экзотические конструкции. Но более близкий к жизни пример можно было придумать, правда
Может я не очень понимаю, но в приведенном примере правильного использования в компонент не падает функция renderUser. Она есть в типизации, но в пропсах её нет.
Можем ли мы называть UserCard и UserList компоненты "дружными" и на основании этого делать прямую зависимость UserList от UserCard? Мне кажеться что это зависит от контекста фичи, и в каких-то случаях это действительно может быть проще, а в каких-то нет. Например, когда у нас есть два композиционных "виджета", которые используют UserList, но с разными по логике карточками
Мы компоненты дружными не называем, если они зависят от одного и того же актора, и меняются по одной причине, они являются дружными сами по себе. А вот это уже целиком и полностью зависит от ситуации
Так в итоге же отказались от этого в реакте,раньше писали лождик лайер чтоб интерфейс тупой бил и могли бы его менять как удобно а логика на слоях лежит которые просто пропсы прокидывали в интерфейс , в итоге ушли от этого потому что это офигенный бойлерплет и никому не нужный , все равно интерфейс не меняют )
От DIP не отказались, используем завуалированно, не зная как называется children - dip renderProp - dip createContext - dip connect из redux тоже был dip
Намечается отличная серия роликов, в принципе, как и всё остальное на канале👍🏼Выпускай оставшиеся ролики, хочется быстрее посмотреть практику😄
Хорошее видео, показывает реализацию DIP в реакте, однако, пример с UserList и UserCard кажется не совсем удачным. В конце было сказано, что "дружные" компоненты могут иметь прямые импорты, а не зависеть от абстракций, это как раз этот случай. Думаю, более правильно было бы показать компонент List, который инкапсулирует в себе всю общую логику, вроде той же пагинации, и в качестве пропсов уже принимает функцию по рендеру каждого элемента, тогда компонент UserList (композиционный, как ты назвал) будет рендерить абстрактный List, передавая функцию, рендерящую конкретное отображение UserCard.
Да, хорошее замечание. Для меня было главное показать, что renderProp это уже реализация DIP и для этого не нужны какие то экзотические конструкции.
Но более близкий к жизни пример можно было придумать, правда
Накинул пару дельных мыслей когда рассказывал о применении) Спасибо!
было бы круто после всех принципов и практики по ним сделать серию роликов по FSD
Может я не очень понимаю, но в приведенном примере правильного использования в компонент не падает функция renderUser. Она есть в типизации, но в пропсах её нет.
Круто, спасибт ха отличное объяснение🔥
О, Гриша Петров ❤😊
Можем ли мы называть UserCard и UserList компоненты "дружными" и на основании этого делать прямую зависимость UserList от UserCard? Мне кажеться что это зависит от контекста фичи, и в каких-то случаях это действительно может быть проще, а в каких-то нет. Например, когда у нас есть два композиционных "виджета", которые используют UserList, но с разными по логике карточками
Мы компоненты дружными не называем, если они зависят от одного и того же актора, и меняются по одной причине, они являются дружными сами по себе.
А вот это уже целиком и полностью зависит от ситуации
всегда считал, что зависит "от", а не "на" ... видимо, я что-то пропустил ))
Всё смешалось люди кони (depends on)
Так в итоге же отказались от этого в реакте,раньше писали лождик лайер чтоб интерфейс тупой бил и могли бы его менять как удобно а логика на слоях лежит которые просто пропсы прокидывали в интерфейс , в итоге ушли от этого потому что это офигенный бойлерплет и никому не нужный , все равно интерфейс не меняют )
От DIP не отказались, используем завуалированно, не зная как называется
children - dip
renderProp - dip
createContext - dip
connect из redux тоже был dip
@@paromovevg так createContext сам контекс и тем более коннект уже сто лет как не используют же ))
ничего не понял. лучше на коде примеры показывать чем на карточках