What is the need for view state in salesforce. There are lot of definitions how to lower the size, what is etc. But why we need view state is not illustrated. can anyone help me on this.
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It only takes a minute to sign up.Sign up to join this community
@Alexander Berehovskiy shared a great article about view state.
What is the need for view state in salesforce
Your question is explained in this excerpt:
A user requests a web page with a simple form on it, and fills out the form and submits it. If the user's input fails the validation rules for the form, the server responds with an error message - the user corrects the error and resubmits it successfully. Behind the scenes the browser is issuing HTTP requests.
The page is initially retrieved with a GET request and form submissions happen via POST requests. These POST requests are also called postbacks since the data on the form is being posted back to the same page. From the user perspective, this is a stateful interaction since the page state is changing based on its previous state. However HTTP is a stateless protocol, which means that the initial GET and the two subsequent POSTs are treated as independent requests for the page. As a result, some other mechanism is needed to persist state information across HTTP requests.
Visualforce is server side so every action you take using controller is sent to server for processing then result is sent back with generated HTML. This is the workflow for visualforce pages:
User requests a page
The server executes the page’s underlying code and sends the resulting HTML to the browser
The browser displays the HTML
When the user interacts with the page, return to step one
This is why you need to manage state. View state makes developers job easy on managing state for visualforce page.
If you don't want to work with view state or you don't need to keep state in your page then you can check: Refactor your pages to make its view stateless or Consider doing your own state management in certain cases
there is a nice article about view state in SF
Visualforce pages that contain a form component also contain an encrypted, hidden form field that encapsulates the view state of the page. This view state is automatically created, and as its name suggests, it holds the state of the page - state that includes the components, field values and controller state.
The data in the view state should be sufficient to recreate the state of the page when the postback is received. To do this, it stores the following data:
All non-transient data members in the associated controller (either standard or custom) and the controller extensions. Objects that are reachable from a non-transient data member in a controller or controller extension. The component tree for that page, which represents the page's component structure and the associated state, which are the values applied to those components. A small amount of data for Visualforce to do housekeeping. View state data is encrypted and cannot be viewed with tools like Firebug.