For the Microsoft SharePoint Conference in Las Vegas I did a session on using TypeScript to develop for SharePoint and Office. In that session I demonstrated a non-trivial example of a library I built in TypeScript for accessing SharePoint's REST services. I did this because TypeScript is about building enterprise scale applications – something that JavaScript doesn't do particularly well (to be as kind as possible.) I got several requests by the other speakers at the conference and the attendees about what I intended to do with the library. And I'm happy to confirm that I'll be releasing the code as an open source community project. The intent is to create a library that can be used anywhere to build applications for SharePoint.
However, before I decide where to put the library, I need to know who would be willing to help with the enhancement of the library. I don't want to create a project on CodePlex to find I'm the only developer – if that becomes the case I'll just host the project here on my site. I'm really looking for who would be willing to contribute. I should be clear much of the code won't be super-technical, highly architectural. A lot of it is just slogging out support for various interfaces and following the pattern I've already created. Not that there won't be fun problems to solve but I also don't want to discourage folks who don't feel like they're architect-level developers yet. Before go into more details, let's talk about the library itself.
What is TypeScript?
If you missed it, TypeScript is a super-script of JavaScript that compiles down into regular JavaScript. The benefit is that it adds type safety through compilation time checking – and intellisense in Visual Studio. It's a great tool for those who are tired of debugging for hours to realize that they had a capitalization problem or a typo on a method that they just couldn't see while looking at the code. I believe that it's the future way to develop JavaScript. We'll develop in TypeScript and compile down into JavaScript as an intermediate language.
Who Can Use the Library?
Because the library is TypeScript based it compiles into regular JavaScript. That means anyone that has a platform that uses JavaScript can use the library. Whether it's Office and SharePoint applications like the library was built for or whether it's a Windows 8 HTML/JS application. The one requirement is the use of jQuery as a base library. It's also likely that the library will ultimately require the datajs library that's being developed to make OData access easier. Otherwise, the library is intentionally easy to use.
What Does the Architecture Look Like?
The primary challenges for most developers who are getting involved with JavaScript are the lack of type safety and the increased dependence on asynchronous calls to keep work of the primary display thread. Building the library in TypeScript resolves the concern of type-safety. The dependence on asynchronous calls is handled through the use of promises. jQuery includes a Deferred object. This object implements JavaScript promises.
The short is that a promise is a "publish-subscribe" object which allows you to subscribe to events you're interested in and get notified when they're completed (typically through anonymous methods). Once the event occurs your code is run. The beauty of this is you can right code that looks something like:
Obj.DoSomethingAsync().done(function () { alert('success'); }).fail(function () { alert('oops'); }).then(function () { alert('next?'); });
This will cause the right methods to be called when the async method completes. This approach keeps the async response code together with the code that started the async event. The beauty of this is that the deferred object can be held and if other code wants to subscribe to the event later it can. If the event is already completed the code that is subscribing to the event will run immediately. This allows you to do caching internally in your objects to minimize repeated calls.
With this as the basis the objects mirror the objects in the server side object model. The methods are intended to mirror the way that you deal with the objects on the server. There are a few differences because of the way that JavaScript works when compared to .NET/C# -- however, the differences are designed to be minimal. A developer who knows the SharePoint object model should be able to use Intellisense in Visual Studio to see what's happening.
Why not the JavaScript Client Side Object Model?
A rather obvious question is, "Why would I write a totally new library to access the REST services when there's already a JavaScript client side object model?" The short answer is that the JavaScript Client Side Object model doesn't always work. It works just fine if you're in a SharePoint hosted application. However, in situations where you don't have an app web the SharePoint JavaScript library won't work. Even when it does work – outside of the SharePoint hosted app – it's quirky. I wanted one library that worked whether I was working on remote server, a Windows 8 application, or on the SharePoint server itself. I didn't want to have to do things fifteen different ways.
Developers Needed
At the beginning I mentioned that I wanted some other folks who would be willing to help me flesh out the scope of the model. That work is something that doesn't require a huge amount of skill – it's something that's good exercise for developing against SharePoint remotely. If you're relatively new to development – I absolutely can use your help here.
In addition, I'm looking for some folks who are willing to help me keep an eye on the architecture of the library as it grows. I've got a long background in building architectures and libraries – but JavaScript isn't my native world. I'd love someone who can help with the finer points of architecting enterprise scale JavaScript. For instance, techniques for managing cross-domain calls.