|
1 |
| -import { useMutation } from '@apollo/client'; |
2 |
| -import { isEqual } from 'lodash'; |
3 |
| -import { UpdateLanguageEngagement as UpdateLanguageEngagementInput } from '~/api/schema.graphql'; |
4 |
| -import { EngagementDataGridRowFragment } from './engagementDataGridRow.graphql'; |
| 1 | +import { useGridMutation } from '../Grid'; |
| 2 | +import { EngagementDataGridRowFragmentDoc as EngagementGridRow } from './engagementDataGridRow.graphql'; |
5 | 3 | import { UpdateLanguageEngagementGridDocument as UpdateLanguageEngagement } from './UpdateLanguageEngagementGrid.graphql';
|
6 | 4 |
|
7 |
| -export const useProcessEngagementUpdate = () => { |
8 |
| - const [updateLanguageEngagement] = useMutation(UpdateLanguageEngagement); |
9 |
| - |
10 |
| - return ( |
11 |
| - updated: EngagementDataGridRowFragment, |
12 |
| - prev: EngagementDataGridRowFragment |
13 |
| - ) => { |
14 |
| - if (updated.__typename !== 'LanguageEngagement') { |
15 |
| - return updated; |
16 |
| - } |
17 |
| - |
18 |
| - if (isEqual(updated, prev)) { |
19 |
| - return updated; |
| 5 | +export const useProcessEngagementUpdate = () => |
| 6 | + useGridMutation(EngagementGridRow, UpdateLanguageEngagement, (row) => { |
| 7 | + if (row.__typename !== 'LanguageEngagement') { |
| 8 | + return undefined; |
20 | 9 | }
|
21 |
| - |
22 |
| - const input: UpdateLanguageEngagementInput = { |
23 |
| - id: updated.id, |
24 |
| - milestoneReached: updated.milestoneReached.value, |
25 |
| - usingAIAssistedTranslation: updated.usingAIAssistedTranslation.value, |
26 |
| - }; |
27 |
| - // Don't wait for the mutation to finish/error, which allows |
28 |
| - // the grid to close the editing state immediately. |
29 |
| - // There shouldn't be any business errors from these current changes, |
30 |
| - // and network errors are handled with snackbars. |
31 |
| - // Additionally, MUI doesn't handle thrown errors either; it just gives |
32 |
| - // them straight back to us on the `onProcessRowUpdateError` callback. |
33 |
| - void updateLanguageEngagement({ |
34 |
| - variables: { input }, |
35 |
| - // Inform Apollo of these async/queued updates. |
36 |
| - // This is important because users can make multiple changes |
37 |
| - // quickly, since we don't `await` above. |
38 |
| - // These optimistic updates are layered/stacked. |
39 |
| - // So if two value changes are in flight, the value from the first |
40 |
| - // API response isn't presented as the latest value, |
41 |
| - // since there is still another optimistic update left. |
42 |
| - // Said another way: this prevents the UI from presenting the final change, |
43 |
| - // then looking like it reverted to the first change, |
44 |
| - // and then flipping back to the final change again. |
45 |
| - // This also ensures these pending updates are maintained |
46 |
| - // even if the grid is unmounted/remounted. |
| 10 | + return { |
| 11 | + variables: { |
| 12 | + input: { |
| 13 | + id: row.id, |
| 14 | + milestoneReached: row.milestoneReached.value, |
| 15 | + usingAIAssistedTranslation: row.usingAIAssistedTranslation.value, |
| 16 | + }, |
| 17 | + }, |
47 | 18 | optimisticResponse: {
|
48 | 19 | updateLanguageEngagement: {
|
49 | 20 | __typename: 'UpdateLanguageEngagementOutput',
|
50 |
| - // This is an easy/cheap/hacky way to "unparse" the date scalars |
51 |
| - // before writing them to the cache. |
52 |
| - // Our read policies expect them to be ISO strings as we receive |
53 |
| - // them from the network this way. |
54 |
| - // Since our temporal objects have a toJSON, this works fine to revert that. |
55 |
| - engagement: JSON.parse(JSON.stringify(updated)), |
| 21 | + engagement: row, |
56 | 22 | },
|
57 | 23 | },
|
58 |
| - }); |
59 |
| - |
60 |
| - return updated; |
61 |
| - }; |
62 |
| -}; |
| 24 | + }; |
| 25 | + }); |
0 commit comments