Return dispatcher from useStateAction

[adorkable77]

Hi, thanks for your nice work!

The useStateAction hook passed the safeActionFn to react's useActionState, is it feasible to return the dispatcher from useStateAction, so that I can pass it to the form's action prop for non-js situation? some code like:

  import {.action } from './action'

  const App = () => {
    const { result, dispatcher, execute } = useStateAction(action, {})

    return (
      <form 
        action={dispatcher} 
        onSubmit={(e) => {
          e.preventDefault()
          excute(new FormData(e.currentTarget))
        }}
      >
        {result.data?.someValue}
        <button>submit</button>
      </form>
    )
  }

it seems to work well, did I miss something?

[TheEdoRan]

Saw you already commented on the related issue, but I'm linking my reply here too just for context. As already said, I'm thinking of changing useStateAction API/removing it entirely from the library in favor of useActionState hook from React, as not having support for progressive enhancement seems to be a pretty big issue. Exposing both the action dispatcher and execute is not a great solution, because if you use the dispatcher as a form action, returned props like status and input don't get correctly updated, so it's very inconsistent behavior and ultimately a pretty terrible DX.

• [BUG] Sending form with javascript disabled not working #189 (comment)

[adorkable77]

@TheEdoRan Thank you for your patient answer!
In my use case, I only want to support minimal progressive enhancement. Even if I don't use the execute/excuteAsync, I still need to implement similar functionality. I think the useStateAction hook is very helpful for DX.
In addition, without JS, the callbacks will not be called, so that's not a problem.

[TheEdoRan]

Problem is that if users use dispatcher instead of execute, then input and status properties go out of sync, which is not a good DX, as already said above. Returning dispatcher from useStateAction would allow writing buggy code, and I already can see the number of issues that would be opened if I implemented that.
So, not sure if there's a good solution. If you want progressive enhancement, it's probably best to use the useActionState hook from React. Let me know your thoughts as well, thanks.

[adorkable77]

@TheEdoRan I agree with you too.

import { someAction } from './action.ts'
import { useEffect, useActionState } from 'react'

export const Component = () => {
  const [state, dispatch] = useActionState(someAction, null)
  useEffect(() => {
      // Some things can only be handled on the client side
      if (state.error) {
        // same as onError
      } else {
        // same as onSuccess
      }
  }, [state])

  return (
    <form
      action={dispatch}
      onSubmit={e => {
        e.preventDefault()
        dispatch(new FormData(e.currentTarget))
      }}
    >...</form>
  )
}

Previously, I mistakenly thought of the execute as the implementation in onSubmit. When I don't need input and status(in most cases), this example should solve the problem.
From your perspective, Unified the API of the lib is more important. Thanks for your time!

[adorkable77]

Do you plan to remove the useStateAction hook from the library?

[TheEdoRan]

After user feedback like yours I'm thinking of keeping it as it is right now, it's indeed a useful wrapper. Maybe I can point users to React useActionState hook in the docs if they want to use progressive enhancement.

[MrOxMasTer]

Problem is that if users use dispatcher instead of execute, then input and status properties go out of sync, which is not a good DX, as already said above. Returning dispatcher from useStateAction would allow writing buggy code, and I already can see the number of issues that would be opened if I implemented that. So, not sure if there's a good solution. If you want progressive enhancement, it's probably best to use the useActionState hook from React. Let me know your thoughts as well, thanks.

I recently heard about this library and do not understand the principles by which it works and provides this type safety.

I thought it was just a convenient wrapper for validation, so as not to constantly talk like this:

const action = async (
  prevState: unknown,
  formData: FormData,
) => {
  const field = formData.get('email')?.toString();
  const valid = await schema.safeParseAsync(field);
}

At the same time, with nice features, for example: validation on the client side

The idea is very good and it is great if this library will be finalized.

But the library is made very non-native. When everyone is striving for progressive improvement and making it all native (the same resurrection of the action attribute of a form and tailwind, which is trying to more embed native CSS in the new version), the library does not like to emphasize it, provided that it is not a recently added feature. There was a useFormState hook that existed for quite a long time and it was possible to make a wrapper for it for a long time. Then change it to useActionState.

Conclusion:

Why can't you just make a wrapper for useActionState, like useSafeActionState, which when js is disabled will return a normal server action with VALIDATION on the server. And when js is available, there will be validation on both server and client (or why js is needed, I don't know in this library).

Something like this:

const someAction = action.schema(schema)
.action(async (prevState, valid) => { ... })

const Component = () => {
   const { response, formAction, isPending } = useSafeActionState(someAction, null)

  return (
    <form
      action={formAction}
      onSubmit={e => {
        e.preventDefault()
        formAction(new FormData(e.currentTarget))
      }}
    >...</form>
  )
} 

I think if we make it more native, then people will use this library more actively. To simply optimize routine actions related to validation

[MrOxMasTer]

The question is different, but what should the server action look like in general, so that there would be support for progressive improvement and I would not have errors.

It was about the 2nd argument. It was necessary to pass {}, although it is strange

[TheEdoRan]

It's not, useActionState hook expects a value of the same type of the action's return value as its second argument (initialState), in this case of the action result object which is an object with optional properties, so at least it has to be an empty object.

[MrOxMasTer]

It's not, useActionState hook expects a value of the same type of the action's return value as its second argument (initialState), in this case of the action result object which is an object with optional properties, so at least it has to be an empty object.

Then why does everything work well with a null value in a normal server action?

[MrOxMasTer]

expects a value of the same type of the action's return value

Show me at least one line where it says that she EXPECTS the SAME value.
There is even a null specified in the documentation:

The only condition I found is to use any serializable value.

[MrOxMasTer]

It's not, useActionState hook expects a value of the same type of the action's return value as its second argument (initialState), in this case of the action result object which is an object with optional properties, so at least it has to be an empty object.

And please indicate that useActionState, only stateAction works, because I'm already confused about these initial values

[MrOxMasTer]

You can discuss this with the developers of react-hook-form. They are wondering how to make it all type-safe using server actions. Think about the same thing. Maybe you can make a convenient wrapper that can be used by react-hook-form and then the beauty will be
react-hook-form/react-hook-form#11061