π YAAAS!!! Solved the edit/delete issue of previous generation notifs on a different content model
Comments are easy to edit/delete, it's the edit/delete of its related child notifications that are hard. Adding a new content field to the notif model only added new complexities, where previous and current generation of notifs need to be handled differently (key thing is, fetching the right notif for previous gen and current gen uses different filter params due to the additional commentContent field).
Should I care if previous generation notifications get updated if a user updates the parent comment? It's likely not a common use case (people don't usually go back to old comments to edit/delete them), but I like things to be backwards-compatible instead of sweeping this tech debt under the carpet. Took more time for sure, and double the complexity, but I hope it's worthwhile for better UX.
Had to add if else statements to both the delete and edit functions, to accommodate both generations. The condition `this.relatedNotifs.length` is based on fetching the current gen of notifs - if .length=0, then run function for prev gen; if .length>0 then run function for current gen.
Should I care if previous generation notifications get updated if a user updates the parent comment? It's likely not a common use case (people don't usually go back to old comments to edit/delete them), but I like things to be backwards-compatible instead of sweeping this tech debt under the carpet. Took more time for sure, and double the complexity, but I hope it's worthwhile for better UX.
Had to add if else statements to both the delete and edit functions, to accommodate both generations. The condition `this.relatedNotifs.length` is based on fetching the current gen of notifs - if .length=0, then run function for prev gen; if .length>0 then run function for current gen.
