It does not have to cover every single reason for redrawing to be useful, just for the ones that are included to be reliable. So a ”not exactly 1:1” situation should be good enough for this purpose.
Well, I am trying to trigger an action when a card gets moved from one list to another, but only for the member who did the moving. I am already keeping track of movements between lists by keeping the old list in the public card data section of the powerup. I hoped that I would be able to piece together who did the moving in a similar way.
I could not find any way to derive the initiator information from the client library. The REST-Api allows access to a cards history, which in turn could be used to resolve the initiator of the card movement. But given the additional authentication requirements, the rate limiting of the api and the fact that I would have to do this on every single list change render() call for every single active member makes this effectively a non-solution.
I thought that maybe once render() triggered for the member initiating the action, I could just trigger my own action and then set a flag for all other members indicating that this action is already resolved. But the client library does not work that way. When a member triggers a list change, all active members will get a render() call with the same snapshot of the board state as the original initiator, not with the state that the initiator left behind, so the do-not-act flag would not be seen by the other members before they had already acted.
Lastly I thought that by clever manipulation of the card’s data and analysis of how it changed between subsequent calls I might be able to deduce the original initiator. But besides this resulting in a lot of additional data manipulations and subsequent render() calls this would also be pretty unreliable. My tests suggested that for members on similar internet connections the scheduling order of the calls might be reliable enough to make assumptions about the originator of an action, but for members on very different connections there is no guarantee of scheduling order at all.
I don’t know if there is a good reason not to give powerups insight into state transitions, but this information is already available through the card history of the REST api. Giving powerups access not only to current board state, but also allowing them to understand how that state came to be would allow powerups to perform actions based on very specific contexts. In my current case it is only about starting a timer for one board member, and not for another. I have quite a few of requests asking to make my powerup smarter. And in many cases this smartness depends on not only knowing what the state of the board is right now, but also how it came to be.
If any of this is unclear, please let me know and I will try to elaborate on it.