Closure; the missing piece

White jigsaw puzzleWhile doing a code review this week, the developer asked me if we could refactor some TypeScript. Basically take some repetitive client side code, pop it into a new file and make it easier to implement elsewhere.  The project is using the powerful DevExpress ASPxGridView control in a lot of places (multiple controls on a page and multiple pages) and in batch edit mode. The users wanted the ‘Save / Cancel’ panel to be at the top of the screen instead of the default location in the grid footer. Simple enough process, we can create a user control to handle a couple of nicely themed ASPxButtons, link to a helper class for the common work on the grid and we should be done.

First we take a look at the original markup, the client side client event is being wired to a TypeScript method

Inside the TypeScript file, the method was doing some checks and calling another method on the grid control, gvTemplates.UpdateEdit(); This is where the repetition was, each grid had its own ‘save’ method.

helper.saveGrid = function ( ) {

In order to optimise the code, we have to pass in the name of the grid being edited, then find the grid in the DOM and execute the method on it.

The first part was to update the markup to call to the helper class

The key difference here is the introduction of the brackets into the assignment, we are no longer just pointing the click event to our TypeScript method, but actually executing it, which is bad. This is where the closure comes in. For more information about closures I suggest you read the following article from Julian Bucknall.

For our needs, the code should look something like this

helper.saveGrid = function (gridId: string) {
        return function (s, e) {
            var grid: ASPxClientGridView = ASPxClientControl.GetControlCollection().GetByName(gridId);

The ‘gridId’ parameter is going to contain the grid’s client side ID, the saveGrid() method then returns a function that is passed back to the click event handler on the button. There are a few cool things going on with the new code. Firstly (and this is where you can come unstuck very quickly) is the use of the parameter that is passed in. The inner function can use the value from the outer function. The second thing to note is the nice helper class provided by DevExpress to get access to the control, so you don’t need to go searching through the DOM. Code cleaned, duplication removed and a much nicer way to handle calls from multiple controls and/or pages.

While this serves as a very quick tutorial on being able to call common methods, I really want to highlight a) the power of the closure, b) the frustration they can cause to JavaScript / TypeScript beginners.

For more detailed information on closures and best practices please see these fantastic articles:

Caught out with closures

The module pattern

Approaching Angular 2 from a WebForms perspective


Omelettes anyone?

Sometimes we spend so long working in a technology it is a difficult to make a switch. If it ain’t broke, don’t fix it, right!?  The problem is, the world moves on. Using server side technologies like ASP.NET WebForms is something I still love to do, add a few DevExpress components onto a page, set the properties, bind some data and boom, almost no code and I have a working web application. There are many debates scattered on the internet about WebForms been deprecated, that they are evil, I simply disagree. Now, if you are wanting to target a wider range of web servers and operating systems, use .Net Core, have light weight UI then you would start looking at some of the popular frameworks like Angular 2. Herein lies the dilemma, how does someone with many years experience as a WinForms and WebForms developer make the jump to a client side driven application? I’m pleased you asked…

Julian and I are presenting a free webinar on this exact topic on November 3. Specifically we will take an existing WebForms application and create an Angular 2 version using the DevExtreme Web controls.

The goal is to show how a C# (or VB) developer with a background in WebForms can get started in the client side world. As with most of my presentations lately, we will also be using TypeScript.

Take part in the fun by Registering here,  seats are limited.

DevExtreme, Ionic, TypeScript and Angular 2

This week, Julian and I took to the airwaves again to show just how easy it is to combine some pretty heavy hitting names to produce cutting edge mobile applications.

The presentation was recorded and is available to watch on the DevExpress YouTube channel.  In a couple of weeks time, we will be showing you how to make the most of multi-platform notifications with some real world business scenarios.

Mobile Evolution: Obj-C –> TypeScript with DevExtreme

It still amazes me, the number of developers who have put writing mobile apps into the ‘too hard’ basket. The scenario is the same around the world… someone at a corporate level decides it would be cool to have an ‘app’, but when you start looking into it, well, it’s a nightmare. There is framework after framework, promise after promise, and then when you start looking at the costs and small print, its a mine field! The question that has been raised for years is still as relevant as ever… “do I go native or hybrid?”, well that still depends on your project, your skill set and budget, but if you are wanting to break into the mobile market at attack all three major players at once, I recommend hybrid. People who know me would be shocked at that last statement since I love native iOS development, but the truth is simple, you cannot hit multiple platforms from the comfort of Objective-C. That’s when I decided to take on a challenge, to create a hybrid version of an existing iOS application that I developed years ago, and since TypeScript was officially released in Visual Studio Update 2, I decided it should be the language of choice.

Join me on April 29, 10am (PDT) as I turn a native iOS application into a DevExtreme generated hybrid and get maximum exposure from a single codebase.

Register Today