From the docs for Visualforce Remoting: "Because you aren’t using forms and there’s no view state associated with the request, you have to manage the state of the page yourself, on the client side. On the other hand, there’s nothing that prevents you from combining JavaScript remoting with the standard Visualforce MVC design paradigm."

I am not sure I understood the above very well. If we do not use form (to get rid of View State issues), what can be done to maintain state between requests? Like, for standard MVC frameworks like JSF, state management is handled by the managed beans(request scoped, session scoped etc). But in Salesforce, if we get rid of the form tag, how can we manage page state? Any pointers, suggestions would be helpful.


The "state" in this case is stored in memory on the client, in whatever scheme you want to use. As an example, let's say that you have a page that increments a counter when you click a button.

Here's the difference:

Visualforce-Managed State

<apex:page controller="CounterController">
    <apex:form id="form">
        {!counter} <apex:commandButton action="{!increment}" reRender="form" value="Add 1" />

public class CounterController {
    public Integer counter { get; set; }
    public CounterController() {
        counter = 0;
    public void increment() {

Client-Managed State

    var counter = 0;
    function incrementCounter() {
        document.getElementById("counter").innerHTML = counter;
    <span id="counter">0</span>
    <button onclick="incrementCounter()">Add 1</button>

"But, wait, sfdcfox, where's my state gone?" you may ask.

The state is now simply var counter, stored in the client. You'll also notice that the page is now more responsive and won't randomly lose clicks or "rubber-band" back to a previous value when you double-click the button.

Of course, this is an oversimplified example, but the point here is that I'm managing my own state instead of depending on Visualforce to do it for me. Of course, I can still use JavaScript remoting if I need to get data back from the database, but now I have more control over how the state is rendered.

It's generally recommended that you maintain your own state when there's a risk of exceeding the 135KB View State Governor Limit, or really any time that you need a UI that's responsive in real-time (< 16ms), such as auto-complete fields, etc. It's a little more JavaScript, which you can use jQuery or the like to reduce the work you need to do, but you gain a more responsive UI.

  • Thanks a lot for explaining so nicely @sfdcfox. I think I have got the idea. So essentially we have to focus on keeping the logic mostly on the client-side and keeping contacting the server via POST requests to a minimum. – SFDC Dev 27 Jun 27 '17 at 4:14

If you do not use apex:form, you will need to decide on a state-storing scheme for yourself. If your page only uses basic input fields, you don't really need to store state since all the information is already in the fields, and can be sent to the server via an Ajax "submit" button. Since you are using Javascript rather than post backs, you actually don't need to refresh the page while you are using it, which means you don't need to send a ViewState back and forth to the server whenever an action occurs. This makes this model somewhat simpler to implement yourself.

Other than that, you can use basic Javascript objects to hold state, the same way any JS framework does. You can do that by having a literal state variable, or using a namespace object and putting your variables inside of it. In either case, if you do need to send the whole state to the server, you can serialize it to JSON on the page and then deserialize it in your server-side method call. You can also import a Javascript framework if you would like, and use that to run the page with remoting calls to get any extra information you need from the server.

  • Good idea to use a JS framework with VF Remoting. I will explore further on this. Thanks! – SFDC Dev 27 Jun 27 '17 at 4:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.