но там реализация снизу

Чето сложно

Зачем разделять стор и эффект, если у обоих сущностей есть состояние и на оба хочется подписываться? Почему бы все не упростить и не описывать деларативно только зависимости от состояния?

Чет код вообще не рассказывает о намерениях автора

RFC по pathon 2.0 готово:
https://gist.github.com/artalar/7edfcacc84cd6fe0ab43e883564e4dbc
Что внутри:
- минималистичный API: эффект и стор - все одно и тоже - просто набор тригеров на изменение состояния
- мощнейшие возможности для функциональной композиции (собственно это и описано в 2-immutablePreset.js)
- фундаментальное исправление проблемы состояния гонки, ромбовидных зависимостей и т.п.: API заставляет пользователя (updateQueue) самому думать об этом, при этом не нагружая его мозг (effect.compute и все). Т.е. в примере есть два типа подписок: простые при отсутствии необходимости мгновенной реакции (для сайд-эффектов и перерендера компонентов отображения) и compute для вычисления значений необходимых слою данных приложения. Я еще исправлю пример на более реалистичный и наглядный.
- вес кода библиотеки не должен привышать 10KB не минифицированный!
- при этом остаются безграничные возможности для расширения. Например, как видно из 2-immutablePreset.js на основе updateQueue.parent можно создавать даже рекурсивные структуры данных. Все чем занимается pathon - вызов очереди очередей подписок.

Прочитал код. Очень тяжело читается

example тяжело читается????

Да

Почему нужен child