Makes client side SharePoint a bit nicer to work with (that's the plan, at least)
JavaScript
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
build
lib
src
test
.editorconfig
.gitattributes
.gitignore
.jscs.json
.jshintrc
.travis.yml
CONTRIBUTING.md
CONTRIBUTORS
Gruntfile.js
LICENSE
README.md
bower.json
karma.conf.js
package.json

README.md

Build Status

Resources

Documentation

Test coverage

Distribution files (BLEEDING EDGE)

Development version (unminified)

Production version (minified and mangled)

For stable builds, look at the list of releases. As of this moment, none are released. Please refer to the milestones for information.

Technical details

  • uglify reports that sputils.min.js is 31.68 kB
  • sputils aim to be compatible with MDS (Minimal Download Strategy).
  • sputils re-export the library functional.js as the symbol sputils.fjs
  • sputils rely on the following libraries/APIs (excepting SharePoint) under the hood:
    • fetch, which is enabled on older platforms by the polyfill fetch. This is a global API, so is usable from all code using window.fetch.
    • Promise, which is enabled on older platforms by es6-promise-polyfill. This is also a global API, and is accessible at window.Promise.

Intro

The intent of this project is to gather best practice in JavaScript interaction with SharePoint. The goal is to provide a unified API through which developers can work. Although there is much to read on the best practices of server side SP development, the same can not be said for client side.

Pull requests are welcome, but please follow the instructions listed further down.

The project is arranged into namespaces, all children of sputils. The currently planned namespaces are:

  • conversion
  • list
  • rest
  • search
  • termstore
  • user
  • helpers
  • lib

Each namespace will be extensively documented with examples and through tests. This will be assisted by the build system.

rest

This namespace contains the infrastructure required to easily interact with SharePoint's REST API, both through a series of helper functions designed to take care of the common use cases, and through a low level interface which is little more than a thin wrapper around XHR.

search

Because of the size of the SP search REST API it merits its own namespace. This module will combine convenience with best practice, covering the common cases of interaction with the SharePoint search engine and, as far as it is applicable, using sensible defaults.

termstore

Making it a breeze to interact with the SharePoint termstore. Get the terms for a specific term group, either as a list or a tree. Automatically handles custom sort orders configured in the terms.

helpers

Miscellaneous convenience functions, eg promise based SP dependency loading.

lib

generic functions that can be used for many different things.

Setup

$ git clone https://github.com/eakron/sharepoint-utilities.git

Install Node.js for your OS

$ sudo npm install -g grunt-cli bower

Specific to the project:

$ npm run build

Building

Running npm run build will create two build artifacts in the dist/ folder: sputils.js and sputils.min.js.

It will also generate docs and coverage in their respective directories.

Committing/pushing

This project uses husky that automatically runs tasks when committing/pushing. If any errors from these tasks occur, the commit or push will halt and rollback.

Pull requests

Read CONTRIBUTING.md before making a pull request.

New code is expected to follow the general style of existing code. Please take the time to familiarize yourself with the code base. Make sure you are not reinventing the wheel, some functionality you need may already exist. It is recommended to use an EditorConfig plugin for your text editor. All new API functions must be covered by tests.