Try those data structures out. They are based on functional lenses and are really efficient and you can get time travel for free.
It's worth trying to understand the data structure and why it was used before you dismiss it out of hand. It was a very deliberate choice. There is also a very strong 1:1 mapping between plain old javascript objects and the state data structure you build up with observ, observ-struct and observ-varhash. Serialization and hydration works basically out of the box.
My reaction to the marty stuff is that it's trying to moved towards an architecture that mercury already has out of the box and that you don't have the unnecessary component state stuff the parent comment mentioned.
The component state stuff is probably my biggest gripe with the way react is architected.
Haven't used mercury, but in react component state has it's uses. It's strongly recommended both in docs and mailing list that component state should only be used for ephemeral data, the data that losing is not a problem when the component unmounts.
For example, when implementing a dropdown menu with react, holding the dropdown menu's open/closed state in the component, and modifying it with onClick events is really convenient.
It's worth trying to understand the data structure and why it was used before you dismiss it out of hand. It was a very deliberate choice. There is also a very strong 1:1 mapping between plain old javascript objects and the state data structure you build up with observ, observ-struct and observ-varhash. Serialization and hydration works basically out of the box.
My reaction to the marty stuff is that it's trying to moved towards an architecture that mercury already has out of the box and that you don't have the unnecessary component state stuff the parent comment mentioned.
The component state stuff is probably my biggest gripe with the way react is architected.