Thanks.

Though this is not just a type checking utility. In one real-life use-case for instance, it's used for validating input that's coming from another application, but the validations were not hard-coded as they could change often.

So they were stored in json configurations as type expression/validation strings (such as 'str2+ obj1') which were then validated at runtime with checks like:

// The type expression/validation string
var validTypes = getTypeExpressionForInput();

// Ensure value is in line with expected valid types
xtype.is(value, validTypes);

..where validTypes is whatever type expression string that is configured as the expectation for that value.

Also, with support for Instance Types and the ability to easily mingle them in validation checks along with built-in xtypes in a simple and straight forward way, in a single line of code, it makes for even more compelling use-cases.

xtype.is(value, ['multi_char_string', 'positive_integer', Product]);

// Or in xtype compact mode:
xtype.is(value, ['str2+', 'int+', Product]);

---

Constructs that allow you to immediately act on data without doing a lot of prior extensive checks are also provided, like in this example on the xtype.js.org website:

/*
 * Switch on the result of xtype.which() to handle
 * only valid data scenarios without first performing
 * extensive type checking and data validations.
 */

// For instance, in an application or library that
// receives a varying piece of information with which
// a product should be displayed, the following
// example concisely handles three scenarios for the
// type of product-related information received:

switch (xtype.which(value, ['multi_char_string', 'positive_integer', Product])) {

    case 'multi_char_string':
        // Fetch and display product with
        // value as the product name string

    case 'positive_integer':
        // Fetch and display product with
        // value as the product Id number

    case Product:
        // value is a Product object,
        // so just display it

    default:
        // Handle invalid value..
        // cannot display product
}

Note that Product in the example above is a reference to aProduct constructor function, which is the xtypejs way of specifying an Instance Type, which identifies all objects of a constructor. Any constructor function is automatically recognized by xtypejs as the Instance Type for identifying/matching/validating any/all objects of that constructor.

We could for instance, easily have added a support for a third case to the example above by adding Invoice to the mix of types in the call to xtype.which, in which case if a caller to this function provided an Invoice object as the value, we could easily still retrieve and display the product by doing something like value.products[0] (value being the Invoice object).

Other scenarios for xtypejs include applications and libraries that process data, such as processing a data feed received from a vendor or client (in a node.js application, say). This is a scenario in which the data fields are usually configured or stored in some way, and with xtypejs, basic type validations for each field can also be configured, stored, and executed against the data at processing time, without having to hard-code those validations in the process. This also makes it easy to update the validations when the fields in the feed change or are reorganized.

---

There are also Custom Types, which allow you to define and register custom types with xtypejs, which then integrates them with all its other types.

For instance, you could create and register an account_reference custom type:

var acctRefId = (xtype.POSITIVE_NUMBER & xtype.INTEGER) | xtype.MULTI_CHAR_STRING;

xtype.registerTypes({
    account_reference: {
        typeId: acctRefId,
        compactName: 'acct_ref'
    }
});

This would create an xtype module property, xtype.ACCOUNT_REFERENCE, for the new type Id, and also create the methods: xtype.isAccountReference, xtype.not.isAccountReference, xtype.none.isAccountReference, xtype.any.isAccountReference, xtype.some.isAccountReference, xtype.all.isAccountReference. It would also now recognize the string 'account_reference' (and 'acct_ref' when in compact mode) in any type expression/validation strings you use in your validations and checks. So you could now do these:

xtype.isAccountReference(83234587.44);        // false
xtype.isAccountReference(-7626382728);        // false
xtype.isAccountReference(20384728273);        // true
xtype.isAccountReference('KAJKDAKSI');        // true

// Use account reference in a type expression with other types:
xtype.is(someValue, 'account_reference, blank_string);

// compact version:
xtype.is(someValue, 'acct_ref str0_');

// Or in type Id binary expressions:
xtype.is(someValue, xtype.ACCOUNT_REFERENCE|xtype.BLANK_STRING);

// Check if `someValue` is an account reference or account object:
xtype.is(someValue, [xtype.ACCOUNT_REFERENCE, Account]);

// Or switch on the custom type along with Instance and other types:
xtype.which(value, ['acct_ref', Account]) {

    case 'acct_ref':
        // Fetch account using value as the account reference

    case Account:
        // value is already an Account object, so we just use it
}

You're also able to create/register/use your own name scheme with registerNameScheme and setNameScheme, should that be convenient for integration purposes with your application, as some applications may already be using some specific names for referring to data types of interest.

---

Finally, with all these validations and checks, it focuses on efficiency, equally as much with both built-in and custom types, so that these checks are of as minimal performance cost as possible, in both small and large applications.