Conversation
This helps manage some of the "make sure to resolve on unmount" that we'd seen in this PR: https://github.com/homebound-team/internal-frontend/pull/2417/files?w=1
| import React, { PropsWithChildren, useCallback, useEffect, useMemo, useRef, useState } from "react"; | ||
|
|
||
| export enum AutoSaveStatus { | ||
| /** No calls are in-flight or just-recently-saved. */ |
There was a problem hiding this comment.
Just added descriptions for good measure
| export interface AutoSaveStatusContextType { | ||
| status: AutoSaveStatus; | ||
| /** Resets status to IDLE, particularly useful if "Error" or "Done" is stale */ | ||
| resetStatus: VoidFunction; |
There was a problem hiding this comment.
I removed resetStatus with the idea that it's the responsibility of the provider itself to manage when to reset/not-reset status, based on components notifying of their own/individual status.
There was a problem hiding this comment.
It already did do that, to an extent.
resetStatus() was a way for components to manually clear our the save status. i.e. if something failed, the user started typing again, and we wanted to show Idle/Ready instead of Error before actually firing a new save.
| /** Resets status to IDLE, particularly useful if "Error" or "Done" is stale */ | ||
| resetStatus: VoidFunction; | ||
| errors: unknown[]; | ||
| errors: string[]; |
There was a problem hiding this comment.
I changed the type to string[] b/c one place was passing Errors, another strings, and to be useful to display, the client needs to have some sort of idea of what's here.
| }); | ||
|
|
||
| it("renders with a provider", () => { | ||
| const { result } = renderHook(() => useAutoSaveStatus(), { |
There was a problem hiding this comment.
Most of these renderHook changes are just using the wrapper alias.
| const { result } = renderHook(() => useAutoSaveStatus(), { wrapper }); | ||
|
|
||
| act(() => result.current.triggerAutoSave()); | ||
| act(() => result.current.setLoading(true)); |
There was a problem hiding this comment.
Moving over to the setLoading API.
The context still has trigger/resolve as it's internal impl that we expose to useAutoSaveStatus, but the external API of useAutoSaveStatus is now just "loading yes/no?" and internally we turn that into trigger/resolve as/if needed.
This API change is mostly driven b/c our useMutation wrapper here:
https://github.com/homebound-team/internal-frontend/pull/2417/files?w=1
Can no longer imperatively call trigger in a try with a resolve in the catch/finally. Instead we're just told by useMutation "here's the current loading+error values", which the setLoading API facilitates:
const setLoading = useAutoSaveStatus();
const [useSaveFoo, saveFoo] = useSaveFoo();
setLoading(saveFoo.loading, saveFoo.error?.toString());
stephenh
changed the title
|
@bdow / @TylerR909 I was futzing with this to make the ergonomics of this PR cleaner: https://github.com/homebound-team/internal-frontend/pull/2417/files?w=1 And I think Because really what that PR is doing is solving save/auto-save for all mutations, not just ones that go through form-state auto saves. So, we could pull So, could land this PR in form-state but then automatically copy/paste the auto-save-context over into Beam, and delete it from this repo (and any calls that |
TylerR909
left a comment
TylerR909
left a comment
There was a problem hiding this comment.
Not a huge fan of how imperative setSaving(true/false) feels. Much prefer declarative trigger/resolve. But, that notwithstanding, lgtm.
Tried to write a test to check the useEffect cleanup effect to verify status gets set back to idle but couldn't get it working. I'm convinced it works, though.
| export interface AutoSaveStatusContextType { | ||
| status: AutoSaveStatus; | ||
| /** Resets status to IDLE, particularly useful if "Error" or "Done" is stale */ | ||
| resetStatus: VoidFunction; |
There was a problem hiding this comment.
It already did do that, to an extent.
resetStatus() was a way for components to manually clear our the save status. i.e. if something failed, the user started typing again, and we wanted to show Idle/Ready instead of Error before actually firing a new save.
Fwiw terminology-wise I'd call |
2 participants
This helps manage some of the "make sure to resolve on unmount" that
we'd seen in this PR:
https://github.com/homebound-team/internal-frontend/pull/2417/files?w=1