homebound-team / form-state Goto Github PK

Should be pretty easy to do form-level undo/redo on top of the form state.

There are a few mobx undo/redo libraries out there, not sure if the best approach is using an existing library, or copy/pasting the basic approach and adopting it for form-state's specific needs.

Originally we thought that form-state's autoSave methods would need to trigger auto-save statuses.

However, we've since added the apolloHooks.ts instrumentation in internal-frontend that hooks all mutations up to the auto-save status. Which actually works better b/c some of the schedule page's mutations weren't going through form-state.

Given this new slice point, we should be able to move AutoSaveStatusProvider to beam and not have form-state itself need to know/trigger it anymore.

 const SignupSchema = Yup.object().shape({
   firstName: Yup.string()
     .min(2, 'Too Short!')
     .max(50, 'Too Long!')
     .required('Required'),
   lastName: Yup.string()
     .min(2, 'Too Short!')
     .max(50, 'Too Long!')
     .required('Required'),
   email: Yup.string().email('Invalid email').required('Required'),
 });

Current theory is that we probably can't use exactly the Zod/Yup API / libraries one-for-one, b/c we'll have misc form-state-isms/settings like "this is the delete key", etc. that aren't included in Zod/Yup.

It seems the first generic T here should have been removed as part of #77 .

If we have a form config like:

const config = {
  authorId: { required: true, rules: (...) => }
};

The Rule interface today only accepts the serialized value, i.e. "a:1", but when authorId is bound to, say, a drop down / select field, it'd be great to have the Rule accept the AuthorFragment directly.

Currently the rule has to accept the value string and re-find the selected AuthorFragment from a shared list of authors: AuthorFragment[].

Copy/pasted from https://github.com/homebound-team/internal-frontend/pull/3424#discussion_r1107253955

I couldn't think of a great way to handle this with like "first-class" support in Beam...

I believe the concept's we'd want would be:

1. Validation rules that are conditional on rpc.status (which form-state does support today, and where I'd nudged Dean and Craig at first)
2. "Dual valid-ness", to drive "only enable Save As Active if the conditional-on-rpc.status rules all pass", essentially separate form.validIfDraft / form.validIfActive flags
3. The "conditional on rpc.status=active" error messages should only ever show up if the user comes in to an already-active RPC and starts deleting fields.

The 2nd one, which is basically the useComputed they're writing by hand, is the tough one--b/c we don't want to actually set rpc.status=active, b/c that would show a bunch of errors in the UI like (First Name is required).

But we want to ask if we happened to set rpc.status=active, then would all of the rules be true?

...I dunno, like maybe something like:

const canBeActive = useComputed(() => {
  const originalStatus = rpc.status
  // quickly switch to active
  rpc.status.value = active
  // run all the form rules
  const canBeActive = rpc.valid
  // okay, put it back
  rpc.status.value = originalStatus
  // and return our "probed" validness
  return canBeActive
});

That actually doesn't seem that bad, and maybe we could write a hook like:

const canBeActive = useMaybeValid(formState, formState.status, active);

That would internalize the "try flipping to active, record valid, put it back" dance.

But I'm not actually sure if the "flip to active, flip it back" would work in mobx...like, I'm 80% sure it "would technically work", but would be nuances around making sure the changes happened synchronously and ideally were not observed by anyone else.

...actually, I saw the phrase "transaction" in the mobx docs last night, so maybe that would be an approach...start a transaction, change the status, record the canBeActive = rpc.valid, and then rollback the transaction. Never used the mobx transactions before so not sure/don't know the API.

Given a GraphQL query like:

query {
  projectItem(id: 1) {
    bidItem { id name }
  }
}

And an input query like:

mutation {
  saveProjectItem(input: SaveProjectItemInput)
}

input SaveProjectItemInput {
  bidItem: EntityId
}

input EntityId { id: String! }

We'd like to bind that to a form like:

const formConfig: ObjectConfig<SaveProjectItem> = {
  bidItem: { type: "value", localKeys: "name" }
}

const jsx = <LazyBoundBidItemSelect field={form.bidItem}

And be able to pass the SelectField.options: initial + lambda

Questions:

• Is formConfig.bidItem a type: "value" or type: "object" with nested keys?
• Is the type of LazyBoundBidItemSelect a FieldState<{ id: string; name: string}> or an ObjectState<{ ... }>? Does it matter?