Autopostback And Losing Values In Connected Sharepoint Web Parts

Understanding AutoPostBack Behavior

The AutoPostBack feature in ASP.NET allows a page to automatically post back to the server when certain events occur, without the user having to click a button or link. This provides a more responsive and dynamic user experience.

In SharePoint, AutoPostBack is commonly used with web parts to connect them together. For example, when a value is changed in one web part, it can automatically update other web parts on the page with the new information.

However, a downside to this behavior is that it can cause values entered into input fields and controls to be lost. When the postback occurs, the page goes through its full life cycle on the server, which resets the viewstate and clears any unsaved changes.

Page Life Cycle on PostBack

To understand why values are lost, we need to look at the ASP.NET page life cycle on postback:

1. Initialization – The page request is received and objects like Request, Response, Session, Server etc. are created.
2. Load viewstate – Viewstate data is loaded into the page properties.
3. Postback event handling – Events like button clicks are handled.
4. Load – At this stage the Page and Child Controls all have their Load event handlers called.
5. Postback change handling – Values changed on postback are processed.
6. Rendering – The Render method is called to display HTML output to the browser.

When the Load event fires on postback, control values have not yet been restored from viewstate. So any values that weren’t stored are effectively reset.

How Values are Lost on PostBack

There are a couple of ways that a postback from one web part can cause connected web parts to lose their data.

Example 1 – Chaining Web Parts

Web parts are connected through chaining – the selected item in one web part drives the choices available in the next web part.
For example, selecting a product category filters down products.

On postback all web parts reload, so any selected items are lost. The chained web part is reset, breaking the expected workflow.

Example 2 – Dependent Lookup Columns

A list has a Person column that looks up a related Person list. An edit form uses the selected person to display details.

On postback the lookup column is cleared, breaking the connection to that person’s details.

Storing Values Before PostBack

To prevent loss of data, input values must be stored before postback and restored afterwards. This can be done in JavaScript by handling the page unload and load events.

function storeValues() {

  // Get input elements
  var inputs = document.getElementsByTagName("input");
  
  // Store each element's value
  for(var i = 0; i < inputs.length; i++){
    sessionStorage.setItem(inputs[i].id, inputs[i].value);
  }
  
}

function onPostBack() {

  // Get input elements
  var inputs = document.getElementsByTagName("input");

  // Restore input values  
  for(var i = 0; i < inputs.length; i++){
    var storedValue = sessionStorage.getItem(inputs[i].id);
    if(storedValue != null) {
      inputs[i].value = storedValue;
    }
  }

}

// Store values before unload
window.addEventListener("beforeunload", storeValues);
// Restore values after load
window.addEventListener("load", onPostBack);

This code loops through the input fields, stores their values in sessionStorage before postback, and restores them after postback. Now field data persists across the trip to the server.

Custom Components

For custom SharePoint components and web parts, viewstate and control state can be used instead of session storage. Key methods are:

• SaveViewState() - Called before rendering to save control data
• LoadViewState() - Restores saved data after postback
• TrackViewState() - Adds a field to viewstate

// Store input value 
string inputValue;

protected override object SaveViewState()
{
  // Save inputValue
  Object state = new Object();
  state["input"] = inputValue;
  return state;
}

protected override void LoadViewState(object savedState)
{
  // Retrieve saved value
  if(savedState != null)
  { 
     inputValue = (string)((Object)savedState)["input"];
  }
  base.LoadViewState(savedState);
}

protected override object TrackViewState()
{
   // Add value to viewstate 
   return inputValue;
}  

Alternative Approaches

While storing values before postback often works, an alternative approach for complex scenarios is to avoid full postbacks completely.

UpdatePanel Control

The UpdatePanel wraps sections of the page into an ajax partial postback rather than full postback. This allows some parts of the page to refresh without losing data in others.

With this approach care must still be taken with viewstate and restoring control values correctly. But the rest of the page state will remain intact.

Client-Side Rendering

An advanced tactic is keeping the data on the client, and using client-side rendering instead of server postbacks. Solutions like React, Angular or Vue can connect to SharePoint data while providing a smooth user experience.

This keeps application state on the client side rather than losing it on each server round trip. Data is preserved within the user session across postbacks.