Pretty much all mutation hooks are written for a single specific view, some of which do multiple mutations to catch a couple of different scenarios that a resource can exist in (thread vs feed for example - it mutates the list and also mutates the thread itself)
This worked so far, but resources will show up in all sorts of places soon (boards, feeds, library, searches, LLM responses, threads, etc) so mutators need to be a bit more clever and know the context from which the mutation is occurring.
For this, I'm thinking a "view context" parameter for mutation hooks so they can optimistically mutate the correct place. It might also solve part of #278 this can also make mutators more composable and pull them out of the actual hook functions (they can get quite large)
Pretty much all mutation hooks are written for a single specific view, some of which do multiple mutations to catch a couple of different scenarios that a resource can exist in (thread vs feed for example - it mutates the list and also mutates the thread itself)
This worked so far, but resources will show up in all sorts of places soon (boards, feeds, library, searches, LLM responses, threads, etc) so mutators need to be a bit more clever and know the context from which the mutation is occurring.
For this, I'm thinking a "view context" parameter for mutation hooks so they can optimistically mutate the correct place. It might also solve part of #278 this can also make mutators more composable and pull them out of the actual hook functions (they can get quite large)