Един от ключовите проблеми, с които се сблъсках в предишната си работа, е справянето с действия, които трябва да променят състоянието на 2 отделни клона на дървото на компонентите. Когато използвате изрична настройка на състоянието, трябва да правите всякакви изкривявания, като предавате обратни извиквания дълбоко в дървото, където тяхната уместност е съмнителна и отвлича вниманието от това, което вашият компонент прави там. В крайна сметка човек завършва със състояние на спагети — върнете се към кода си след 4 месеца и нямате представа как работи. Въведеният редуциране на модела на проектиране означава, че действието, задействащо актуализации на състоянието, не трябва да знае къде се случва промяната на състоянието. Това също означава, че мястото, където се променя състоянието, също е лесно намерено и следователно документацията е очевидна 4 месеца по-късно. Компонентите показват неща. Това е лесно за единичен тест. Състоянието е свързано с подпорите много просто. Има много малко място за глупави спагети.
За прости проекти няма причина да се използва каквато и да е рамка. Просто го напишете и се прозявайте.
Но всеки сложен проект ще се възползва от този вид разделяне на проблемите, ако искате той да може да се поддържа дори след 6 месеца
