Comments 62
А поясните, пожалуйста, знающие люди, чем конкретно подход вынесения CSS по компонентам лучше глобального CSS?
Просто я не совсем понимаю зачем размазывать стили?
1) Единая ответственность (каждый класс (к примеру) должен отвечать за что-то одно и ни за что другое. В нашем случае — один модуль css должен отвечать за один компонент)
2) Лучше много маленьких модулей, чем один, но унифицированный (отвечающий за кучу всего) — тут думаю, понятно без пояснений.
Не знаю, насколько это притянуто за уши, но СОЛИД распространяется (как я это понимаю) не только на ООП и следовать ему всегда и везде — необязательно (даже где-то противопоказано). Но в совсем простых случаях (как этот, к примеру) можно им руководствоваться, как мне кажется
Ну и как минимум легче искать правило css под конкретный компонент, расположение которого ты, как правило знаешь, рядом с этим компонентом, а не где-то еще…
Я бы вас и близко к проекту не подпустил с таким восторженным образом мыслей. Уж простите.
В идеале, стиль компонента композируется из имеющихся в проекте базовых классов. Если тебе их не хватает, то либо ты плохо с ними знаком, либо дизайнер что-то мудрит, либо проекту действительно не хватает каких-то базовых классов, но тогда они вводятся по итогам согласования.
Мой главный поинт: СОЛИД — это хорошо, но руководствоваться нужно в первую очередь здравым смыслом, а уже потом солидом)
Например у вас все кнопки синие, но одна — красная. Пока она такая красная одна — её цвет хранится с компонентом, а всё остальное от глобальных стилей.
Или ещё пример: все картинки у вас квадратные (глобальный стиль), но изображение в углу одно (компонент лого, background-image: url), а в середине другое (фото котика).
Бывают стили настолько специфические, что нет смысла сорить ими в глобал.
Лучше тем, что намного легче избегать коллизии названий классов, идентификаторов, анимаций и т.п… В глобальном CSS нужно внимательно следить за названиями или использовать всякие БЭМы, а в CSS-модулях можно писать любые названия и не беспокоиться.
Советую ещё попробовать redux-symbiote, эта библиотека позволяет писать названия экшенов, фабрики экшенов и соответствующие редьюсеры в одном файле, что очень удобно. Я реализовал с нуля один проект как раз на описанном стеке + redux-symbiote, проблем не было.
На всякий случай: название экшена можно получить так:
actions.actionFunc.toString();А в саге можно написать так:
take(actions.actionFunc, handlerFunc);
Да, если в проекте только простые круд операции, то смысла нет тянуть сагу или другие продвинутые библиотеки, хватит и thunk. Есть множество кейсов где thunk не справляется, например, сокеты, синхронизация между вкладками, throttle и debounce саг и т.д. Саги позволяют элегантно решать проблемы с сайд эффектами.
Поэтому у меня вопрос, касательно этого пункта:
Хочется вынести логику запросов и работы с данными для запросов в отдельный модуль — для этого и нужны сагиЭто легко делается вообще без каких-либо библиотек. Это redux настолько ущербный, что для нормального вынесения логики работы с данными запросов к нему нужны отдельные библиотеки? Или просто все смотрят, что другие берут thunk и saga и также бездумно тянут их в свой проект? Или же в этих библиотеках что-то есть такого, что делает код проще/лучше, чем код тех, кто redux не использует?
Это redux настолько ущербный
Вообще то да, ущербный это ещё мягко сказано, он убогий, это ближе к истине)
Но у нас народ любит садомазо, поэтому redux и его зоопарк все ещё используют на проектах, увы и ах. А ещё некоторые используют голый реакт и его стейт менеджмент(он тоже убожество). Вообщем и смешно и плакать хочется. React годится только как view, а управление состоянием должно быть другое. Но если ты хочешь почувствовать боль и отвращение от разработки, то бери redux и его зоопарк, он слихвой доставит тебе эти ощущения =)
Это легко делается вообще без каких-либо библиотек
Именно, но опять же, садомазо и легко, вещи не совместимые, так что увы))
codesandbox.io/s/restless-sound-hvtiw?file=/src/App.tsx — Redux
codesandbox.io/s/hungry-brook-69sb9?file=/src/App.tsx — MobX
Если после этого останутся сомнения в убогости Redux'a, и он вам по прежнему будет нравится, то уж извините)
Как бы getters/setter уже больше 10ти лет, ES6 Proxy 5 лет, а люди до сих пор кроме Redux'a (максимально топорный и примитивный, все делается руками и с тоннами быдло кода) ничего не знают и знать не хотят. Ало, может пора выйти из каменного века, это уже даже не смешно.
А как в MobX сделать нормализованный стэйт? Останется преимущество над redux?
Вот:
codesandbox.io/s/keen-snowflake-reg7r?file=/src/App.tsx
Или же вот такой вариант, по красоте с реактивным классом для переиспользования
codesandbox.io/s/interesting-chatelet-k1yq7?file=/src/App.tsx
codesandbox.io/s/keen-snowflake-reg7r?file=/src/App.tsx:1224-1232
codesandbox.io/s/zen-tharp-eymiv
Ну вот я использую голый реакт и получается даже более удобно чем с mobx, вот пример — https://codesandbox.io/s/competent-engelbart-cltwg. Нет никакой магии геттеров-сеттеров или прокси-объектов, просто вызываем функцию актуализации когда нужно актуализировать view с состоянием. Есть и недостаток в виде менее эффективного обновления (реакт будет делать diff всего приложения при изменении состояния). Но тормоза появляются лишь на больших приложениях (> 10к дом-нод) что встречается нечасто и для 99% mvp-приложений можно обойтись без mobx (и потом можно легко подключить его только в случае появления тормозов diff-механизма реакта).
Просто изменил переменную и всё, любым способом и из любого места. Кому надо, тот отреагирует и перерендерится автоматически без явных вызовов дополнительных. Причем это стало возможно ~10 лет назад, с появлением getters/setters.
Просто изменил переменную и всё, любым способом и из любого места
Это и есть главная проблема MobX. Если Вы работали на хоть сколько то больших проектах, особенно если приходилось бы вникать в код, оставленный в наследство на MobX, Вы бы с уважением отнеслись к Redux.
То, что Вы назвали быдлокодом, всего лишь способ вести проект в строгом соответствии с правилами. Может, TypeScript тоже быдлокод?
перерендерится автоматически без явных вызовов дополнительных
В ту же кассу. Явное лучше неявного.
Если Вы это оспариваете, то флаг Вам в руки
По моему опыту в 90% случаев это типовые CRUD операции. Которые можно сделать например вот такими либами github.com/tannerlinsley/react-query
Запросы на хуках до первого раза, когда два разных компонента используют данные одного и того же запроса. И тогда приходится выносить запрос в общего родителя, если есть, прокидывая результат вниз по дереву.
Если приложение не простейший todo list, вы в первые же дни столкнётесь с кучей подводных камней, которые не решаются своими хуками на фетчах.
+1 за react-query с первого дня.
Шел 2020 год, а люди до сих пор не знают что такое MobX и продолжают использовать допотопные, примитивные и ущербные технологии в виде redux и прочей ереси типо санок, саг, реселектов и тому подобное. 2014 год так и не хотите искоренять из себя. Больно смотреть на общий уровень разработки конечно.
Объясните, зачем для получения каждого пропса используется createSelector? Его использование полезно, если мы как-то модифицируем входные данные — создаём новые массивы, объекты. Почему бы для простого получения пропала не использовать обычные функции?
Грубо говоря, есть у нас 5 контейнеров, которые вытаскивают что-то + state.users.data[index].name
Бэк поменял логику и вместо name нам теперь приходит поле с наименованием title. Нам придется лезть во все 5 контейнеров и менять там это имя — не круто. А с селектором так делать не придется — поменял один-два селектора и радуешься жизни
Это как записывать строки в константы, как бы
const getUsers = (state) => state.users
const getUser = (state, index) => getUsers(state).data[index]
const getUserName = (state, index) => getUser(state, index).name
Я так понимаю, смысл в том, чтобы в последней функции поменять name, на title, например. Все что будет приходить в контейнеры не поменяется.
Я примерно тоже к такому же пришел. Саги невероятно удобная вещь. Она легко читается и контролируется. Единственный минус это то что при таком подходе оочень долго пишешь, но она окупается в долгосрочной перспективе. Еще приплюсуй typescript и вообще будет смак
В 2010 году нам дали getters/setter и всё, с тех пор можно писать и использовать по настоящему крутые стейт менеджеры с автоматической подпиской/отпиской и автоматическим вызове реакций на изменения, в 2016 году нам дали ES6 Proxy, так это вообще просто бомбически и ограничения которые были в getters/setters исчезли и жить стало ещё лучше, но нет же, это не наш путь, наш путь это мазохизм, допотопные и топорные «технологии», где все надо делать ручкам и писать при этом тонны однообразного быдло кода, который автоматически сразу же устаревает и подлежит переписыванию с нуля.
Хотя может быть я чего-то не понимаю и писать код в 2020 году так же, как его писали в 2014 году это круто.
И тут дело не в моде, а в здравом смысле и в колосальном удобстве, я использую MobX с начала 2016 года. Так что это не какая-то новая фигня, ради новой фигни.
Вот примеры быстро взглянуть и оценить суть:
codesandbox.io/s/restless-sound-hvtiw?file=/src/App.tsx — Redux
codesandbox.io/s/hungry-brook-69sb9?file=/src/App.tsx — MobX
Тут расширенный набор всяких штук
codesandbox.io/s/suspicious-water-5wwnz
Нету ни одного кейса в котором Redux или голый React(кроме тупой верстки полностью без логики и состояния) был бы лучше чем MobX, ну реально ни одного.
Архитектура приложения React Redux