Feat: add useStateMachineInputs hook

[Bokdol11859]

Add new useStateMachineInputs Hook for fetching multiple stateMachine inputs from a rive file

Description

This pull request introduces a new hook, useStateMachineInputs, designed to easily get multiple inputs from a variable number of inputNames.

Previously, you had to map over the inputNames array to create input for each of them.
Since that behavior is against the rules of hooks, I decided to create this new hook.

---

This would be against the rules of hooks.
const inputs = inputNames.map(inputName => useStateMachineInput(rive, stateMachine, inputName));

With this hook, you can do it this way.
const inputs = useStateMachineInputs(rive, stateMachine, inputList);

---

Changes Made

CreateduseStateMachineInputs.ts

[bodymovin]

what do you think about removing the union with null and having inputs only be StateMachineInput[]?
I think an empty array is a simpler api to deal with.

[Bokdol11859]

Yeah that definitely seems like a better option. I'll change that!

[bodymovin]

is this necessary? It seems the next lines are checking the same and the else statement is also handling the alternate.

[Bokdol11859]

Yeah, it doesn't seem necessary to me either, but I had that in because I found the same logic in the useStateMachineInput code.
I could create another pull request to refactor the useStateMachineInput hook if you're okay with it.
I'll work on removing some of the repeated logic.

[bodymovin]

for safety, the useEffect hook can return a clean up function to clear this callback.
If not, multiple instances of the function might try to set the input values.

[Bokdol11859]

Thanks, I'll add a rive.off() cleanup function.

[bodymovin]

thanks for the PR! looks good overall, just left some comments on some details.

[lancesnider]

Thanks for the PR! Right now this is how you'd use it, right?

const stateMachineInputs = useStateMachineInputs(rive, STATE_MACHINE_NAME, [
  { name: ON_HOVER_INPUT_NAME },
  { name: ON_PRESSED_INPUT_NAME },
]);

const onHoverInput = stateMachineInputs?.find(input => input.name === ON_HOVER_INPUT_NAME);
const onPressedInput = stateMachineInputs?.find(input => input.name === ON_PRESSED_INPUT_NAME);

I'd love to see it to where defining each input didn't require extra component code. Maybe something like:

const [onHoverInput, onPressedInput] = useStateMachineInputs(rive, STATE_MACHINE_NAME, [
  { name: ON_HOVER_INPUT_NAME },
  { name: ON_PRESSED_INPUT_NAME },
]);

[lancesnider]

Does anyone else get this warning when using it in a component: useStateMachineInputs.ts:39 Warning: Maximum update depth exceeded

[bodymovin]

this validation isn't needed, a filter call will always return an array at this point

[Bokdol11859]

True! I'll fix that too!

[Bokdol11859]

Thanks for the PR! Right now this is how you'd use it, right?

const stateMachineInputs = useStateMachineInputs(rive, STATE_MACHINE_NAME, [
  { name: ON_HOVER_INPUT_NAME },
  { name: ON_PRESSED_INPUT_NAME },
]);

const onHoverInput = stateMachineInputs?.find(input => input.name === ON_HOVER_INPUT_NAME);
const onPressedInput = stateMachineInputs?.find(input => input.name === ON_PRESSED_INPUT_NAME);

I'd love to see it to where defining each input didn't require extra component code. Maybe something like:

const [onHoverInput, onPressedInput] = useStateMachineInputs(rive, STATE_MACHINE_NAME, [
  { name: ON_HOVER_INPUT_NAME },
  { name: ON_PRESSED_INPUT_NAME },
]);

I just needed them to be fired all at once so I didn't have to manage them one by one.
But yeah that seems like a better approach to me too! I'll change that!

[Bokdol11859]

Does anyone else get this warning when using it in a component: useStateMachineInputs.ts:39 Warning: Maximum update depth exceeded

I'll take a look at it!

[Bokdol11859]

I made some changes to the code! 2a26db1

1. The hook now returns the inputs as an array, where each of the inputs are in the order they were in in the inputNames array
2. Codes that were unnecessarily checking rive/stateMachineName/inputNames have been removed.
3. The code will run faster, as the time complexity has been cut from O(n*m) to O(max(n, m)).

[bodymovin]

is there a reason why the map needs to be stored in the state instead of the array?
It's great that it is being used as an intermediate store while building the inputs for performance, but that seems like an implementation detail of syncInputs.
In the end it's exposed as an array and It forces to use the useMemo hook.

[Bokdol11859]

Nope not at all anymore.
It was a Map for the initial implementation I planned, which is returning the Map instead of an Array. I thought it would be a better implementation as the user gets to choose which input they want to use, without having to map over the whole array again to find it.
But I realized that could be handled by preprocessing the inputNames array passed to the hook. ex) filtering out the unnecessary inputNames before calling the hook.

So yeah, there's no reason for it to be a Map instead of an Array now.
I'll change that! Thanks for pointing it out!

[bodymovin]

out of curiosity, in the previous implementation this method was defined in the useEffect hook directly. Was there a reason for moving it outside?
As far as I know, it's a good practice to declare methods that are only used in a useEffect, inside the useEffect hook itself. It helps with encapsulation. And in this particular case doesn't need the useCallback hook.

[Bokdol11859]

It's true that declaring functions that are only used in a useEffect within the hook is helpful for encapsulation, but I think it kind of hurts the readability of the code in many cases.
I personally like to leave the useEffect hook as concise as possible so that I can understand the flow of the useEffects quickly without scrolling up and down too much.
(Besides, I find useEffects to be where the majority of unexpected bugs occur, so I try to keep them easy to understand in most cases.)
Since there's just one useEffect in this case, and since the function gets recreated whenever the useEffect runs (as they have the same dependency array), I don't really mind whether the function is defined inside or outside the hook.

If putting functions within useEffects is the convention Rive follows, I'm more than happy to move it back into the useEffect! Let me know what you think!

[Bokdol11859]

Does anyone else get this warning when using it in a component: useStateMachineInputs.ts:39 Warning: Maximum update depth exceeded

@lancesnider Are you still seeing this warning? I don't seem to be getting it right now from where I'm using it.