Redux best cases??

Question

[AlexKindGeek]

Всем привет. Активно работаю с React / Redux. Сейчас хотелось бы улучшить архитектуру приложений (больших, Real World) и вообще научиться строить приложения (их архитектуру) с нуля, так что-бы потом стыдно не было))

Возможно есть какие-то достойные внимания (статьи, туториалы, паттерны и т.д)?

Всем большое спасибо за ответы.

Answer 1

[Антон Спирин]

Да много их. Все зависит от размера проекта, количества разработчиков и многих других факторов.
Вот хорошая подборка Дальше уже гуглите, темы которые интересуют.
Почитайте обязательно про ducks pattern, об отличиях File Type First и Feature First подходов к организации структуры.

Comments

[AlexKindGeek]

Артём Петренков, Поэтому я и не люблю сагу и стараюсь не использовать). Санки прекрасно со всем справляются. Тонко и лаконично, а сага для меня пока что остается непонятной кучи кода.

[Антон Спирин]

Артём Петренков, при умелой организации подходы Feature First и File Type First отлично совмещаются. Так же, не вижу ничего плохого в разделении saga и ducks файлов.
Зацикливаться не этом не надо, это хорошо знать.

[Антон Спирин]

Артём Петренков, участвовал в разработке огромной финансовой системы, где себя отлично показал на практике смешанный подход(Feature First + File Type First), как в плане поддерживаемости и масштабируемости так и в плане быстрого onboarding для новых участников команды(15+ фронтов).

Пример

/common
  /api
  /components
  /ducks
  /entities
  /sagas
  /selectors
  /utils
/features
  /Feature1
  /Feature2
  /Feature3
  /Feature4
  ...
  /FeatureN
/Main
  /pages
  index.js
  App.js
  routes.js
  rootReducer.js
  rootSaga.js
  store.js
/Auth
  /pages
  index.js
  App.js
  routes.js
  rootReducer.js
  rootSaga.js
  store.js
...

Папка common тут организована File Type First

Просто тот же ducks pattern — это одна из идей, не следует ей слепо следовать.

Кто-то где-то призывал слепо следовать?

Во всяком случае, отделять логику в сагах от соответствующих ей доменной области считаю глупым, если речь идёт о подходе Feature First.

Я имел ввиду такой пример:

/features
  /Accounts
    /components
    index.js
    accountsDucks.js
    accountsSaga.js
    accountsSelectors.js
    accountsApi.js
    Accounts.js
    AccountsContainer.js

[AlexKindGeek]

Антон Спирин, Довольно сложный и в то же время интересный пример структуризации.
Непонятно только зачем для каждого "компонента" иметь store или же в чём ф-ция этого файла в разных директориях?

[Антон Спирин]

AlexKindGeek, там так реализованы подприложения, отдельные точки входа. Фронтенд клиент это большой dashboard по управлению финансами с определенным количеством страниц, на которых куча сложных виджетов, которые с легкостью должны добавляться, изменяться и заменяться и при этом могут использовать общие сущности. Ну и такая структура очень круто подошла.

[AlexKindGeek]

Антон Спирин, Спасибо. Очень даже вдохновляет на изучения)
Спасибо вам)

[AlexKindGeek]

Антон Спирин, Еще хочу задать 2 вопроса.
1. Можно посмотреть маленький какой-то кусок компонента?
уж очень стало интересно)
2. Используете ли вы lodash / ramda / underscore в проектах??

[Антон Спирин]

Артём Петренков, глупости. Папка common организована File Type First и нет никакой разницы в какой иерархии она расположена. Вы чужие идеи и условности пытаетесь трактовать за абсолют. Его зачастую нет.

[Антон Спирин]

Артём Петренков, common ни в коем разе не является feature, это директория в которой лежит код, который используются во всем приложении, оттуда можно делать импорт куда угодно, в обратном направлении нельзя. Она организована File Type First, хотя можно было бы организовать все несколько иначе. Feature тут самостоятельный модуль, который, может как использовать что-либо из папки common так и нет и с легкостью быть прокинут в приложение или отключен.
Вы, конечно, можете не соглашаться и трактовать как хотите, но рекомендую вам воспользоваться вашим же советом:

это одна из идей, не следует ей слепо следовать