данное видео идеально показывает то, что 'компоненты' в реакте не очень то и похожи на компоненты, а являются обычными функциями, которые возвращают значение
Так можно было бы сказать, если бы понятие "компонент" не было задано самими авторами React Авторы React назвали функцию которая возвращает React.Element компонентом, и всё. То что это просто функция, никто не отменяет
@@paromovevg это вводит в заблуждение разработчиков не только из других сфер, но даже тех же фронтендеров, которые до этого с реактом не работали, можно было использовать такое понятие, как template в видео же показано решение проблемы 'компонентов' в реакте, поскольку в других инструментах это решается гораздо легче, но конечно, само по себе видео хорошо объясняет принцип)
Спасибо за классный обзор DI ! Либо я все сильно упрощаю, либо все реально сильно проще, но как по мне DI - разработка на уровне интерфейсов, а не конкретных реализаций. Получается мы просто создаем интерфейс который компонент А будет использовать, а потом уже любой другой компонент Б должен реализовать этот интерфейс.
Огонь. Быстро и понятно... А... Я на 1.5 скорости послушал... Но всё равно понятно. Такое бы видео полтора года назад, чтобы я мог объяснить коллегам по работе, чем их компонента была плоха
SPA на реакте тот еще глобус с совами) Поймал себя на мысли, что на примерах разбивки компонентов можно объяснять и single responsobility, и Coupling/Cohesion и наверное еще много все умного
По факту да, упрощает связывание абстракций с реализациями Его можно и к inversion of control притянуть, но такой концептуальной мысли я в него не закладывал
При всем желании не могу понять, каким это образом у нас меняется так называемое направление зависимостей. В чём концептуальная разница между кейсами, где наш компонент что-то заимпортил и где он взял это что-то пропсами? Ну да, у нас более универсальный модуль, да мы зависим не от конкретного пропса, а от n-ого пропса, имеющего определённый интерфейс. А где тут стрелочка то поворачивается?
Самая гравная разница, кто является держателем типа. Раньше компонент B теперь компонент А Теперь компонент А меняется только при изменении своих собственных типов
🔄 Зависимость от конкретных реализаций усложняет код и препятствует его повторному использованию. ⬆ Инверсия зависимостей - это инструмент, позволяющий абстрагироваться от реализации и управлять потоками зависимостей. 🔗 Инверсия зависимостей заключается в том, что абстрактный класс зависит от интерфейсов, а конкретные классы реализуют эти интерфейсы. 🛠 Инверсия зависимостей используется для улучшения тестируемости, расширяемости и гибкости кода. 💪 Архитектор должен уметь применять инверсию зависимостей для проектирования надежных и гибких систем.
Предлагаю сделать серию видосов каждый сеньор должен знать. Отличный контент
Поддерживаю!
сделай tutorial по Tiny Invert. очень надо
Ну прям булочка, такой радостный и довольный сидит 🙂
@paromovevg вы б хотя б продемонстрировали как использовать вашу либу с реактом. или это будет следующее видео?
данное видео идеально показывает то, что 'компоненты' в реакте не очень то и похожи на компоненты, а являются обычными функциями, которые возвращают значение
Так можно было бы сказать, если бы понятие "компонент" не было задано самими авторами React
Авторы React назвали функцию которая возвращает React.Element компонентом, и всё. То что это просто функция, никто не отменяет
@@paromovevg это вводит в заблуждение разработчиков не только из других сфер, но даже тех же фронтендеров, которые до этого с реактом не работали, можно было использовать такое понятие, как template
в видео же показано решение проблемы 'компонентов' в реакте, поскольку в других инструментах это решается гораздо легче, но конечно, само по себе видео хорошо объясняет принцип)
@@xyozy8 То что я не особо думал о людях которые не знают React -- правда моя ошибка. Признаю
@@paromovevg🎉
Спасибо за классный обзор DI ! Либо я все сильно упрощаю, либо все реально сильно проще, но как по мне DI - разработка на уровне интерфейсов, а не конкретных реализаций. Получается мы просто создаем интерфейс который компонент А будет использовать, а потом уже любой другой компонент Б должен реализовать этот интерфейс.
Огонь. Быстро и понятно... А... Я на 1.5 скорости послушал... Но всё равно понятно. Такое бы видео полтора года назад, чтобы я мог объяснить коллегам по работе, чем их компонента была плоха
Спасибо, Женя. Только одна просьба, на экране редактора кода масштабируй текст плиз. Раза в 3-4. место же позволяет?
Хотелось бы чуть больше инфы про недостатки применения dependency inversion
Эта библиотека - типа аналог @Autowired в java?
SPA на реакте тот еще глобус с совами)
Поймал себя на мысли, что на примерах разбивки компонентов можно объяснять и single responsobility, и Coupling/Cohesion и наверное еще много все умного
По факту React компонент это функция.
Что и SRP применим к функциям, и вообще все принципы программирования я думаю, никто не спорит
Tiny Invert это же по сути реализация inversion of control container? Слой для связывания абстрактных интерфейсов с их реализациями и доступа к ним
По факту да, упрощает связывание абстракций с реализациями
Его можно и к inversion of control притянуть, но такой концептуальной мысли я в него не закладывал
При всем желании не могу понять, каким это образом у нас меняется так называемое направление зависимостей. В чём концептуальная разница между кейсами, где наш компонент что-то заимпортил и где он взял это что-то пропсами? Ну да, у нас более универсальный модуль, да мы зависим не от конкретного пропса, а от n-ого пропса, имеющего определённый интерфейс. А где тут стрелочка то поворачивается?
Самая гравная разница, кто является держателем типа. Раньше компонент B теперь компонент А
Теперь компонент А меняется только при изменении своих собственных типов
лучший
Нужен пример использования до/после и тд
Интересно, как компонент А зависит от В? А если из А в B будут проброшены пропсы?
Сам факт импорта уже зависимость. Компонент B может быть переименован перенесен, поменять интерфейс или логику. Все приведет к изменениям A
К примеру, если пропсы изменяться в компоненте B, то A надо рефакторить
Спасибо за разбор темы. А в чём отличие от dependency injection?
Dependency injection - это инструмент, который позволяет удобно делать dependency inversion
Мой tiny invert по факту замена dependency injection
покажешь как это реализовать на vue nuxt? )))
Там беда
Но почти всегда спасают слоты с параметрами, те же рендер пропсы
@@paromovevg покажешь расскажешь?)))
🔄 Зависимость от конкретных реализаций усложняет код и препятствует его повторному использованию.
⬆ Инверсия зависимостей - это инструмент, позволяющий абстрагироваться от реализации и управлять потоками зависимостей.
🔗 Инверсия зависимостей заключается в том, что абстрактный класс зависит от интерфейсов, а конкретные классы реализуют эти интерфейсы.
🛠 Инверсия зависимостей используется для улучшения тестируемости, расширяемости и гибкости кода.
💪 Архитектор должен уметь применять инверсию зависимостей для проектирования надежных и гибких систем.
Все сеньоры в сборе?!
Коммент в поддержку
Браво! Отличное объяснение
16:54 Мне же не послышалось? 😂
какой ты умничка. заметил, что человек оговорился
молодец
Оказывается это так просто, а то некоторые типы так загоняют.. походу сами не понимат))
Первый ❤
умничка, есть повод для гордости
@@kitsunaana9783 ага, стал лучше понимать dependency inversion
Лайкосиков этому господину!