計算フィールドにはプロキシが必要になります。 Ie11で使用する場合は、 https://www.npmjs.com/package/proxy-polyfill のようなポリフィルを使用します。

計算フィールドは、外部データを扱う場合に役立ちます。 たとえば、1人当たりの収入フィールド（gnp/pop）または利益フィールド（収益-経費）を追加できます。

計算フィールドは動的です。 計算で使用されるフィールドを変更すると、それらの値は自動的に更新されます。 また、読み取り専用です。 それらの計算に使用されるプロパティの値を変更することはできますが、結果を直接編集することはできません。

FlexGrid cellTemplatesとは異なり、計算フィールドは並べ替え、フィルタリング、およびグループ化に使用できます。 また、チャートやその他のWijmoコントロールで使用することもできます。

計算フィールドは、データ項目を引数または文字列として受け取る関数として定義できます。

以下に例を示します。

// 通常のデータ項目
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
        }, ...
    ]
}

次のように関数ベースの計算フィールドを追加できます。

// 計算プロパティを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
    }
});

関数ベースの計算フィールドは、次の理由により、通常、文字列ベースの計算フィールドよりも優れています。

1）設計時のエラーチェックとコマンド補完を提供します。 2）実行速度が速い 3）コンテンツセキュリティポリシー（CSP）に関する問題はありません。

あるいは、文字列ベースの計算フィールドを追加することもできます。

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

文字列式は、 項目の元の値と計算された値を含む コンテキスト変数「$」により、現在の項目を参照できます。 文字列ベースの計算フィールドには、関数ベースの計算フィールドよりも利点があり、場合によっては重要になることがあります。 いくつかの利点は次のとおりです。

1）少し簡潔です 2）データとして保存でき、実行時に簡単に変更できます。

このプロパティは、常に適用されるfiltersプロパティには影響しません。

パラメータとして渡された項目を画面に表示する必要がある場合、コールバックはtrueを返します。

このプロパティのデフォルト値はnullです。これは、データがフィルタリングされないことを意味します。

ビューに含めるには、アイテムはfilterプロパティとfiltersコレクション内のすべての述語を渡す必要があります。

このメソッドは、データ項目をパラメータとして、検証されるプロパティ、およびデータが既に解析されてデータ項目に適用されているかどうか（parsing == false）またはユーザーが値を編集しようとして予期されたデータ型に解析できない値を入力したかどうかを記述する解析パラメータ（parsing == true）を受け取ります。

このメソッドは、エラーメッセージを含む文字列を返します。エラーが検出されなかった場合はnullを返します。

次に例を示します。

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

        // 「解析に失敗しました」メッセージを表示します。
        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';
            }
        }

        //  保存（解析）されたデータが有効であることを確認します。
        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';
        }
    }
});

作成関数が提供されない場合、CollectionView は、適切な型の項目を 初期化せずに作成しようとします。

作成関数が提供される場合、その関数は、パラメータを受け取らず、 コレクションに対して適切な型のオブジェクトを初期化して返す必要があります。

このプロパティのデフォルト値は zero です。この場合、ページングが無効になります。

このプロパティはデフォルトで true に設定されます。これにより、 編集が完了した後にコレクションが常に正しくソート、フィルタリング、およびグループ化されるようにします。

false に設定する場合、アイテムの編集時に更新を遅延されます。 この場合、ソート、フィルタリング、およびグループ化の基準が変更されるか、 またはExcelと同様にrefresh メソッドが呼び出されるまで、コレクションは更新されません。

指定された場合、ソート比較関数は、パラメータとして任意の型の値を 2つ取り、最初の値が2番目の値と比べて小さい、等しい、または大きい のいずれであるかを示す値-1、0、または+1を返します。ソート比較関数がnullを返す場合は、標準の組み込み比較子が使用されます。

このsortComparer プロパティを使用すると、カスタム比較アルゴリズムを 提供でき、単純な文字列比較より、ユーザーが期待する結果によく 一致するソートシーケンスが得られる場合があります。

たとえば、 Dave Koele's Alphanum algorithmを参照してください。 このアルゴリズムは、文字列を文字列や数値から成る部分に分割した後、 数値部分は値順に、文字列部分はASCII順にソートします。 Daveは、この結果を「自然なソート順」と呼んでいます。

次の例は、sortComparer プロパティの一般的な使用方法を示します。

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

// カスタムソート比較子を使用してCollectionViewを作成します
const view = new CollectionView(data, {
    sortComparer: (a: any, b: any) => {
        return isString(a) && isString(b)
            ? alphanum(a, b) // 文字列に使用するカスタム比較子
            : null; // 文字列以外にはデフォルトの比較子を使用します
    }
});

次の例は、 Intl.Collator を使用してソート順を制御する方法を示しています。

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

// Intl.Collatorを使用してソートするCollectionViewを作成します
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) // 文字列に使用するカスタム比較子
: null; // 文字列以外にはデフォルトの比較子を使用します
    }
});

指定されている場合、この関数は、SortDescription、データ項目、および変換する値をパラメーターとして受け取り、 変換後の値を返す必要があります。

このプロパティはソートの動作をカスタマイズする手段を提供します。 たとえば、 FlexGrid コントロールはこのプロパティを使用して、 マップされた列を生の値ではなく表示値を基準にソートします。

以下のサンプルコードは、国コードの整数を含む'country'プロパティをソートするときに、 対応する国名を使用してソートされるようにします。

const countries = 'US,Germany,UK,Japan,Italy,Greece'.split(',');
view.sortConverter = (sd: SortDescription, item: any, value: any) => {
    return sd.property === 'countryMapped'
        ? countries[value]; // 国IDを国名に変換します。
        : value;
}

次の例では、2つの値を組み合わせています。 この場合、国でソートすると、ビューが都市ごとに分割されます。

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

このプロパティはデフォルトでSortNulls.Lastに設定されます。これにより、コレクションをソートすると、並べ替えの方向に関係なくNULL値が最後に表示されます。 この動作はExcelと同じです。

このプロパティのデフォルト値はfalseに設定されているため、

CollectionViewはどのデータ項目が変更されたかを追跡しません。 このプロパティがtrueに設定されている場合、CollectionView は、

データの変更を追跡し、itemsAdded、itemsRemoved、 itemsEdited の 各コレクションを介して変更を公開します。 変更の追跡は、変更が有効であることをユーザーが確認した後にサーバーを 更新する必要がある場合に役立ちます。

変更をコミットまたはキャンセルしたら、clearChanges メソッドを使用して、

itemsAdded、itemsRemoved、itemsEdited の各コレクションをクリアします。

CollectionView は、適切なCollectionView メソッド（editItem /commitEdit、 addNew /commitNew、remove）を使用して行われた変更だけを追跡します。

データに直接行われた変更は追跡されません。

安定したソートアルゴリズムは、同じキーを持つレコード間の相対的な順序を維持します。 たとえば、「Amount」フィールドを持つオブジェクトのコレクションを考えてみます。 このコレクションを「Amount」でソートする場合、安定したソートでは、 Amount値が同じレコード間で元の順序が保たれます。

このプロパティのデフォルトは false です。この場合は、 高速だが安定ではないJavaScriptの組み込みソートメソッドが CollectionView で使用されます。

useStableSort をtrueに設定すると、すべてのブラウザーで安定したソートが保証されますが、ソート時間が30%～50%も長くなります。

注意：Chromeはバージョン70以降、Firefoxバージョン3以降は安定したソートを提供します。 ES2019の場合 、ソートは安定している必要があります。 ES2018までのECMAScript第1版では、不安定になることが許可されていました。

useStableSortプロパティをtrueに設定すると、すべてのブラウザー（IE11も含む）で安定したソートが保証されますが、ソートにかかる時間が30％～50％増加します。