📣 RFC: Alternative renderHook APIs

[mpeyper]

I'm working on the improved docs in #19 and I'm struggling a bit with the section on changing the parameters passed to the hooks. Essentially, my issue is that there are 2 ways you can do it.

The first way is to just keep local variables and update them before rerendering:

let someValue = 0
const { result, rerender } = renderHook(() => useSomeHook(someValue))

// update value
someValue = 1
rerender()

The second way is the use the options.initialProps and rerender(newProps) features:

const { result, rerender } = renderHook(({ someValue }) => useSomeHook(someValue), {
  initialProps: { someValue: 0 }
})

// update value
rerender({ someValue: 1 })

The main reason the second way exists was to work around an issue in our own unit test for ensuring useEffect hooks were testable. The problem was that the updated value was updated for the cleanup of the effect too rather than capturing the initial value. In hindsight, I can see that is probably only an issue for that test, as most users would be passing the values into a hook function, capturing the initial value for the cleanup.

I'm not saying that having the callback function scope the variables isn't still a good idea in some cases, but I think it's a non-issue for most users.

Now we could just remove the initialProps/newProps functionality altogether, but I personally find the usage of a bit more ergonomic, especially when there is more than 1 value to update, as I don't have to keep a variable and spend multiple lines to rerender (1 for each update to the values and the another to render), so I'm asking for opinions on people's preferred API for this.

I'm also open to any ideas for a better API than either of these if you can think of one. I've actually been playing with an idea for a "hook-like" API along the lines of:

const { result, updateProps } = renderHook(() => {
  const someValue = useProps(0)
  return useSomeHook(someValue)
})

// update value
updateProps(1)

Where updateProps calls rerender under the hood. I'm not sure if this is a good idea, just a thought I had. Anyway, let me know your thoughts on any of the above.

[hartzis]

I really like where you're headed! Could it be simplified even more so we don't have to explicitly use useProps either?

const { result, updateProps } = renderHook(useSomeHook, initialProps)

// update value
updateProps(1)

Then under the hood renderHook could use your useProps? I also keep seeing the pattern of always passing an anonymous function wrapping the tested hook, () => useSomeHook(), why couldn't renderHook just do that?

I think this might break the current api, but just throwing out to think about it.

[mpeyper]

Hi @hartzis,

Thanks for taking the time to give your thoughts.

The main reason why we don't just accept the initialProps as the second parameter is that there are other options that can be provided, i.e. wrapper. It's impossible to say which is more valid as the second parameter and which would be third, as anyone wanting to update props will need to use initialProps, but anyone wanting to useContext will need to use wrapper, so they both went into the options` giving them the same level of precedence in API. That's not to say we couldn't do that, just that I'd like to find a better way.

Essentially what your asking for with calling the hook with the props is what it does now, so long as your hook accept a single parameter:

function useSomeHook(someValue) {
  // whatever
}

const { result, rerender } = renderHook(useSomeHook, { initialProps: 0 })

// update value
rerender(1)

The anonymous function is often used to take the single parameter and turn it into many for the hook function:

function useSomeHook(someValue1, someValue2) {
  // whatever
}

const { result, rerender } = renderHook(
  ({ someValue1, someValue2 }) => useSomeHook(someValue1, someValue2),
  { initialProps: { someValue1: 0, someValue2: 1 } }
)

// update value
rerender({ someValue1: 3, someValue2: 4 })

Because of this I just use the anonymous function for all cases for consistency.

[mpeyper]

The current spike I have for useProps/updateProps would look like this for the above example

function useSomeHook(someValue1, someValue2) {
  // whatever
}

const { result, updateProps } = renderHook(()  => {
  const [someValue1, someValue2] = useProps(0, 1)
  return useSomeHook(someValue1, someValue2)
})

// update value
updateProps(3, 4)

The hook callback could be onelined as:

const { result, updateProps } = renderHook(() => useSomeHook(...useProps(0, 1)))

I'm not sure that is particularly readible for newcomers though.

There's also a restriction that it can only be called once within renderHook, which is probably fine but may cause difficult to debug issues if misused, so I'd like to either make it jsut work, or at least give a meaningful error if they try.

The other thing I'm noticing as I update the tests to use the new API, is the rerender function is becoming irrelevant. I'm sure there are going to be cases where you want to rerender the hook without props changing so I'm loathed to remove it, but I'm struggling to find one myself. If you have one then please let me know.

[hartzis]

Nice! I too can't currently think of a use for rerender, but there is probably someone that will find a reason, 🤣

Thoughts on a "helper" for the oneliner?

function testHook () {
  const [hook, ...args] = arguments;
  return renderHook(() => hook(...useProps(...args)))
}
...
const { result, updateProps } = testHook(useSomeHook, 0, 1)

Too far? Too much? I may just be having too much fun.

[mpeyper]

I've moved away from the useProps idea as the implmentation was starting to get quite complicated and it was starting to feel like I was make a hooks-like implementation for the "cool" factor more than anything. I still think the concept has legs, but I don't have the time myself to put into an entire rewrite of much of the libraries guts right now.

On a different note, I was given an interesting suggestion from @jpeyper in person about this which I'll put here for consideration.

The idea is to use default values on the parameters for the initial props, and have rerender update the props if they are provided... something like:

const { result, rerender } = renderHook(
  (someValue = 0, someOtherValue = 'test') => useSomeHook(someValue, someOtherValue)
)

// update values
rerender(1, 'updated test') // order would be important here

Note: I think this is technically possible with the current API as long as you use an object for the one and only parameter, e.g.

const { result, rerender } = renderHook(
  ({ someValue = 0, someOtherValue = 'test' }) => useSomeHook(someValue, someOtherValue)
)

// update values
rerender({ someValue: 1, someOtherValue: 'updated test' })

I prefer this to the current initialProps implementation as it's one less time I have to duplicate the names of that parameters. The second example here (using the current props objectalso has some benefits in my opinion in that it doesn't rely on order to line up the parameters and it's perhaps a bit clearer when reading the code to identify the link between thererender` values and the the callback parameters.

I also think that if the rerender behavior was changed to merge with the current props, this could be quite a straight forward API to use:

const { result, rerender } = renderHook(
  ({ someValue = 0, someOtherValue = 'test' }) => useSomeHook(someValue, someOtherValue)
)

// update someValue
rerender({ someValue: 1 })

// update someOtherValue
rerender({ someOtherValue: 'updated test' })

// resets both
rerender({ someValue: undefined, someOtherValue: undefined })

Happy to hear thoughts 👂

[hartzis]

@mpeyper I personally really like the idea of using default values.

[mpeyper]

Thanks for the feedback @hartzis! Just for my reference, which of the 3 shown example do you prefer?

[hartzis]

@mpeyper Yeah, I guess I kind of saw them all as essentially the same. The defaults are in the user's control and not the library.

rerender could just pass all arguments to the function passed to renderHook?

Then both the object destructuring and the order of params just work?

Your examples are easy to follow, read, and feel natural with what I think one would "expect". Please let me know if I'm misunderstanding, but they really feel straightforward and clean.