в чате был диалог на тему. Thunk на то и нужен, что бы компонент не перегружать кучей логики, сложные последовательности экшенов выносятся в отдельные экшн креаторы, динамические вычисления выносятся в селекторы, изменение стейта - остаётся в компоненте. Зачем все смешивать?
Отмена предыдущих вызовов метода решается в несколько строк кода, и не всегда кстати нужна.
Возможно, из-за примера на codesandbox у нас недопонимание, и пример с редаксом будет прекрасен, но если забыть про редакс, простое изменение стейта, которое в тасках, так же можно написать в методе компонента, не наследуясь от какого-то класса, что в случае с реактом кстати антипаттерн.
Хочется предсказуемого состояния с заранее описанными доступными переходами - есть стейт машины, но они только добавят кода, хоть и упростят контроль состояния. А в случае с этими goals как раз прослеживается стейт машина, которая по факту не делает почти ничего
Тренер ближе к function tree
Обсуждают сегодня