Well, I don’t know if it helps, but I try to think in more “passive” rather than “active” terms when it comes to Bubble - i.e. elements “referencing” or “responding to” data (states) or events as opposed to “passing” or “sending” information.
I’ve also found that creating a “data hierarchy” within the page, where the nesting of groups reflects that hierarchy, can facilitate this approach. For example, the “thing” of the page itself might be a User, with a group or RG referencing that user’s messages, and then elements within the RG referencing their parent.
If structured in such a way, then the nested elements can simply reference the “current cell’s” or “parent group’s” data, and things should be fairly straightforward.
Also, keep in mind that things like an element’s data source and visual attributes can be changed based on a “condition” (via the Conditions tab of the property editor).
Anyway, you probably know this stuff, but having a bit of a traditional coding background, I have to continually remind myself of it. (The Bubble programming model seems to more closely align with front end frameworks like React or Vue.)