Autogrow textarea Angular directive with vertically centered text

This post is about emulating input[text] with a textarea element to create a text wrapping input that adjusts its height to the amount of content it holds. A working example can be found on Plunker.

When was the last time you asked yourself about input[text] element's user experience and usability? Well in normal situation (that is likely 90% of the time) this element works great but in the remaining cases it may not be ideal. Whenever you need your users to enter long(er) one-liners input[text] may not be your best option as it can't wrap text so part of it outside element's boundaries is being hidden. If nothing else, it's distracting to users.

You mainly have two options here each with its ups and downs:

• textarea element - very similar to input[text] as it allows entering unformatted text that can wrap as many lines as its length requires; it has some styling problems though (I'll explain that in a bit) and also allows entering multiple lines of text which may be undesirable but easy to handle/prevent
• content editable div element - it can easily be styled to look exactly like input[text] and it also wraps long lines of text (normally) just like textarea; the main problem is controlling its behaviour to prevent text formatting in a cross browser way

Of the two options the first one seems simpler so let's implement it.

Angular ngRoute routing authorization with asychronous promises

AngularJS routing doesn't support route authorization out of the box and nor does its popular cousin ui-router even though the latter supports state change cancellation with later continuation (using $urlRouter.sync(); check documentation). But in non-trivial Angular SPAs this feature is regularly needed. So I went off implementing it.

Data binding a single shared view to different controllers using "ControllerType as instanceName" syntax

If you haven't already I strongly suggest you first read John Papa's AngularJS styleguide. It's a magnificent document of an evolving set of AngularJS development best practices. Among them there's also one that says to abolish $scope use and rather provide view model data as part of controller instance because view bindings become more contextual amid other reasons. To accomplish this you need to use the ControllerType as instanceName syntax. This is usually a blessing but sometimes it may seem to be a curse especially when you give controllers contextual instance names (i.e. UserController as user) instead of some common name (i.e. UserController as vm). This is especially useful if you're nesting controllers and don't want to access parent controllers using scope's $parent property.

Contextual instance naming plays along nicely until you introduce shared views. Now when you want to bind your shared view to a controller instance you don't really know its name. It can be any controller instance name that will be using this shared view. Now what?

jQuery UI slider extension that enhances range capabilities

I'm going to provide you with the code that makes it possible to set bounds to range slider handles (minimum and maximum) and some more sugar along with it.

I needed to create a range slider that is a bit smarter than the one provided by jQuery UI library that only allows to set minimum and maximum values for the whole slider, but I needed to set a few things more. I had to provide a range slider that would allow users to select time range between midnight and midday the next day (36 hours all together). These were my requirements:

• Lower handle can only move to midnight the next day (so it can move between 00:00 and 1d 00:00) - this simply means that time range must start today
• Selected range must be at least 1 hour wide
• Selected range can't be wider than 24 hours all together

These were my requirements and although I like jQuery UI plugins/widgets and even though it comes with a slider it doesn't work as expected. I could of course put it all in my slide handler, but tha wouldn't be reusable and it would also not allow me to do some additional things I implemented along. Want to know which ones?

Use CSS floats to flow data in columns rather than rows with jQuery .transpose() plugin

I know we have CSS3 multi-column layout that makes HTML content flow in columns dead simple but the problem is that only the most modern browsers (as of July 2011) support this CSS3 capability. As you might have guessed this means tough luck for Internet Explorer users. Microsoft decided that CSS3 column layout is not something developers or better web designers would need so IE still doesn't support it. Not even in version 9 that is.

Even though CSS3 multi-column support got supported recently we have been displaying data in pseudo columns for some time. We either displayed tables when we had tabular data or used CSS floats or CSS inline-blocks when displaying lists and we didn't want the list to be long and narrow which makes it hard to use. The nice thing about floating is that elements take as much horizontal space as they can inside container and when individual items are set a fixed width this means that they will display in column-like layout. The problem is though that floated items run in rows meaning that when you have alphabetic text (or numbers) list items they won't flow in columns as we're used to ie. in phonebooks. No. Items flow in rows. This makes these kind of lists hard to read and search through. But I have a solution for you. jQuery plugin that re-arranges your items into columns to improve their usability.

jQuery animated "scroll into view" plugin (with additional ":scrollable" selector filter)

Sometimes our pages have to deal with long(er) unpaged lists of data. Long enough to fall off the viewable browser window estate. Actually you don't even have to deal with lists at all. Let me re-define the problem: when you have a scrollable element on your page (may be the very body of it) and you need to programmatically scroll to its out-scrolled child element, then this jQuery plugin is just for you. Now let's see when we have to do this and what could go wrong.

jQuery parseJSON automatic date conversion for Asp.net and ISO date strings

This one's quite common. You asynchronously communicate (a.k.a. Ajax) with your server and get JSON data in return. You most probably use $.parseJSON() on the client side which actually parses JSON string and returns an object. We've all used that. But (yes, there's always a but) there's a catch. There's no defined standard for date serialization, so jQuery will not parse your dates back to dates. What the heck even native JSON parser (these days supported in all major browsers) won't do that. So you have to do it yourself. Manually. Or, modify default jQuery functionality a bit and get it done automatically.

Sending complex JSON objects to Asp.net MVC using jQuery Ajax

jQuery has great support for sending HTML form data (that is input, select and textarea element values) back to the server using Ajax technologies by providing two main ways of preparing form data for submission - namely serialize() and serializeArray() functions. But sometimes we just don't have a form to send but rather JSON objects that we'd like to transfer over to the server.

Asp.net MVC on the other hand has built-in capabilities of transforming sent data to strong type objects while also validating their state. But data we're sending has to be prepared in the right way so default data binder can it and populate controller action parameters objects' properties. We can of course parse values ourselves but then we also loose the simplest yet efficient built-in validation using data annotations which is something we definitely want to use.

I know I've been sending JSON objects back to the server before, but this time I came across a problem that felt odd, since based on my previous experience should work out of the box. To my surprise it didn't. Let me explain what was going on.

Handling validation errors on Ajax calls in Asp.net MVC

If you're developing rich web clients using Asp.net MVC on the back-end, you've probably come across this functionality that can be described with these conditions:

1. client side data (may be a form),
2. ajax posting of this data (form),
3. controller action has strong type parameters,
4. controller action processes data and returns anything but a full view (since it was an Ajax call)

Familiar? Then you've come across this problem: »What should be done when validation fails?«
Seems fairly straight forward, right? Well not so fast my fellow developer friend...

Asp.net MVC model binding to List<T>

Asp.net MVC is really a great platform to build performant and very controllable web applications. But sometimes some functionality is scarcely documented if at all. Internet proves (thank you Google) to be an invaluable wealth of information in this regard since other developers are usually solving similar problems. But sometimes you either don't find usable information or you want to test things for yourself as well and learn something new as you go along.

Something similar happened to me on my previous project. I had to dynamically generate a list of objects in the browser and then reliably POST them back to web server so that data would be reliably model bound and validated as well. I wanted to avoid manual validation at all costs because it would unnecessarily overcomplicate server code.