Comments 12
Вы создали паттерн Container/Presenter, который был придуман Дэном Абрамовым. Но похвально, что вы дошли до этого самостоятельно!
Тоже выделяю Pages отдельно, но по другому принципу. Для меня это просто самый родительский компонент, все. Не важно что он использует, просто точка входа. У вас написано, что типа в нем надо юзать переменные которые используются для страницы, например параметры из урл. Но, что если этот параметр по сути нужен будет там где то глубоко? Будите прокидывать его по дереву компонентов через пропсы?
Да, я тоже, как правило, использую Pages как точку входа. Как правило, беру только параметры из url и, возможно, какие нибудь закешированные свойства, чтобы передать их в контейнер дальше, который в свою очередь уже и получает все необходимые данные и показывает их.
Если взять пример из статьи, то мы можем увидеть, что контейнер получает на вход
export type ProductListContainerProps = {
type: string;
limit: number;
page: number;
};И да, мы можем это получать сразу в контейнере, точно так же как и получаем это в Pages.
Но тут сразу возникает вопрос.
Вот мы в контейнере (или где-то дальше) используем useParams (из react-router-dom) чтобы получить параметры из url. Получается этот контейнер становится привязанным к конкретному типу url с конкретным параметром и не может использовать в других случаях. Если вас это удовлетворяет, то пожалуйста, но как будто мы, в каких-то случаях, можем потерять переиспользуемость.
Отвечая на ваш вопрос. Мне сложно представить такой пример, где это будет прям большой проблемой. Я с таким не сталкивался. Но если там прям какая-то очень длинная цепочка из контейнеров, то любые варианты подойдут. И объявить контекст, с созданием хука для удобной работы с ним, и прокидывать через пропсы, и прям из контейнера обращаться к этим url-параметрам или чему либо. Для этого контейнеры и нужны в моем представлении.
Но опять же. Если мы создаем длинную цепочку контейнеров то почему мы не должны на каждом этапе прокидывать туда эти пропсы, если они там нужны. Просто контейнеры это тоже не прям "мусорный бак" в котором всё подряд нужно объявлять. Как будто их тоже нужно разбивать на какие-то логические блоки и передавать в них и объявлять в них только то что нужно конкретно ему.. а если вы передает то, что нужно только для того, чтобы передать это дальше.. то возможно вы где-то уже ошиблись раньше.. и стоит, например, передавать внутренний контейнер через пропсы тоже, чтобы один конейнер не зависил от другого.. не уверен, но как будто бы так..
В общем вопрос интересный, к сожалению я не имею прям на него ответа, как поступить лучше в такой ситуации.. Будет о чем подумать) Если есть идеи, то пишите конечно)
В таком случае я думаю вас заинтересует FSD методология. Очень похоже на то что у вас, но с несколько другой декомпозицией.
https://feature-sliced.design/ru/docs
Возможно там вы найдете ответы на вопросы которые ещё не успели у вас появится или почувствуете в развитии методологии.
Кстати говоря не особо понял смысл заворачивать расчет цены в хук с мемоизацией. Имхо затраты на мемоизацию дороже расчета.
Если говорить о мемоизации стора чтобы избежать грязных рендеров или общей мемоизации я больше склоняюсь к reselect Имхо это проще для массовой мемоизации чтобы не возится с правилами мемоизации или прописыванием кучи чистых функции
Спасибо за FSD, почитаю.
Кстати говоря не особо понял смысл заворачивать расчет цены в хук с мемоизацией. Имхо затраты на мемоизацию дороже расчета.
Да, вполне возможно вы правы, я, к сожалению, еще не спец в этом.
Если говорить о мемоизации стора чтобы избежать грязных рендеров или общей мемоизации я больше склоняюсь к reselect Имхо это проще для массовой мемоизации чтобы не возится с правилами мемоизации или прописыванием кучи чистых функции
Чистые функции (хуки) обязательны только в чистых компонентах. И в них не допускается, по моему принципу, использование чего либо из вне. То есть все данные получаются через пропсы и там не важно через что сделан глобальный стейт и как вообще всё там устроено. Там может быть mobx, redux, контексты или еще что либо, на работу чистого компонента это никак не должно влиять.
За reselect спасибо, попробую.
))) Абсолютно правильные выводы!!! В плане того, что "учителям конкуренты не нужны"! Никто не будет делиться с вами секретами и " короткими путями"!!! Я почти год работаю Программистом (Frontend) За первые 3 месяца я понял почему разработчик без опыта нафиг не нужен!! Только практика поможет самостоятельно найти правильные пути и подходы. ....Ну и конечно книги. Грамотных видосов крайне мало. И далеко не всегда там "самые правильные подходы". Только собственный опыт и эксперименты. Пример: однажды мне понадобилось динамически изменить цвет svg... погуглив, и ознакомившись со stackoverflow, я нашел несколько вариантов решений... но предчувствие КРИЧАЛО - решения отстой!!! стал копать дальше... В итоге, код svgШки засовываю прямо в компонент, а цвет (свойство fill) задаю переменной из CSS )))) То, о чем вы поведали в этой статье, мне преподавали в корпоративном университете сбера год назад. Успеха вам в учëбе!)
Вот и пришло то время, когда пишем Frontend, подразумеваем React.
"Партия - ум, честь и совесть". Эх ...
Столкнулся с проектом, в котором разделение кода построенно таким образом, как описано в этой статье. Разделять и декомпозировать код, это правильный подход. Но я стал подмечать что этот подход не для всех понятен. В коде я увидел много лишних оберток и на вопрос зачем тут это нужно я услышал, что "так делают на проектах" . Как разработчик я не могу принять этот ответ в качестве аргумента. Любая созданная обёртка, лейаут или компонент, это в первую очередь функция со своим лексическим окружением и подкапотной логикой (реакта) кеширования и проверки пропсов на изменение для последующего перерендера. Я думаю что, создание лишних оберток, в теории, может ухудшить производительность аппки.
Frontend. Чистые и грязные компоненты