Sheet Class

Calculated fields require proxies. To use them in IE11, you will need a polyfill such as this one: https://www.npmjs.com/package/proxy-polyfill.

Calculated fields can be useful when dealing with external data. For example, you could add a per-capita income field (gnp/pop) or a profit field (revenue-expenses).

Calculated fields are dynamic. If you change the fields used in the calculation, their values are updated automatically. They are also read-only. You may change the value of the properties used to calculate them, but you cannot directly edit the result.

Unlike FlexGrid cellTemplates, calculated fields can be used for sorting, filtering, and grouping. They can also be used with charts and any other Wijmo controls.

Calculated fields can be defined as functions that take a data item as an argument or as strings.

For example, if your data looked like this:

// regular data item
interface IDataItem {
      product: string,
      brand: string,
      unitPrice: number,
      qty: number,
      shipped: boolean
}
function getData(): IDataItem[] {
    return [
        {
            product: 'Banana',
            brand: 'Chiquita',
            unitPrice: 45.95,
            qty: 12,
            discount: .08,
            shipped: true
        }, ...
    ]
}

You could add function-based calculated fields this way:

// add calculated properties to IDataItem
interface ICalcDataItem extends IDataItem {
    fullName: string;
    allCaps: string;
    totalPrice: number,
    tax: number;
}

let cv = new CollectionView<ICalcDataItem>(getData(), {
    calculatedFields: {
        fullName: ($: ICalcDataItem) => [$.brand, $.product].join(' '),
        allCaps: ($: ICalcDataItem) => $.fullName.toUpperCase(),
        totalPrice: ($: ICalcDataItem) => ($.unitPrice * $.qty) * (1 - $.discount),
        tax: ($: ICalcDataItem) => $.totalPrice * 0.12
    }
});

Function-based calculated fields are usually a better choice than string-based calculated fields because:

1) They provide design-time error checking and command completion, 2) They run faster, and 3) They do not have any issues with content-security policy (CSP).

Alternatively, you could add string-based calculated fields:

let cv = new CollectionView<IDataItem>(getData(), {
  calculatedFields: {
    fullName: '[$.brand, $.product].join(" ")',
    allCaps: '$.fullNameStr.toUpperCase()',
    totalPrice: '($.unitPrice * $.qty) * (1 - $.discount)',
    tax: '$.totalPrice * 0.12'
});

String expressions may refer to the current item via the context variable '$', which contains the item's original and calculated values.

String-based calculated fields have advantages over function-based calculated fields that may be important in some scenarios:

1) They are slightly more concise, and 2) They can be stored as data and easily changed at run-time.

This property does not affect the filters property, which are always applied.

The callback should return true if the item passed in as a parameter should be included in the view.

The default value for this property is null, which means the data is not filtered.

To be included in the view, an item has to pass the predicate in the filter property as well as all predicates in the filters collection.

The method takes as parameters a data item, the property being validated, and a parsing parameter that describes whether the data has already been parsed and applied to the data item (parsing == false), or whether the user was trying to edit the value and entered a value that could not be parsed into the data type expected (parsing == true).

The method returns a string containing an error message, or null if no errors were detected.

For example,

view = new CollectionView(data, {
    getError: (item: any, prop: string, parsing: boolean) => {

        // parsing failed, show message
        if (parsing) {
            if (prop == 'date') {
                return 'Please enter a valid date in the format "MM/dd/yyyy"';
            } else if (prop == 'id') {
                return 'Please enter a positive number';
            }
        }

        // check that stored (parsed) data is valid
        if (prop == 'date' && item.date < minDate) {
            return 'Please enter a date after ' + Globalize.formatDate(minDate, 'd');
        } else if (prop == 'id' && item.id < 0) {
            return 'Please enter a positive number';
        }
    }
});

If the creator function is not supplied, the CollectionView will try to create an uninitialized item of the appropriate type.

If the creator function is supplied, it should be a function that takes no parameters and returns an initialized object of the proper type for the collection.

The default value for this property is zero, which disables paging.

The default value for this property is true, which ensures the collection is always sorted, filtered, and grouped correctly after any edit operations.

Set it to false if you want updates to be deferred when items are edited. In this case, the collection will not be refreshed until the sorting, filtering, and grouping criteria change or until the refresh method is called (Excel behavior).

If provided, the sort comparer function should take as parameters two values of any type, and should return -1, 0, or +1 to indicate whether the first value is smaller than, equal to, or greater than the second. If the sort comparer returns null, the standard built-in comparer is used.

This sortComparer property allows you to use custom comparison algorithms that in some cases result in sorting sequences that are more consistent with user's expectations than plain string comparisons.

For example, see Dave Koele's Alphanum algorithm. It breaks up strings into chunks composed of strings or numbers, then sorts number chunks in value order and string chunks in ASCII order. Dave calls the result a "natural sorting order".

The example below shows a typical use for the sortComparer property:

import { CollectionView, isString } from '@grapecity/wijmo';

// create a CollectionView with a custom sort comparer
const view = new CollectionView(data, {
    sortComparer: (a: any, b: any) => {
        return isString(a) && isString(b)
            ? alphanum(a, b) // use custom comparer for strings
            : null; // use default comparer for everything else
    }
});

The example below shows how you can use an Intl.Collator to control the sort order:

import { CollectionView, isString } from '@grapecity/wijmo';

// create a CollectionView that uses an Intl.Collator to sort
const collator = window.Intl ? new Intl.Collator() : null;
let view = new CollectionView(data, {
    sortComparer: (a, b) => {
        return isString(a) && isString(b) && collator
            ? collator.compare(a, b) // use collator for strings
            : null; // use default comparer for everything else
    }
});

If provided, the function should take as parameters a SortDescription, a data item, and a value to convert, and should return the converted value.

This property provides a way to customize sorting. For example, the FlexGrid control uses it to sort mapped columns by display value instead of by raw value.

For example, the code below causes a CollectionView to sort the 'country' property, which contains country code integers, using the corresponding country names:

const countries = 'US,Germany,UK,Japan,Italy,Greece'.split(',');
view.sortConverter = (sd: SortDescription, item: any, value: any) => {
    return sd.property === 'countryMapped'
        ? countries[value]; // convert country id into name
        : value;
}

The next example combines two values so when sorting by country, the view will break ties by city:

view.sortConverter: (sd: SortDescription, item: any, value: any) => {
    if (sd.property == 'country') {
        value = item.country + '\t' + item.city;
    }
    return value;
}

This property is set to SortNulls.Last by default, which causes null values to appear last on the sorted collection, regardless of sort direction. This is also the default behavior in Excel.

The default value for this property is false, so the CollectionView does not keep track of which data items have changed.

If you set this property to true, the CollectionView will keep track of changes to the data and will expose them through the itemsAdded, itemsRemoved, and itemsEdited collections.

Tracking changes is useful in situations where you need to update the server after the user has confirmed that the modifications are valid.

After committing or cancelling changes, use the clearChanges method to clear the itemsAdded, itemsRemoved, and itemsEdited collections.

The CollectionView only tracks changes made when the proper CollectionView methods are used (editItem/commitEdit, addNew/commitNew, and remove). Changes made directly to the data are not tracked.

Stable sorting algorithms maintain the relative order of records with equal keys. For example, consider a collection of objects with an "Amount" field. If you sort the collection by "Amount", a stable sort will keep the original order of records with the same Amount value.

The default value for this property is false, which causes the CollectionView to use JavaScript's built-in sort method, which is fast and usually stable.

Chrome provides stable sorting since version 70, and Firefox since version 3. As of ES2019, sort is required to be stable. In ECMAScript 1st edition through ES2018, it was allowed to be unstable.

Setting the useStableSort property to true ensures stable sorts on all browsers (even IE 11), but increases sort times by 30% to 50%.