Using window.confirm as a Promise

When writing a modern JavaScript application that uses Promises or async/await, it is sometimes useful to wrap other things in promises so they can more easily be used in a standard way throughout your codebase or in promise chains.

This is especially true if a built-in feature has the same properties of a promise, but is not one. The window.confirm API is one that I wrap a lot in my applications:

function confirmDialog(msg) {
  return new Promise(function (resolve, reject) {
    let confirmed = window.confirm(msg);

    return confirmed ? resolve(true) : reject(false);
  });
 }

And now we can use it just like a normal promise:

confirmDialog('Do you really want to delete this?')
  .then(() => doYourDeleteAction(task.id))
  .catch(err => alert('Unable to delete!'))

Now if you ever want to replace that confirm dialog with some custom version with a fancy UI like a modal window, you can do so much easier – just by updating the confirmDialog function itself.

Effective Browser JavaScript Debugging

How to effectively debug your web application is increasingly becoming a critical skill for any web developer, especially with the rise of ever-more complicated JavaScript applications with code transpiling and obfuscation. I wanted to teach the other developers at my company how to do this to be more effective at work, and developed it into a full talk that I have given at many conferences all across the world. My local user group OKC.js was the first time this talk was recorded and made available online. Please check it out:

Don’t Bet Against Language Features

Remember when all the blogs in PHP land were telling you to use single quotes because double quotes are slow? I was a heavy PHP user at the time, and man I sure do. The advice was actually factually correct at the time, but has long been fixed in PHP, and it would never have mattered in your application anyways. I have seen this scenario play out again – this time with JavaScript Promises.

Be wary anytime you hear something along the lines of “use X instead of Y, because Y is slow” – where Y is a built-in programming language feature. This argument crops up from time to time, but it is almost always a complete non-issue in the long run. Continue reading

Stronger Encryption and Decryption in Node.js

If your encryption method produces the same encrypted result given the same original text input, your encryption is broken. Yet this is what I see in most other examples around the web on how to do encryption in Node.js. Strong encryption should always produce a different output, even given the same exact input. Continue reading

Titanium Proxy Objects With JavaScript Call and Apply

Sometimes language and platform abstractions bite you. They can seem pretty straightforward and “just like the real thing”, but sometimes they have odd behaviors that don’t quite work the way you expect.

Dynamic method invocation with .call() and .apply()

The .call() and .apply() functions are something you will use a lot if your code involves a lot of dynamic arguments, such as building an array of arguments that then need to be mapped to actual ordered function arguments in a function or method call.

Since Titanium runs native JavaScript with the V8 engine bundled in your app, you will naturally find yourself attempting things like this:

var args = [sql].concat(params);
var db = Ti.Database.open('dbname');
var rs = db.execute.apply(db, args);

But if you run that, and you will be presented with the head-scratching error:

invalid method 'execute:'

Although the error is pretty confusing – you know there is a method named execute on the db object – there actually is a good explanation for this behavior.

Titanium Proxy Objects

What intiutively seems to you like a normal JavaScript variable here – db – is actually a proxy object created and returned by Titanium with the Ti.Database.open call. Titanium also returns proxy objects for pretty much every other component that has a native counterpart they are bridging over to behind the scenes. This black magic is fundamental to how Titanium works internally.

The Solution

Although the main Titanium proxy object explanation suggests creating a wrapper object for the method call, that’s actually not necessary at all, and creates a lot of extra work, as well as many additional lines of code.

The best solution is to use a bit of JavaScript meta programming and call the apply method directly from the Function prototype:

var args = [sql].concat(params);
var db = Ti.Database.open('dbname');
var rs = Function.prototype.apply.call(db.execute, db, args);

This is a nice one-liner that achieves the same end result, is much easier to undertand, and does not require a wrapper object or another layer of indirection to achieve.

Count the Number of Object keys/properties in Node.js

When using the excellent formidable library to handle file uploads, I needed to get a count of the number of files unloaded in a multi-part form. Javascript arrays have a .length property that you can use, but objects do not. I instinctively typed:files.length

Which returned undefined. So if there is no length property present, an easy way to count the number of keys or properties of an object in ES5-compliant javascript environments like Node.js is to use the Object prototype directly:

Object.keys(files).length

A little more typing, but it is fast, efficient, and most importantly: already built-in.

The One Character Block Comment

When debugging, I often find that I have to comment and un-comment a block of code several times during the process of trying to find out what’s going on. That used to mean typing and deleting comment block characters repetitively, but not anymore. Here’s a simple solution to that problem: Comment or un-comment an entire code block of code by typing or deleting a single character.

I was able to arrive at this solution by combining the one-line comment with the comment block in a way that takes advantage of the rules the different types of comments have to follow.

Continue reading

jQuery UI Datepicker with AJAX and LiveQuery

I’ve been a little aggravated lately trying to get jQuery UI Datepicker to work correctly on dynamically added fields for creating additional line items to invoices for InvoiceMore. It works great for fields already displayed on the page, but it tends to have major issues with dynamically added fields through AJAX or AHAH. Of course it won’t work out of the box with elements added dynamically to the DOM, so we can use jQuery’s $.live() event (new in 1.3 – you previously had to use liveQuery) to make it work. The Datepicker works by binding to the focus() event by default, but as of jQuery 1.3.2, the ‘focus’ event cannot be monitored by the ‘live’ event function. So we’re stuck with a little work around:

You would think just a simple "$(this).datepicker()" call wrapped inside the live() event would work, but it doesn’t. Turns out that in order to get it working consistently, you have to add the ‘showOn: focus’ config option as well as manually focusing on the element with the focus() event. Charming.