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
This may be abusive usage of Player - if so, please let me know
This "problem" only crept up from version 0.8.0 - Looking at the deeper logs from the rendering infinite loop, seems to be coming from react-subscribe. Which is caused from the usage of reactPlayer.start(...).
Use-case
Currently I have instances of nested Player React components. The main use-case for this is due to a quirk of the ReactAsset component - Where if I have a plugin component which has Player schema JSON built into it, any attempts to access data via the {{}} special characters won't work. Which makes sense as the parsing is done pre-render, and as the rendering of the component with the nested schema JSON happens after the {{}} parsing. It wouldn't get picked up.
Imagine I have an initial page which is a Player component, which houses a Modal which contains a form. If the Modal/Form was its own React component with more schema JSON inside of it referencing more assets, that JSON would be outside of the scope of the initial page/view JSON.
Maybe if this kind of behaviour should be avoided... if so we may want to issue warnings or preventions about this type of view structure. We'd also need an alternative to post-parsing {{}} instances within a JSON through the ReactAsset component.
To Reproduce
This code sandbox illustrates the infinite suspense issue - But does not show the infinite rerender issue. I have a feeling that the complex level of my own implementation in my codebase may be the cause for that rendering loop, but quite difficult to port to a CodeSandbox.
A nested Player instance inside another Player instance should behave uniquely to the parent - This was the given behaviour up until 0.8.0. If this isn't feasible anymore, we should look to document the limitation and/or prevent it via warnings and throwing errors if a nested player issue is discovered.
Screenshots
The text was updated successfully, but these errors were encountered:
Describe the bug
This may be abusive usage of Player - if so, please let me know
This "problem" only crept up from version 0.8.0 - Looking at the deeper logs from the rendering infinite loop, seems to be coming from
react-subscribe
. Which is caused from the usage ofreactPlayer.start(...)
.Use-case
Currently I have instances of nested Player React components. The main use-case for this is due to a quirk of the
ReactAsset
component - Where if I have a plugin component which has Player schema JSON built into it, any attempts to access data via the{{}}
special characters won't work. Which makes sense as the parsing is done pre-render, and as the rendering of the component with the nested schema JSON happens after the{{}}
parsing. It wouldn't get picked up.Imagine I have an initial page which is a Player component, which houses a Modal which contains a form. If the Modal/Form was its own React component with more schema JSON inside of it referencing more assets, that JSON would be outside of the scope of the initial page/view JSON.
Maybe if this kind of behaviour should be avoided... if so we may want to issue warnings or preventions about this type of view structure. We'd also need an alternative to post-parsing
{{}}
instances within a JSON through theReactAsset
component.To Reproduce
This code sandbox illustrates the infinite suspense issue - But does not show the infinite rerender issue. I have a feeling that the complex level of my own implementation in my codebase may be the cause for that rendering loop, but quite difficult to port to a CodeSandbox.
Codesandbox
Expected behavior
A nested Player instance inside another Player instance should behave uniquely to the parent - This was the given behaviour up until 0.8.0. If this isn't feasible anymore, we should look to document the limitation and/or prevent it via warnings and throwing errors if a nested player issue is discovered.
Screenshots
The text was updated successfully, but these errors were encountered: