задача библиотечного кода — не писать один и тот же код дважды

ты же не пишешь реакт с нуля, когда нужно рендерить

фильтр решил задачу реализации - библиотечный, а на самой странице составить его - это уже бизнес код, решение задачи?

я бы сформулировал так:
задача бизнеса — отрисовать определенные фильтры на страницах, потому что определенным пользователям нужны конкретные поля фильтровать
задача библиотеки — позволить собрать ЛЮБОЙ фильтр, на любой странице быстро

Всем привет, у меня возникло недопонимание в импементации atomic design в react проектах и я очень был бы благодарен, если кто-нибудь мне поможет разобраться. Недопонимание заключается в определении смысла двух сущностей atomic design - pages и templates. Я определил template, как компонент, который уже является страницей и принимает свой контент через props, но тогда у меня возникает, как я считаю, слишком завязанное представление о pages на концепциях react и его экосистемы: я думаю о page, как об обертки(умном компоненте, контейнере) для "истинной" страницы(template), которая знает о store, содержит в себе логику и т.д и лишь передает props и callbacks для template. Если вас не затруднит, буду благодарен за ваши объяснения, за ссылки на материалы, которые помогут мне разобраться.

template не явлется страницей. template это комопонент с дырками, может быть для чего угодно, для страниц/ модалок/ форм. Да в целом для чего угодно, зависит от проекта

page это компонент который напрямую рендериться роутером. На практике  page скорее всего будет юзать какой-то темплейт внури себя, но больше эти сущности никак не связаны

И следующие слайды

Спасибо больше вам, Илья, и вам, Сергей, теперь по ощущениям пазлы сошлись и я еще больше люблю atomic design с новым пониманием его, я вам благодарен!

Всем доброе утро. Изучаю данный подход структуры проекта, прошу совета.
Предположим, имеется данный код (приложил скрин). Есть функция withAuthentication, которая оборачивает компонент и редиректит на '/login', если юзер не залогинен и пытается перейти на '/profile'.
Вопрос: куда лучше поместить данную функцию? В src/features/auth, или в src/lib? Имею ввиду, это часть фичи auth или скорее глобальная функция и ей место в lib?

Привет! У меня вопрос такого характера по feature slices
Можно с lib обращаться к SM ?
Если нет, то можно feature/сущность, подключать к другой сущности ?

В фичу

Можно. Но лучше как можно реже

Спасибо!

Спасибо!

Где можно почитать что это за бизнес логика,
как мне разделить логику от бизнес логики...

- если я работаю с СМ это уже бизнес логика ?
- или бизнес логика та которая работает с данными сервака ?

какой кейс у тебя, что тебе нужен стейт менеджер в либ?

вот ___________

Хочу сделать модальное окно, в пример я напишу ниже немного кода как я хочу инкапсулировать.

@ Header.tsx

import { show } from 'modal'

<Button onClick={ show('MODAL-AUTH') } > Открыть </ Button>

@ Auth.tsx

import { hide } from 'modal'
import { Modal } from './ui/modal'

<Modal use='MODAL-AUTH'>
 <Close onClick={ hide('MODAL-AUTH') } />
</Modal>

идея в чем, чтобы я мог гибко управлять модальными окнами с любого места ( show / hide ), не писавши дополнительную логику к примеру

const [show, hide] = useModal => ( ... )

Зачем тебе с разных компонентов открывать модалку?

??