usePromise

[hnordt]

const MyComponent () => {
  const { isPending, data, error }  = usePromise(sendRequest({ url: "/somewhere" }))
  return null
}

const MyComponent () => {
  const { isPending, data, error, dispatch }  =
    usePromise(() => sendRequest({ url: "/somewhere" }))
  return <button onClick={dispatch} />
}

const usePromise = promise => {
  const autoDispatch = typeof promise !== "function"

  const [isPending, setIsPending] = useState(autoDispatch)
  const [data, setData] = useState(null)
  const [error, setError] = useState(null)

  const dispatch = async () => {
    try {
      const _promise = autoDispatch ? promise : promise()
      setData(await _promise())
    } catch (error) {
      setError(error)
    } finally {
      setIsPending(false)
    }
  }

  useEffect(() => autoDispatch && dispatch())

  return {
    isPending,
    data,
    error,
    dispatch
  }
}

[jxom]

I'd honestly like to convert https://github.com/jxom/react-loads to use hooks - this kind of abstraction will be real useful!

[jamesplease]

This is cool, and an idea that I was thinking about while reading the hooks documentation. What I'm really curious to understand better is best practices regarding when to use Suspense versus when to use hooks. It seems like this API here is doing some of the same things that the Suspense API is being designed to do.

I'm pretty curious about this topic, so I tweeted about it. I know that the React team is super busy – especially right now after dropping this huge RFC – but maybe we'll hear back from them.

[jxom]

Yeah, I've been actively thinking about it too @jamesplease. I'd love to understand more about this as well!

[hnordt]

Dropped in favor of Suspense.

https://twitter.com/sophiebits/status/1055702535183290369

Thanks @jamesplease.

[jxom]

Hmm, I think this could still be a valid approach though, as you can actually “suspend” from within a hook. I think it would still be pretty useful to create an abstraction around promise state/data with a hook. Correct me if I’m wrong in my thinking though!

[jamesplease]

as you can actually “suspend” from within a hook.

Is that so? I thought Suspense (and suspending) meant turning render into something like a coroutine, whereas custom hooks acted more like an Observable, “pushing” values into the Component that cause it to rerender. Can custom hooks be used to transform render into a coroutine as well?

If you just mean that custom hooks can be long-living (like an “epic”), then I don’t think I would use the word “suspending” to describe that based on my current understanding. I could be wrong on my word usage tho’

I think it would still be pretty useful to create an abstraction around promise state/data with a hook. Correct me if I’m wrong in my thinking though!

I think this depends on the exact nature of subtle nuances that Sophie mentioned in her reply to me. She mentions “concurrent renders,” which sounds like it may just be an optimization thing, but I’m not sure.

I plan to do some more thorough testing of the Suspense component vs custom hooks over the next few days to see what the differences are, and how they might interact with other things in React (like Context updates).

[jxom]

Well I thought the same as you until I was scrolling twitter and saw Dans tweet...

You could suspend inside a Hook.
https://twitter.com/dan_abramov/status/1055693701488402432?s=21

I think it might be best to wait until Suspense is fully documented before we make some kind of assumption about this though?

Let me know how you go in your investigations though - am curious!

[jamesplease]

That’s pretty interesting. I hadn’t considered that, but it makes sense.

Waiting for docs on the Suspense component is definitely the right thing to do, but we’re already playing around with an unstable API (hooks), so I think it is fine to explore different things, even if we find out later that it isn’t encouraged by the React team.

If we assume (for kicks) that the Suspense component is stable, and that the basics of the hooks API will remain the same, do you think it would make sense to allow for a hook like this to optionally suspend? The Apollo Client’s Query component has a prop to toggle this behavior iirc.

[hanford]

Hey friends, after searching the issues for Async yesterday I started working on something very similar. (probably should have searched promise too 🙇‍♂️)

Feel free to take a look ... I'm curious what everyones thoughts are:

• rehooks issue
• repo with working code
• codesandbox demo

The hook I wrote should be ready to be merged as is, but I'm happy to make tweaks according to feedback

[fouad]

Agree with @jamesplease, learning about Suspense will help a lot with the React-standard way to do this

@hanford not sure we should merge #44 as useAsync for similar reasons — leaving other comments in that PR

we can leave this issue open in case anyone else has an opinion/idea about promises + React Hooks