И
Совершенно верно.
То есть запросы к серверу, обработка и хранение данных — всё в контейнерах. А стейт-менеджер куда?
Size: a a a
2020 July 13
DS
То есть запросы к серверу, обработка и хранение данных — всё в контейнерах. А стейт-менеджер куда?
Хочешь добить и поиздеваться что ли?)
И
https://codesandbox.io/s/presentational-and-container-components-q1vid
Попробую с примером.
У нас есть презентационный компонент
Компонент
Можно реализовать два контейнера с говорящими названиями
Мы можем безболезненно для компонента
Попробую с примером.
У нас есть презентационный компонент
App , отвечающий за UI и обработку событий на нём («лямбда-адаптер» в `onChange`).Компонент
App не знает об обработке данных, эту ответственность на себя берёт его родитель.Можно реализовать два контейнера с говорящими названиями
AppWithHooks и AppWithClass, который обрабатывают данные, получаемые от дочернего App.Мы можем безболезненно для компонента
App менять реализацию обработки данных: классы, хуки, редакс, локалсторедж - нас не волнует.
Осталось только понять, зачем
И
Хочешь добить и поиздеваться что ли?)
Не, интересна логика
DT
Опять подходы 2015 года
DT
и опять те же самые обсуждения
DT
пишите как вам удобней, но не забывайте что после вас будут работать еще люди с вашим кодом
И
https://codesandbox.io/s/presentational-and-container-components-q1vid
Попробую с примером.
У нас есть презентационный компонент
Компонент
Можно реализовать два контейнера с говорящими названиями
Мы можем безболезненно для компонента
Попробую с примером.
У нас есть презентационный компонент
App , отвечающий за UI и обработку событий на нём («лямбда-адаптер» в `onChange`).Компонент
App не знает об обработке данных, эту ответственность на себя берёт его родитель.Можно реализовать два контейнера с говорящими названиями
AppWithHooks и AppWithClass, который обрабатывают данные, получаемые от дочернего App.Мы можем безболезненно для компонента
App менять реализацию обработки данных: классы, хуки, редакс, локалсторедж - нас не волнует.Ты намеренно разделил на две части цельный кусок логики, и ввёл пять пропов чтобы что? Чтобы заменить при необходимости источник данных/обработчиков? Компонент, который принимает вот это всё — вообще нихера не переиспользуемый. Хочешь вынести логику для переиспользования? Напиши хук useTodos, меняй внутри реализацию хоть по пять раз за коммит. Разделением логики работы компонента на два «независимых» компонента добьёшься ровным счетом ничего
K
Ты намеренно разделил на две части цельный кусок логики, и ввёл пять пропов чтобы что? Чтобы заменить при необходимости источник данных/обработчиков? Компонент, который принимает вот это всё — вообще нихера не переиспользуемый. Хочешь вынести логику для переиспользования? Напиши хук useTodos, меняй внутри реализацию хоть по пять раз за коммит. Разделением логики работы компонента на два «независимых» компонента добьёшься ровным счетом ничего
иногда удобней работать с разделением, что бы не было кучи кода в 1 файле, вот и вся логика что ты пытаешься понять, просто удобство
И
иногда удобней работать с разделением, что бы не было кучи кода в 1 файле, вот и вся логика что ты пытаешься понять, просто удобство
Ну да. Кастомным хуком решается на ура. Зачем компонент для этого создавать?
DT
никто не против разделения, прямо в документации говорится про это и про примеры кастом хуков
DT
есть еще люди которые выносят всю логику вне реакта, либо большую ее часть
K
Ну да. Кастомным хуком решается на ура. Зачем компонент для этого создавать?
ну если можно обойтись хуком - то нет смысла, я про то когда много кода
И
ну если можно обойтись хуком - то нет смысла, я про то когда много кода
А когда нельзя обойтись хуком?
VO
То есть запросы к серверу, обработка и хранение данных — всё в контейнерах. А стейт-менеджер куда?
Контейнер предоставляет нужные данные и функции презентационному компоненту. Запросы к серверу, обработка и хранение данных могут быть реализованы как прямо в контейнере, так и вынесены «по уму» в разные модули, а контейнер только составляет композицию этих модулей для презентационного компонента.
VO
Ты намеренно разделил на две части цельный кусок логики, и ввёл пять пропов чтобы что? Чтобы заменить при необходимости источник данных/обработчиков? Компонент, который принимает вот это всё — вообще нихера не переиспользуемый. Хочешь вынести логику для переиспользования? Напиши хук useTodos, меняй внутри реализацию хоть по пять раз за коммит. Разделением логики работы компонента на два «независимых» компонента добьёшься ровным счетом ничего
Сейчас перевариваю...
И
Контейнер предоставляет нужные данные и функции презентационному компоненту. Запросы к серверу, обработка и хранение данных могут быть реализованы как прямо в контейнере, так и вынесены «по уму» в разные модули, а контейнер только составляет композицию этих модулей для презентационного компонента.
И зачем это нужно, если можно сделать то же самое кастомным хуком прямо а нужном компоненте? Чтобы описывать «тупые» компоненты, которые принимают три структуры и пять коллбэков? Они точно тупые в таком случае? Они же бессмысленны. А если у тебя нет TS с сигнатурами — так вообще пиздец, поди разбери, что за 5 пропсов принимает «тупой» компонент, как эти пропсы между собой связаны и как друг на друга влияют
H
Подскажите пожалуйста, почему date не заполняется данными
И
Контейнер предоставляет нужные данные и функции презентационному компоненту. Запросы к серверу, обработка и хранение данных могут быть реализованы как прямо в контейнере, так и вынесены «по уму» в разные модули, а контейнер только составляет композицию этих модулей для презентационного компонента.
Задумка хорошая, реализация такая себе
И
Заполняется. Гугли асинхронный сетстейт