In Service Studio, all the local variables of a screen and the result of any query or action called in the preparation of the screen is kept in the scope of the entire screen, i.e. they can be referenced in the preparation, the screen itself and the Screen Actions.
Impact - Think viewstate
The screen scope is very handy for the developer, but should not be abused in Screen Actions.
Keep in mind that a Screen Action execution is the result of a request to the Web Server, different from the initial request to the screen that generated the Local variables and preparation data.
Web Servers do not keep this kind of context from a request to another at server side. Instead, any scope information required in all Screen Actions will be placed in the Viewstate that is sent back and forth between requests. Even if some data is only required by one of the Screen Actions, it will be sent to all the Screen Actions as the viewstate is unique per screen. Sometimes information kept in the viewstate is not even used, simply because the Screen Action requiring that information is never hit.
In conclusion, the use of scope information in a Screen Action grows the viewstate size, increasing the network traffic between the server and the browser - Ajax requests become slower and page load keeps degenerating.
To limit the Viewstate growth, make sure you are not referencing large data from the scope in your Screen Actions. It is OK to reference Screen local variables or the result of an action called in the preparation that has a small type (e.g. an integer or an Id) but you should never reference any Structure, record list or large text.
Instead, do the following:
- Reload queries and rerun actions - it is better to repeat the work at server side, than saving these calls by reusing the result from the preparation at the cost of sending large information back and forth in the viewstate
- Pass information in Screen Action parameters - If a certain information is only used by a screen action, passing it in a parameter instead of referencing the scope, will guarantee that it will not be passed to other screen actions in the viewstate.
Parameters are also a clean way to pass the minimum context information to rerun queries or execute actions inside the Screen Action. E.g. pass the TableRecord.List.Current.Customer.Id in a parameter instead of referencing it inside the Screen Action wich would make the entire TableRecord.List to be placed in the Viewstate