I am working on a Perspective app for entering hourly production data. When a form is displayed, a db query is made to populate the form with pre-existing data. This data is loaded into a nested object structure in the session custom props. The data is then bound to a flex-repeater on the page, and through view params and subsequent flex-repeaters, it is propagated to all the various necessary form inputs and fields. As data in the form is added/edited, the data in the session object is modified, so that when the user saves, the data can be pulled from the session to make the necessary inserts, updates and deletes.
My question is, should I be using the session props in this way? I’m basically using it as if it were a Redux store for a node webapp. Data is queried, and then stuffed into the session props so that different views and components can access it and/or bind to it.
Are there performance concerns with using the session in this way? Are there other, more advisable places to store data that’s necessary for that client session? Is there a maximum data limit for the session?
The answer is generally no, but this is dependent on what kind of data are you talking about. If you’re talking about loading a 10,000 row list then definitely
I guess my thought here is that you’re kind of pulling in extra data you might not need for every page? As opposed to making this a custom prop on your top level view canvas/flex repeater for that specific page
Theoretical Answer: No, this would be based off the PC device memory limitations
Practical Answer: It depends on the type of device and how much memory it has. You could potentially load that 10,000 object list into memory on a loaded PC running chrome with no issues, but a 6 year old android might have a tough time churning through all of that
If you do have a lot of data to store, it’s highly recommended to set the visibility to ‘private’ - that way, the system won’t try to synchronize the property tree to the front-end, which eliminates a lot of churn on the websocket.
Right click in the property tree
Don’t try to do it for a component’s main props, but anything in custom should be safe to do, since all bindings and expressions are evaluating on the backend anyways.
Can you explain this in a little more detail? So if I set the access for an object stored in session.custom to private, will updates to that object still propagate to ui components that are bound to it? Does it just mean that it wont get synchronized to some object living on the client (which isn’t used for the bindings anyway)?
Yes, that’s correct. If a property is private, a binding can reference it, and the values will still end up coming to the front-end (into the component’s props) but won’t be continually synchronized in their ‘original’ location.
It’s undocumented and unsupported, but if you type __client in the browser console, you can ‘see’ the front-end’s model of everything that’s happening and what props are available - normally, basically everything. However, if you have large data, or ‘sensitive’ data that might still be required for bindings, you can use the visibility settings to prevent it from being synchronized to the front-end.
