You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I'm currently attempting to implement React Hook Form to coincide with Player in a React Webapp. React Hook Form utilises a register function that passes props through to a component. An example of this could be:
This register function spreads a few props to the element; name, onBlur, onChange and ref.
Due to the nature of how React Ref works, ReactAsset consumes the Ref. Docs here.
Describe the solution you'd like
I believe implementing the React forwardRef to the ReactAsset component would solve this issue. This is under the assumption that the current system does not have an alternative method to solve this issue. By my understanding, this should not cause issues with components who are not expecting a ref, allowing "backwards compatibility" from this change.
An example solution:
// Callback Type - As specified from ReactHookForm's definition of the `ref` returned by `register`
export type RefCallBack = (instance: any) => void;
export default forwardRef<
RefCallBack,
AssetType<string> | AssetWrapper<AssetType<string>>
>(function ReactAsset(
{
...rest
},
ref
) {
Thank you!
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
I'm currently attempting to implement React Hook Form to coincide with Player in a React Webapp. React Hook Form utilises a
register
function that passes props through to a component. An example of this could be:This
register
function spreads a few props to the element;name
,onBlur
,onChange
andref
.Due to the nature of how React Ref works, ReactAsset consumes the Ref. Docs here.
Describe the solution you'd like
I believe implementing the React forwardRef to the ReactAsset component would solve this issue. This is under the assumption that the current system does not have an alternative method to solve this issue. By my understanding, this should not cause issues with components who are not expecting a ref, allowing "backwards compatibility" from this change.
An example solution:
Thank you!
The text was updated successfully, but these errors were encountered: