3 ms·

Not OP, but the number of variants in the events makes the cardinality of the state of the system extremely large. Probably too large to be able to reason about

Not OP, but the number of variants in the events makes the cardinality of the state of the system extremely large. Probably too large to be able to reason about fully. It makes weird bugs in the event schema likely impossible to debug should they occur.

88913527 5y ago
This is exactly why 2-way data binding fell out of favor in modern UI development. Describing the problem as "the cardinality of the state of the system extremely large" is a succinct way of putting it. The non-linear increase in possible state quickly makes testing an uphill battle. And it's over when you can't have a comprehensive testing strategy, forget about it.
- Spivak 5y ago
  Eh, two-way binding is still alive and well it’s just implemented explicitly on top of one-way bindings. It seems most developers find this easier to reason about but the relationship is still there. Like if all you’re doing is using the event to take the value from the UI and shove it into the model with setState and re-render then you made a two-way binding. Wouldn’t it be helpful if you could tell React to just do this for you and save you the boilerplate? Boom you invented ng-model.
- square_usual 5y ago
  2-way bindings are still alive and well in the big "next gen" web frameworks, Vue and Svelte.
btown 5y ago
Can this be mitigated by ensuring that historical/legacy events are all transformed to more modern equivalents? Similar in theory to https://stripe.com/blog/api-versioning https://stripe.com/blog/api-versioning ? Then you at least have a chain of testable transformations and a reduced cardinality for the actual interactions that reflects the cardinality of all the ways your business users actually use your product today. Of course, this can be lossy, but is it any more lossy than the non-event-sourced CRUD system which is essentially transforming historical events into "overwrite these fields" events that can only be used for their original purpose? To me, the reason not to use event sourcing is more that the tooling and developer experience is just really poor - and so decisions like the above, while valuable to think through directly, rapidly become overwhelming. Visualizations of system state are only as good as the code you bring yourself. I'm hopeful that people building tools on top of things like https://materialize.com https://materialize.com will start to change this though!

88913527 5y ago

This is exactly why 2-way data binding fell out of favor in modern UI development. Describing the problem as "the cardinality of the state of the system extremely large" is a succinct way of putting it. The non-linear increase in possible state quickly makes testing an uphill battle. And it's over when you can't have a comprehensive testing strategy, forget about it.

Spivak 5y ago
Eh, two-way binding is still alive and well it’s just implemented explicitly on top of one-way bindings. It seems most developers find this easier to reason about but the relationship is still there. Like if all you’re doing is using the event to take the value from the UI and shove it into the model with setState and re-render then you made a two-way binding. Wouldn’t it be helpful if you could tell React to just do this for you and save you the boilerplate? Boom you invented ng-model.
square_usual 5y ago
2-way bindings are still alive and well in the big "next gen" web frameworks, Vue and Svelte.

btown 5y ago

Can this be mitigated by ensuring that historical/legacy events are all transformed to more modern equivalents? Similar in theory to https://stripe.com/blog/api-versioning https://stripe.com/blog/api-versioning ? Then you at least have a chain of testable transformations and a reduced cardinality for the actual interactions that reflects the cardinality of all the ways your business users actually use your product today. Of course, this can be lossy, but is it any more lossy than the non-event-sourced CRUD system which is essentially transforming historical events into "overwrite these fields" events that can only be used for their original purpose? To me, the reason not to use event sourcing is more that the tooling and developer experience is just really poor - and so decisions like the above, while valuable to think through directly, rapidly become overwhelming. Visualizations of system state are only as good as the code you bring yourself. I'm hopeful that people building tools on top of things like https://materialize.com https://materialize.com will start to change this though!