search

TheBLVD / mammoth

GNU Affero General Public License v3.0
172 stars 12 forks source link

MAM-3914-dont-replace-every-post-data-when-fetching-for-interaction #555

Closed derspyy closed 1 month ago

derspyy commented 2 months ago

i basically inverted our logic. instead of overwriting the .data parameter and keeping a backup in .preSyncData, i'm keeping .data the original data and only writing new data to .remoteData, which is only used for interactions and app name.

i think this is a good quick fix for weird ID behavior until we figure out a better solution.

bnolens commented 2 months ago

I like this direction. We should map data to its origin. So if a post comes from forYou or a SL (via moth.social) we should store the status data like that in the PostCardModel. If we sync the post with it's local data, we should store the local data separately in the PostCardModel. Maybe data in PostCardModel could be a dictionary. Let's fully map out what we want to do here and come up with a design that can scale to all of the above.

derspyy commented 2 months ago

currently, data is only the originally fetched Status. so if the post was fetched from the FY or SL, .data is not from the user instance. are you suggesting that in those cases we should default to .remoteData and leave .data only for stuff from the user's instance?

derspyy commented 2 months ago

what we could do is make data an optional localData, make two functions fetching one from the other and read both like localData ?? remoteData! (or the opposite depending in priority) whenever we need post data.

derspyy commented 2 months ago

and then interactions are super simplified because now instead of retryLocally we can just read localData and fetch it if it's nil.

derspyy commented 2 months ago

i'm thinking of this pr as a simple fix to those weird "id mismatch" issues before we think of an alternative