Comments 4
Что насчет FSD архитектуры?
Хороший вопрос.
Все примеры FSD, с которыми я сталкивался, как правило, хорошо организованы, и простые правила помогают поддерживать кодовую базу в порядке.
FSD хорошо удовлетворяет условию упорядочивания кода.
Но не решает проблему с быстрой обратной связью и полным разделением бизнес-логики и презентации.
Кажется, что FSD это не альтернатива ни одной из архитектурных паттернов, главной целью которых разделить ответственность логики. FSD - это про правильное упорядочивание кода по фичам. Поэтому я могу себе представить как Flux + FSD, так и MVU + FSD и т.д.
Часто слышу про то, что вью не должно знать про модель, а модель про вью. Почему? Ладно, модели там побоку, как там ее отрисуют, соглы. Но вью должно знать про модель, ему нужно знать какие данные отрисовать. В примере MVC в чем проблема запихнуть модель во вью, зачем нужен этот преловутый контроллер, который по сути ничего не делает?
Да, может показаться, что отделение представления от модели - это усложнение. И да, представление часто напрямую отражает модель данных, так почему бы не сохранить их тесно связанными?
Если модель жестко привязана к вью, то каждый раз, когда меняется модель, приходится менять и вью. Как раз то, чего хочется избежать. Между этими частями приложения должен быть необходимый и достаточный контракт.
Вместо прокидывания пропа "стоимость продукта", лучше отязаться от бизнес логики и назвать такой проп в контракте "value", так что если нужно будет не стоимость продукта показывать, а скажем скидку, то ничего не надо будет менять. Таким образом, пока изменения модели по-прежнему привязаны к этому контракту, мы можем забыть о представлении и не трогать его.
В больших React приложениях бывает заметно, насколько сложно бывает менять модель и потом менять целый каскад компонентов.
Как сделать UI тестируемым и легкоизменяемым?