В статье описал, но может быть не так наглядно. Нужно это для того, чтобы при изменении/расширении объекта в сторе нам не пришлось лазить по всем контейнерам, обращающимся к этому куску стора. Мы залезаем в селектор (максимум в парочку селекторов) и меняем путь до пропса там один раз =)
Грубо говоря, есть у нас 5 контейнеров, которые вытаскивают что-то + state.users.data[index].name
Бэк поменял логику и вместо name нам теперь приходит поле с наименованием title. Нам придется лезть во все 5 контейнеров и менять там это имя — не круто. А с селектором так делать не придется — поменял один-два селектора и радуешься жизни
Видимо я забыл в статье упомянуть про то, что thunk для асинхронных экшнов постоянно порождает промис-хелл… Мы делаем экшн для запроса, в котором вызываем другой экшн для следующего запроса, который состоит из еще двух таких же вложенностей — неудобно отлавливать ошибки и выглядит как-то совсем уж неаккуратно, как мне кажется
Вроде звучит неплохо и логично, но как по мне, если я — новый разработчик на проекте, мне куда более привычно видеть папки components, reducers, actions и тд, чем без знаний бизнес-логики проекта лазить по папкам-сущностям. Но это такой себе аргумент в сторону структуры, так что, скорее это вопрос вкуса, нежели какого-то конкретного профита, как я понимаю =)
Если под «глобальный css» подразумевается какой-нибудь styles.css в проекте, в котором прописаны правила под все стили всего проекта, то я бы сказал, что есть бэст практис в программировании — SOLID, у которого аж 2 пункта в нашем случае бьют:
1) Единая ответственность (каждый класс (к примеру) должен отвечать за что-то одно и ни за что другое. В нашем случае — один модуль css должен отвечать за один компонент)
2) Лучше много маленьких модулей, чем один, но унифицированный (отвечающий за кучу всего) — тут думаю, понятно без пояснений.
Не знаю, насколько это притянуто за уши, но СОЛИД распространяется (как я это понимаю) не только на ООП и следовать ему всегда и везде — необязательно (даже где-то противопоказано). Но в совсем простых случаях (как этот, к примеру) можно им руководствоваться, как мне кажется
Ну и как минимум легче искать правило css под конкретный компонент, расположение которого ты, как правило знаешь, рядом с этим компонентом, а не где-то еще…
Грубо говоря, есть у нас 5 контейнеров, которые вытаскивают что-то + state.users.data[index].name
Бэк поменял логику и вместо name нам теперь приходит поле с наименованием title. Нам придется лезть во все 5 контейнеров и менять там это имя — не круто. А с селектором так делать не придется — поменял один-два селектора и радуешься жизни
Это как записывать строки в константы, как бы
1) Единая ответственность (каждый класс (к примеру) должен отвечать за что-то одно и ни за что другое. В нашем случае — один модуль css должен отвечать за один компонент)
2) Лучше много маленьких модулей, чем один, но унифицированный (отвечающий за кучу всего) — тут думаю, понятно без пояснений.
Не знаю, насколько это притянуто за уши, но СОЛИД распространяется (как я это понимаю) не только на ООП и следовать ему всегда и везде — необязательно (даже где-то противопоказано). Но в совсем простых случаях (как этот, к примеру) можно им руководствоваться, как мне кажется
Ну и как минимум легче искать правило css под конкретный компонент, расположение которого ты, как правило знаешь, рядом с этим компонентом, а не где-то еще…