Custom Field Rendering As An Alternative To Sharepoint Calculated Columns

The Problem with Calculated Columns

Calculated columns in SharePoint allow users to create formulas that compute values from other columns. However, they come with limitations: calculated columns can suffer from performance problems, have restricted functions, cannot reference external data sources, and provide a rigid presentation layer.

Custom field rendering provides an alternative method to deliver computed values in SharePoint lists and libraries. By using custom code instead of formulas, capabilities expand greatly with field rendering over calculated columns.

What is Custom Field Rendering?

Custom field rendering enables developers to customize how SharePoint displays field values using JavaScript or TypeScript code. Instead of computing a value through a formula like with calculated columns, logic can be implemented to derive values from other sources and output them in any desired format.

The field rendering code can interact with the full SharePoint framework and platform. This allows pulling data from REST APIs, user profiles, or external sources to incorporate into rendered field values. Formatting options are also extremely flexible.

Benefits of Using Custom Field Rendering

Here are some of the major advantages of using custom field rendering over calculated columns in SharePoint:

• Avoid performance issues with large lists using calculated columns
• Extend capabilities by using any JavaScript library
• Access external services and data sources from logic
• Dynamic and context-aware formatting options
• Cleaner separation of concerns over calculated columns
• Easier troubleshooting with custom code vs. formulas
• More control over value update behavior
• Can update display without altering underlying data
• Reusable components across solutions

Creating a Custom Field Rendering

Building a custom field rendering involves the following high-level steps:

1. Create rendering file structure
2. Define rendering manifest
3. Develop field renderer
4. Register and deploy rendering
5. Configure field to use rendering

The renderer logic handles retrieving field values and transforming them. The output is returned as a renderable string or DOM structure to display. The rendering components are packaged up and deployed to SharePoint through solutions or online app catalogs.

Walkthrough: Building a Tax Calculator Field

As an example, we can build a custom field rendering that calculates sales tax. Given a price field, it will compute corresponding taxes and format a view to incorporate both values dynamically.

First, implement field renderer logic to extract the price, calculate 8% tax, and format currency with a label:

  let price = ctx.CurrentItem.Price;  
  let tax = price * 0.08;
  return `$${price} (Tax: $${tax.toFixed(2)})`; 

This renders the raw tax calculation. Next, package rendering into a SharePoint solution. Add required manifests to register rendering and make it available for field configuration.

Finally, apply the tax rendering to the Price field in list views. Now it dynamically updates formatted price with computed tax values rendered inline!

Displaying Calculated Values in Views

A major benefit of custom field rendering is getting computed values directly within SharePoint views. Some tips for effectively showing this data:

• Use dynamic templates and bindings in renderer logic
• Implement conditional formatting rules
• Design mobile and responsive layouts
• Pull supplemental data into tooltips
• Give clarity on source of derived values

Proper UI treatments make the complex field rendering behave intuitively for end users. Apply UX principles to improve understandability with snapshots of transformed data shown inline.

Considerations When Migrating Calculated Columns

When planning a transition from calculated columns to field rendering, keep these items in mind:

• Audit existing calculated columns for migration feasibility
• Determine performance-critical formulas to prioritize
• Identify external data source integration needs
• Take inventory of dependent views and processes
• Establish maintained governance policies

Use a phased rollout approach focusing on targeted issues with formulas initially. Eventually custom rendering can subsume and replace all eligible calculated columns during modernization.

Custom Rendering Performance Optimizations

Since renderer code executes per field in every item, it can become a bottleneck as list scale increases. Tactics for optimizing performance include:

• Memoization of expensive computations
• Using async/await for long-running logic
• Debouncing busy field setters
• Graceful handling for unavailable data sources
• Setting sensible cache headers for HTTP requests

Analyze rendering behavior under load tests against production data sets. Apply optimizations incrementally and measure for tangible throughput and latency gains.

Extending Capabilities with Additional Web Parts

Field rendering works great for list views, but additional web parts can provide richer experiences for calculated data. Develop custom web parts to create:

• Interactive dashboards
• Filterable overviews with client graphing
• Printable reports aggregating values
• Fullscreen computed field explorers

Use similar techniques of encapsulated logic and dynamic UIs. Augment values from the data source lists leveraging larger component canvases. Deliver modern progressive web apps against high-value computed data.

Sample Code for a Custom Number Formatter

Here is some sample code for a custom field renderer that formats numbers:

export default class NumberFormatter {

  public render(ctx) {

    const num = parseFloat(ctx.CurrentItem.Number);

    return `

      ${num.toLocaleString()}
      ${num.toExponential(2)} 
    
`;

  }

}

This shows techniques for piping field values into JavaScript number functions. The output composes a custom visualization mixing locale and exponential formatting.

Many creative solutions become available by treating SharePoint columns as abstract data sources. HTML and DOM APIs provide the final layer of polish.

Next Steps After Replacing Calculated Columns

Once transitioning fields over to custom rendering, the increased capabilities spur opportunities to better leverage computed data. Next steps may involve:

• Converting more complex formulas
• Exploring machine learning for predictions
• Connecting to reusable logic cloud services
• Building automation relying on accurate analytics
• Visualizing key reporting metrics

By unlocking custom code, the possibilities for targeting niche scenarios or emerging needs around derived SharePoint data expand greatly.