feat: Add setSaving function.

[stephenh]

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

[stephenh]

Just added descriptions for good measure

[stephenh]

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.

[TylerR909]

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.

[stephenh]

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.

[stephenh]

Most of these renderHook changes are just using the wrapper alias.

[stephenh]

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]

@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 setSaving is still a good/nice change, but more fundamentally I'm realizing that, with the new useMutation-based approach of that PR, we could basically remove the form-state based integration all together (b/c any formState.autoSave is calling a mutation anyway).

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 AutoSaveStatus/provider out of form-state all together and probably just drop it directly into Beam (we didn't do this originally b/c we thought that form-state, which is "upstream" of beam, would need to control the instrumentation; but that's not the case anymore with the useMutation-based approach.)

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 useFormState / useFormStates are making).

[TylerR909]

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.

[TylerR909]

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.

[stephenh]

Not a huge fan of how imperative setSaving(true/false) feels. Much prefer declarative
trigger/resolve.

Fwiw terminology-wise I'd call setSaving the more declarative of the two b/c it lets the caller say / "declare" my current status is X. Vs. the trigger/resolve which have to be called in order, usually in an ("imperative") try/catch or useEffect.