Welcome to the Hypergrid CDN.
This CDN hosts builds, including minified builds, of repos hosted under the fin-hypergrid GitHub organization.
That said, some developers may choose to use a version of fin-hypergrid.min.js, the Hypergrid core build file, and bundle all other modules into a single additional file for download. This approach has the advantage of having the page load the relatively invariant (and large, at 247KB for v3.0.0) core build, which the browser then caches for future reference. This is particularly advantageous if there are multiple apps using the same core file. Download once; use many times. Downsides include limited access to internal core modules (probably a good thing) and the difficulty in maintaining a flat dependency graph when working with more than one bundled build.
Specifically, this CDN hosts build files for:
A list of the build files on the CDN along with sample script tags can be found in the CDN index.
tags to load these files from the CDN at run time.
In this way, individual modules are loaded onto the client synchronously, one file per
In addition to the build files, this site hosts:
All build files are offed in two editions:
module-name.js— Unminified versions are for debugging purposes and, when bundled, include a source map.
module-name.min.js— Minified versions are smaller and faster and are for use on production.
<script>tags from the CDN index, as needed, into your application's
.htmlfile to have your application load them at run time.
The declarations below all assume:
var require = fin.Hypergrid.require; // (calling context undefined)
The Hypergrid core build exposes a selection of its internal modules with
var Base = require('fin-hypergrid/src/Base');
var defaults = require('fin-hypergrid/src/defaults'); // aka Hypergrid.defaults aka Hypergrid.properties
var Behavior = require('fin-hypergrid/src/behaviors/Behavior');
var Column = require('fin-hypergrid/src/behaviors/Column');
var Local = require('fin-hypergrid/src/behaviors/Local');
var assignOrDelete = require('fin-hypergrid/src/lib/assignOrDelete');
var cellEventFactory = require('fin-hypergrid/src/lib/cellEventFactory');
var dynamicProperties = require('fin-hypergrid/src/lib/dynamicProperties');
var dispatchGridEvent = require('fin-hypergrid/src/lib/dispatchGridEvent');
var fields = require('fin-hypergrid/src/lib/fields');
var graphics = require('fin-hypergrid/src/lib/graphics');
var Canvas = require('fin-hypergrid/src/lib/Canvas');
var InclusiveRectangle = require('fin-hypergrid/src/lib/InclusiveRectangle');
var Registry = require('fin-hypergrid/src/lib/Registry');
The following shared namespaces are instances of
var dataModels = require('fin-hypergrid/src/dataModels');
var features = require('fin-hypergrid/src/features');
Members are accessed via the registry's
These are all shared registries; they are shared by all grid instances on the page.
features registries are collections of object constructors.
cellRenderers registry is a collection of cell renderer instances.
(Recall however that access to an instance's constructor is available through its
The following namespaces from version 2.1 are deprecated as of version 3.0.0 and will be removed in a future release.
The comments show the deprecated vs. modern usage (where
modname is a module name):
fin.Hypergrid.lib // deprecated: fin.Hypergrid.lib.modname
// modern: fin.Hypergrid.require('fin-hypergrid/src/lib/modname')
fin.Hypergrid.behaviors // deprecated: fin.Hypergrid.behaviors.modname
// modern: fin.Hypergrid.require('fin-hypergrid/src/behaviors/modname')
fin.Hypergrid.dataModels // deprecated: fin.Hypergrid.dataModels.modname or fin.Hypergrid.dataModels.get('modname')
// modern: fin.Hypergrid.require('fin-hypergrid/src/dataModels/modname')
fin.Hypergrid.features // deprecated: fin.Hypergrid.features.items.modname or fin.Hypergrid.features.get('modname')
// modern: fin.Hypergrid.require('fin-hypergrid/src/features/modname')
fin.Hypergrid.rectangular // deprecated // modern: fin.Hypergrid.require('rectangular')
In the interest of aiding developers in maintaining a flat dependency graph
(_i.e.,_ avoiding loading multiple instances of the same module),
the core build also exposes its external dependencies,
using the same
require()-like syntax as above
(see package.json for versions):
var DatasaurBase = require('datasaur-base');
var DatasaurLocal = require('datasaur-local');
var extend = require('extend-me');
var _ = require('object-iterators');
var overrider = require('overrider');
var Point = require('rectangular').Point;
var Rectangle = require('rectangular').Rectangle;
var SparseBooleanArray = require('sparse-boolean-array');
var Synonomous = require('synonomous');
All of the above are actually read-only members of the `fin.Hypergrid.modules` namespace. The above `require` syntax is preferred, however, because it makes a possible future transition to bundling your app just a matter of removing the `var require` definition.
In addition, the following writable properties are provided for overriding:
fin.Hypergrid.modules.Scrollbar = myScrollBars; // initially exposes require('finbars')
fin.Hypergrid.modules.templater = myTemplater; // initially exposes require('mustache')
Hypergrid always references these two modules through the above properties.
How your modules reference other modules
— and how other modules reference your modules —
depends on whether or not the modules in question
are wrapped up as Hypergrid Client Modules.
(An HCM wrapper is a closure that defines local
See the Client Modules wiki for more information.
The Hypergrid core object is both a constructor and a namespace and always required. It is referenced as follows:
var Hypergrid = window.fin.Hypergrid;
var Hypergrid = require('fin-hypergrid');
Most modules whose source repositories are hosted under https://github.com/fin-hypergrid/, in addition to being published as npm modules, are also "built" into Hypergrid Client Modules and referenced as follows:
var myModule = fin.Hypergrid.require('my-module');
var myModule = require('my-module');
All other modules are referenced using a module-dependent global variable.
Unwrapped modules are free to insert themselves into
would let them be referenced as a Client Module; however they would not themselves be able
to reference Hypergrid or Hypergrid Client Modules using
The Hypergrid core bundled build is always required. A version number is required. Include only one of the following scripts in your application:Latest Hypergrid 3.3 version (recommended!):
|As of v3.2.1, also available on the unpkg CDN (via a
|The advantage of unpkg is it optionally accepts and applies any valid SEMVER string after an @ sign.
The above SEMVER spec
The unminified versions are a hefty ~2.2 MB (largely due to inclusion of the source map for debugging purposes). Always use a minified version (~0.25 MB) on production.
To see the API documentation for the lastest version, just link to the
core/doc folder (a sym-link to
To see API documentation for older versions, insert a version number +
To access the latest version's default demo, just link to the
core/demo folder (a sym-link to
To access older demos, substitute a version number for
dataModel.fetchData; w/simulated propagation delays & error retries
Again, to access older versions of the above demos, simply substitute a version number for
Plug-ins are published as npm modules (CommonJS modules) to the npm registry (npmjs.org). For example, to install the latest version of the fin-hypergrid-grouped-header plug-in:
npm install --save fin-hypergrid-grouped-header. The plug-in will now be available to your file bundler when referenced in code with `require('fin-hypergrid-grouped-header')`.
Plug-ins are usually published as Hypergrid client modules as well, for direct inclusion with
<script> tags. For example, including one of the following
<script> tags in html file will make the file available to your code with `fin.Hypergrid.require('fin-hypergrid-grouped-header'):
Note that like the Hypergrid build files themselves, these plug-in CDNs do not include sym-links to the latest version; a version number is always required.