Spring ’12: Overview of Single View State

While viewers of the Spring ’12 Preview Webinar saw the new single view state in action, I thought it best to give a overview here on the blogs for people to read as well.

If you are a Visualforce developer and you aren’t familiar with the concept of a viewstate, it is one worth getting your head around as you try to make your pages as performant as possible.  As HTTP is a stateless format, the viewstate is a section of data, represented as a long hashed string, on your Visualforce pages which allows Visualforce to maintain the state between the client and the server.  Perform a rerender?  The viewstate keeps things in check.  Posting back information to Apex?  The viewstate is making sure the values being bound are kept straight.  Developers who have used JavaScript Remoting know that the fundamental difference between using actionFunctions and Remoting is that with Remoting there is no viewstate and maintaining state is up to JavaScript and the developer.

A long standing best practice for Visualforce developers has been to keep the number of Apex form tags to a minimum – preferably only one.  The reason for this is that multiple form components results in multiple viewstates which in turn add bloat and complexity to the pages.  With Single View State, which will be a pilot with Spring ’12 requiring Salesforce to enable, multiple form components will have their viewstate reduced down to a single one.  This feature, once enabled, will require no additional coding or setup – it’s not an attribute on the page or form component or anything like that … it is simply a performance gain for Visualforce in general.

I would still recommend developers think and test how they define their forms, however.  There may be instances where placing forms in components now becomes more desirable because it will not result in a performance drop.  There may also be existing limitations, like placing form components within a repeater component – where the outcome might not work as expected.

Spring ’12 is looking to be an excellent evolution of the platform and I’ll be interested to see as this pilot rolls out if we’ll see a sudden performance increase for existing implementations.  Keep an eye out on trust.salesforce.com for when Spring ’12 will hit an instance near you, the release portal and this blog for more information.  As usual, you can comment below or catch me on twitter @joshbirk.



tagged , , Bookmark the permalink. Trackbacks are closed, but you can post a comment.
  • Abhinav Gupta

    I am still don’t see any use of multiple forms in VF page if you are using remoting or native ajax(actionFunction, commandLink/action). As they both don’t rely on presence of forms, but the view state only. Apart from this one can use Action Region tags, where they want to submit or process limited data.

    A plus of having single view state would be for developers coming from other languages, who are used to of creating multiple forms. They will not end up in downgrading the page’s performance.

    What do you suggest ?

  • Yeah, I’m not entirely sure there is any positive effect to having multiple forms. The actionFunctions/command components need access to a form tag, remoting does not.

    The only real reason I can think of would be if maintaining the code in general is easier with multiple forms, say down to the component level. You bring up an interesting use case – and yeah, single view state would certainly aid in that.

    In general, I don’t think Single View State should completely roll back the concept of maintaining fewer form components – still think that designing pages with fewer form tags makes some sense, it’s better to think of Single View State (as it gets rolled out) as something which will help make pages leaner and faster without the need of refactoring.

  • Scott Hemmeter

    For those of us using one big form, does this change improve anything? We have 1 ViewState today and will after this change too, right? This change is more about optimizing the pages for people who unknowingly used multiple forms. Maybe I am missing something, though.

    • You’re correct – if you’ve already been adhering to the practice of one form (and hence one viewstate), you won’t see a difference here. This is more of a behind the scenes optimization for multiple form tags.