# Using Session Custom Props to Stage Data (Advisable or no?) **URL:** \ **Category:** Ignition\ **Tags:** ignition80, perspective\ **Created:** [September 11, 2020, 7:55pm UTC](https://forum.inductiveautomation.com/t/using-session-custom-props-to-stage-data-advisable-or-no/38611 "2020-09-11T19:55:53Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![kjordan](https://avatars.discourse-cdn.com/v4/letter/k/6f9a4e/32.png) [@kjordan](https://forum.inductiveautomation.com/u/kjordan)\ **Post date:** [September 11, 2020, 7:55pm UTC](https://forum.inductiveautomation.com/t/using-session-custom-props-to-stage-data-advisable-or-no/38611/1 "2020-09-11T19:55:53Z")
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? Thanks! ---
**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\ **Post date:** [September 14, 2020, 2:55pm UTC](https://forum.inductiveautomation.com/t/using-session-custom-props-to-stage-data-advisable-or-no/38611/2 "2020-09-14T14:55:35Z")
> [@kjordan](#): > > Are there performance concerns with using the session in this way? 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 > [@kjordan](#): > > Are there other, more advisable places to store data that’s necessary for that client session? 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 > [@kjordan](#): > > Is there a maximum data limit for the session? 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 ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [September 14, 2020, 3:12pm UTC](https://forum.inductiveautomation.com/t/using-session-custom-props-to-stage-data-advisable-or-no/38611/3 "2020-09-14T15:12:22Z")
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. ---
**Author:** ![kgamble](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kgamble/32/8019_2.png) [@kgamble](https://forum.inductiveautomation.com/u/kgamble)\ **Post date:** [September 14, 2020, 3:23pm UTC](https://forum.inductiveautomation.com/t/using-session-custom-props-to-stage-data-advisable-or-no/38611/4 "2020-09-14T15:23:41Z")
> [@paul-griffith](#): > > If you _do_ have a lot of data to store, it’s highly recommended to set the visibility to ‘private’ Say what, how do you do this and how have I never heard about it? Hahaha ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [September 14, 2020, 3:24pm UTC](https://forum.inductiveautomation.com/t/using-session-custom-props-to-stage-data-advisable-or-no/38611/5 "2020-09-14T15:24:51Z")
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. ---
**Author:** ![kjordan](https://avatars.discourse-cdn.com/v4/letter/k/6f9a4e/32.png) [@kjordan](https://forum.inductiveautomation.com/u/kjordan)\ **Post date:** [September 14, 2020, 5:25pm UTC](https://forum.inductiveautomation.com/t/using-session-custom-props-to-stage-data-advisable-or-no/38611/6 "2020-09-14T17:25:38Z")
Thanks so much for the feedback folks! 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)? Thanks again! ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [September 14, 2020, 5:38pm UTC](https://forum.inductiveautomation.com/t/using-session-custom-props-to-stage-data-advisable-or-no/38611/7 "2020-09-14T17:38:04Z")
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.