You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
The text was updated successfully, but these errors were encountered:
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)
The text was updated successfully, but these errors were encountered: