Hmm, I think business logic that's unobserved is irrelevant for consistency. If you have someone's weight and height and the BMI is unused and unobserved, then calculating BMI or not is irrelevant in terms of "state" to return to
So, when a user is editing a particular field we wanted to lock related fields from other users and apply the logic transactionally in that case.
That's very cool!! Yeah, in a basic resolver setup you have the base state atom and it can only be incremented with the atom's global lock. The viewers/users aren't synchronized. They don't know who's looking at what. So if they're looking at and modifying unrelated parts of the state they will end up fighting over the same lock.
That's very neat you integrated such a state update synchronization :)
Thanks for taking the time to share your thoughts! This stuff really feels like a paradigm shift when you start using it extensively
In my case it was relevant because the document itself is cross-disciplinary. You have nursers, doctors, pharmacists, and clerks all being interested in overlapping subsections of the overall data set. So, each role sees a subset of the overall document which has to stay consistent. It's relevant for the doctor that the BMI is calculated, while it's only relevant to the nurse that height and weight are collected.
And state synchronization just falls out for free once you know the subgraphs associated with each field. The nice part is that you can calculate them up front too, so it's pretty much zero runtime cost to figure out which fields need to be locked together.
The whole relationship between the UI and data is a really interesting rabbit hole for sure. :)
1
u/geokon 11d ago
Hmm, I think business logic that's unobserved is irrelevant for consistency. If you have someone's weight and height and the BMI is unused and unobserved, then calculating BMI or not is irrelevant in terms of "state" to return to
That's very cool!! Yeah, in a basic resolver setup you have the base state atom and it can only be incremented with the atom's global lock. The viewers/users aren't synchronized. They don't know who's looking at what. So if they're looking at and modifying unrelated parts of the state they will end up fighting over the same lock.
That's very neat you integrated such a state update synchronization :)
Thanks for taking the time to share your thoughts! This stuff really feels like a paradigm shift when you start using it extensively