master-7 24 апр 2017 в 16:39

Как сделать жизнь Redux разработчика проще?

2 мин

4.9K

JavaScript*

-1

Комментарии 20

justboris 24 апр 2017 в 16:54

И чем ваше решение лучше старого доброго redux-actions?

НЛО прилетело и опубликовало эту надпись здесь

comerc 25 апр 2017 в 02:17

Есть "гораздо более лучший" вариант — redux-act

xGromMx 24 апр 2017 в 20:03

Как сделать жизнь Redux разработчика проще? Просто не использовать его

kanstantsin 25 апр 2017 в 20:57

Золотые слова. Вспоминаю как страшный сон эти тонны повторяющегося кода. Особенно доставляют константа на константе и спагетти из функций, которые аргументы функций, являющихся аргументами функций и т.д. по схеме. Как будто код какой-нибудь CMS из 2005 года.

xGromMx 25 апр 2017 в 20:58

и на что перешли?)

kanstantsin 25 апр 2017 в 21:03

Пока mobx, пока ок, если подумать над архитектурой прежде, чем начать писать :) Но кода стало меньше, появилось какое-никакое ООП, typescript опять же сильно помогает, уже почти можно жить :)

xGromMx 25 апр 2017 в 21:12

Ну mobx не про ООП =)

kanstantsin 26 апр 2017 в 14:13

mobx нет, но попытки писать в ооп-стиле с redux это пытка.

justboris 26 апр 2017 в 14:27

А зачем обязательно ООП?

Есть и другие способы разбиения проекта на части, о которых написано в документации Redux

raveclassic 26 апр 2017 в 16:10

Правильно, потому что redux совсем не про ооп.

raveclassic 25 апр 2017 в 23:18

Вспоминаю как страшный сон эти тонны повторяющегося кода

А можете пример, что у вас там так повторялось? Быть может, дело в том коде, а не в redux?

Особенно доставляют константа на константе

А что не так с константами?

которые аргументы функций, являющихся аргументами функций и т.д. по схеме

И что не так с ФВП?

kanstantsin 26 апр 2017 в 14:19

Я не хочу вступать в полемику, просто на проекте в ~25k строк кода со значительным кол-вом запросов к api размер, поддерживаемость, читаемость кода начинают иметь особое значение, поэтому отказ от redux оказался верным решением. На простых примерах типа todo все выглядит прилично, но на реальных проектах появляются проблемы. Только личный опыт :)

raveclassic 26 апр 2017 в 16:09

Возможно из-за того, что redux не дает каких-либо внятных рекомендаций по архитектуре сервисного и доменного слоев, предоставляя лишь паттерн для организации внутреннего взаимодействия UI. То, что экшены могут быть thunk'ами или promise'ами — не более чем сильное допущение и упрощение. И когда проект начинает разрастаться, становится понятно, что серьезному IO/эффектам не место ни в редьюсерах, ни в экшенах, ни вообще в redux, так как это не его задача (хоть redux и предоставляет возможность вставки middleware).

Рекомендую посмотреть на redux-saga и redux-observable. Обе решают наболевшую проблему толстых экшенов с кучей копипасты, расширяемости и поддерживаемости. Саги только в качестве бонуса предоставляют тестируемость без каких-либо моков.