I have quite a general question surrounding the Data Layer model for Player.
As I've been using Player quite extensively for the past 9-10 months or so, I have to say it's an incredibly impressive feat for server driven UI!
One thing I'd like to understand more is the data layer for a Player instance. So based on previous discussion I know there's an AST involved that essentially parses out all expressions and binding instances, being {{...}} and @[...]@.
So... after trailing a bit of time trying to navigate through the source code, I thought I may as well ask - How is the actual data objects stored for a Player instance? Is the data layer essentially hoisted at the top of the Player instance and used as a store? Or does it utilise context (on the React side), to make all data paths accessible to the AST when parsing bindings.
The only reason I'm asking is purely due to a potential suggestion - Where currently I tend to have alot of re-renders when using heavily nested assets, which tends to be quite common with complex UI. I know a big culprit for excessive re-renders is the usage of Context, because Context will essentially always force a full re-render of children on any changes.
Depending on how the current model works, my only suggestion was going to be something along the lines of using a Player Instance wide "store" to deal with persistent storage. Zustand is a great example of a "global" store that has a great feature of Transient Updates, meaning the React components under the hood don't re-render unnecessarily, because the components have to subscribe the data changes. (I know the data layer for Player is above any React implementations, I'm just mentioning Zustand because it's a good example of eliminating performance issues with React).
I know this may not be completely applicable to the Player system, but I thought it may be worth a shot just shooting by my thoughts.
If anyone has any additional suggestions for mitigating excessive re-renders, that'd be amazing!
React state management is quite funky, and when UIs get complex, they always tend to leave performance on the table!
Hey people!
I have quite a general question surrounding the Data Layer model for Player.
As I've been using Player quite extensively for the past 9-10 months or so, I have to say it's an incredibly impressive feat for server driven UI!
One thing I'd like to understand more is the data layer for a Player instance. So based on previous discussion I know there's an AST involved that essentially parses out all expressions and binding instances, being
{{...}}and@[...]@.So... after trailing a bit of time trying to navigate through the source code, I thought I may as well ask - How is the actual data objects stored for a Player instance? Is the data layer essentially hoisted at the top of the Player instance and used as a store? Or does it utilise context (on the React side), to make all data paths accessible to the AST when parsing bindings.
The only reason I'm asking is purely due to a potential suggestion - Where currently I tend to have alot of re-renders when using heavily nested assets, which tends to be quite common with complex UI. I know a big culprit for excessive re-renders is the usage of Context, because Context will essentially always force a full re-render of children on any changes.
Depending on how the current model works, my only suggestion was going to be something along the lines of using a Player Instance wide "store" to deal with persistent storage. Zustand is a great example of a "global" store that has a great feature of Transient Updates, meaning the React components under the hood don't re-render unnecessarily, because the components have to subscribe the data changes. (I know the data layer for Player is above any React implementations, I'm just mentioning Zustand because it's a good example of eliminating performance issues with React).
I know this may not be completely applicable to the Player system, but I thought it may be worth a shot just shooting by my thoughts.
If anyone has any additional suggestions for mitigating excessive re-renders, that'd be amazing!
React state management is quite funky, and when UIs get complex, they always tend to leave performance on the table!
Cheers!