Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 6
Тут не вполне корректно противопоставляются Knockout и redux. Да, у Knockout есть свои проблемы — но они никак не связаны с UDF. При желании, построить UDF можно как на Knockout, так и на redux, и это будет одинаково просто. А при отсутствии такого желания — можно и там и там все запутать…
Например, можно попробовать вызывать dispatch из редусеров, потом гадать куда пропал такой хороший UDF :-)
Например, можно попробовать вызывать dispatch из редусеров, потом гадать куда пропал такой хороший UDF :-)
1. Противопоставляется реактивный стиль программирования и чистый код
2. Да, даже подскажу как, весь стейт приложения в одном observable, меняем его только чистой функцией, в разметке никаких двусторонних байндингов, вуаля.
3. Требование к редюсеру — он должен быть чистой функцией, dispatch чистой функцией не является, так делать нельзя как минимум по этой причине, а не только потому что это плохая идея в целом.
upd. накосячить да, можно везде. Из этого не следует, что надо все бросить, продолжать грызть кактус и не пытаться предлагать более удачные архитектуры.
2. Да, даже подскажу как, весь стейт приложения в одном observable, меняем его только чистой функцией, в разметке никаких двусторонних байндингов, вуаля.
3. Требование к редюсеру — он должен быть чистой функцией, dispatch чистой функцией не является, так делать нельзя как минимум по этой причине, а не только потому что это плохая идея в целом.
upd. накосячить да, можно везде. Из этого не следует, что надо все бросить, продолжать грызть кактус и не пытаться предлагать более удачные архитектуры.
Вы как-то сильно радикально подошли к задаче. Ни дополнительные observable, ни двусторонние биндинги никак не мешают UDF.
Достаточно
1) не кидать исключений,
2) использовать pureComputed вместо computed.
И да, не надо противопоставлять реактивный стиль программирования и чистый код, потому что они вообще-то лучшие друзья.
Достаточно
1) не кидать исключений,
2) использовать pureComputed вместо computed.
И да, не надо противопоставлять реактивный стиль программирования и чистый код, потому что они вообще-то лучшие друзья.
Во первых двунаправленные байндинги в однонаправленной архитектуре — должно насторожить само по себе. Тут это не игра слов, а буквально не подходят по определению.
А во вторых, т.н pureComputed по определению не являются чистым кодом, в силу недетерминированности.
Функционально-реактивный стиль да, с чистым кодом в обнимку, только к нокауту это не имеет никакого отношения.
А во вторых, т.н pureComputed по определению не являются чистым кодом, в силу недетерминированности.
Функционально-реактивный стиль да, с чистым кодом в обнимку, только к нокауту это не имеет никакого отношения.
Растет она пока не достигнет порога при котором любое вносимое изменение гарантированно, т.е. с вероятностью близкой к 100%, внесет ошибку.Не согласен. С ростом проекта растет количество разработчиков, которые просматривают пулл-реквесты. С таким подходом вероятность не выше 50%.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Контроль сложности и архитектура UDF