Правильно ли я понимаю, что ты предлагаешь совмещать ответственности работы с данными и управления UI в одном компоненте?

эту презентацию я видела, но когда доходит до конкретной реализации, сложно разобраться, какая именно должна быть структура и что куда нужно отнести

В моем представлении - конечно зависит от того, что там происходит и хранится должно...
Я говорю об абстракции, которая скроет деталь реализации - использование лс. При этом эта делать может измениться, и не придется менять везде
Но на самом деле формулируя это только что подумал, что это вообще далеко не везде нужно
Так что имеют место быть и хуки те же, просто надо думать на сколько вероятно, что лс придется на что-то заменить, например

если ты под отвественностью работы с данными понимаешь useSelector/useStore/useSomethingOtherStorage - то да, никаких проблем в этом нет. Как написания ненужного бойлерплейта. При условии построения нормальной архитектуры. а не также как раньше директория components и директория containers и погнали)

я не очень понимаю, вроде говорят, что запросы к апи или локалСтораж из компонента делать напрямую это плохая практика, а зачем тогда куча хуков типа useFetch https://github.com/stevenpersia/captain-hook#usefetch---view-code ?

ну это уже да, продумывать нужно опираясь на требования проекта и его понимание. конкретно вот эта реализация Совы основана на чистой архитектуре и ddd (но про ddd я не помню чтобы Серега говорил, но мне кажется он оттуда почерпнул часть)

Ну, вот вы делаете какой-то прототип, показать заказчику на вчера надо было

Нет времени делать архитектуру, разделяиь слои, и вот это все)

ааа, вот оно чё

ну а еще многие до сих пор не понимают что делать запросы в компонентах плохо))

Доброй ночи, есть ли возможность отображать несколько Popover'ов в одной презентации в material ui?

Структура файлов и папок !== архитектура приложения.
Ответственность работы с данными — запросы к серверу, обработка их результатов и хранение их ответов.
Ответственность управления UI — обработка событий и хранение состояния UI.

не до конца понимаю, что считать фичей, если в приложении есть список покемонов и есть страница одного покемона (ну, например) - list и страница это отдельные фичи? или все, что относится к покемонам в этом приложении - это считается одной фичей?

вот так спасибо за новость) но мы кажется обсуждали это в контексте контейнеров и компонентов, о каких транспортных слоях в них может идти речь?

ну и так то архитектура и про разделение кода тоже если на то пошло

шоб здесь щас не разводить тему Серегиного подхода  - https://t.me/atomicdesign вот чатик собственно тематический, там можно по этой концепции все спрашивать - все объяснят

спасибо, пойду там спрошу

В контейнерах логика про данные, а в презентационных — логика про ui и события? Правильно понимаю?

https://codesandbox.io/s/presentational-and-container-components-q1vid

Попробую с примером.
У нас есть презентационный компонент App , отвечающий за UI и обработку событий на нём («лямбда-адаптер» в `onChange`).
Компонент App не знает об обработке данных, эту ответственность на себя берёт его родитель.

Можно реализовать два контейнера с говорящими названиями AppWithHooks и AppWithClass, который обрабатывают данные, получаемые от дочернего App.

Мы можем безболезненно для компонента App менять реализацию обработки данных: классы, хуки, редакс, локалсторедж - нас не волнует.

Совершенно верно.