Category Archives: TypeScript

Angular Takes the Sting out of Writing Components

It’s astonishing how simple writing web components is with Angular. In a way, this shouldn’t be a surprise: components are the building blocks of every Angular application. However, last week we wrote a component I already knew to be difficult to implement in merely an hour or two. That was really a surprise.

Our choice was a multi-choice select box. There are plenty finished components out there. However, Angular 2+ is still young, so there are few (if any) native Angular multiple-choice boxes we can use. Integrating a component based on other technologies like jQuery is possible, but usually, it takes some time and it’s always a compromise. So I reluctantly agreed when my co-worker suggested to quickly write our own component. “It’s simple”, he said. “It ain’t much work”. It’s true. It wasn’t.

Key to success: template language

The key to success is the clever template language of Angular. More often than not, I’m unhappy with template languages because they always feel clumsy. Angular’s template language doesn’t. Of course, that’s simple because it doesn’t aim to be a general-purpose language. It’s been written specifically for a single purpose, and it serves this purpose well.

I don’t have the source code at hand, so let me sketch our source code from memory. The multiple-choice combobox consists of an input field, which is always visible, and a pane containing the options. The pane is hidden most of the time. So the HTML code (or rather: pseudocode) looks like so:

<input [(ngModel)]="selectedValues" 
       (onfocus)="optionsVisible=true"
       (onblur)="optionsVisible=false">
<div [attrs.visible]="optionsVisible">
  <div class="checkbox" *ngFor="let option in options">
    <label>
      <input type="checkbox" [(ngModel)]="option.selected"
             onchange="updateResult()"> 
      {{option.value}}
    </label>
  </div>
</div>

This little snippet reads and writes like plain vanilla code. But in reality, it’s revolutionary. It takes a lot more code in Java to write an equivalent JSF component. I also compared this code to my AngularPrime/Dart framework I wrote a couple of years ago. Dart is a fine language, but it took much more time and effort to write a simple component.

The component class

Of course, the HTML code is useless without the TypeScript glue code. But again, this code is fairly straight-forward. The sketchy pseudocode looks like this:

export class Option {
  label: string
  selected: boolean = false
}

@Component({
  selector: "multiple-choice",
  templateUrl: "multple-choice.html"})
export class MultipleChoice {
  @Input() options: Options[]

  @Output() result = new EventEmitter(string)

  optionsVisible: boolean = false

  updateResult(): void {
    let result = options.filter(option => option.selected).
             reduce((option, previous) => previous + "," + option.label, "")
    result.emit(result)
  }
}

Another key to success: @Input and @Output

We’re almost there! All we need to add is a little CSS file to arrange the panel properly below the input field. Everything else is handled by Angular: we can pass the list of options to the component using the @Input decorator, and @Output sends the result to the outer component:

<multiple-choice [options]="colors" 
                 (result)="setSelectedColors($event)">
</multiple-choice>

Wrapping it up

Of course, I’ve omitted some details to keep things simple, and I’ve shown only pseudocode. But even the real source code is surprisingly simple. Angular focuses on writing components. Therefore, it makes writing components as simple as possible without sacrificing power. I had the opportunity to compare different approaches, and I’m astonished by the ease of use of Angular.

Electron Brings JavaScript to the Desktop

Let’s continue my “Java on the desktop” series with something that’s not Java, but interesting nonetheless. Electron is a framework wrapping your HTML5 application in a native window of your operation system. Other than most projects in the JavaScript universe, Electron does not follow a “mobile first” approach. Quite the contrary, it’s fairly opinionated in that it supports only three platforms: Windows, OSX, and Linux. This includes access to your computers file system and access to the Windows registry via third-party NPM modules. If I’ve got it right, it even allows you to install your application as a Windows service, which is kind of scary. You know, not too long ago every security expert recommended deactivating JavaScript in the browser because of alleged security risks. Obviously, we’ve come a long way.
Continue reading

TypeScript and ES2016 Decorators vs. Java Annotations

Consider this TypeScript snippet. It’s a very simple Angular2 component. It looks almost like a Java class, doesn’t it?

@Component({
    selector: 'my-app',
    template: '<h1>My First Angular 2 App</h1>'
})
export class AppComponent { }

In particular, the @Component looks like a Java annotation. In fact, it plays the some role as a Java annotation. It tells the Angular2 framework that this class is not an ordinary POJO, but something special. It’s a component, one of the building blocks of Angular.

Striking similarity

That’s exactly the same thing I already knew from the Java world. @Named converts a POJO into a CDI bean. Sometimes Java annotations even have the same fancy curly braces syntax:

@ResourceDependencies({ 
  @ResourceDependency(library = "bsf", name = "js/datatables.min.js", target = "body"),
  @ResourceDependency(library = "bsf", name = "css/datatables.min.css", target = "head")
})
public class DataTable extends UIData {}

So why do the JavaScript and TypeScript communities insist on calling their annotations “decorators”?

Decorators decorate!

The answer is simple: Decorators are called decorators because that’s what they are. You can use them as annotations. But in reality, they are function calls. The Angular2 framework contains a function called Component() that takes a function as a parameter and returns another function. The @ of @Component tells TypeScript and EcmaScript 2016 to call the Component() function and to pass it the function after the decorator. Usually decorators are used to add functionality to a function.

AOP

Does this ring a bell? Exactly – that’s more or less the same as aspect oriented programming. In fact, AOP is one of the classical use cases of Java annotations. Just think of @transactional. This annotation surrounds a method with the glue code needed to execute it in a transaction. In other words, it adds some code before executing the method (opening a transaction) and it adds code after the method (committing the transaction, or rolling it back).

Oops!

Making the @ symbol an alternative way to call functions is a very elegant way to implement both static annotations and AOP. Plus, it should be possible to pass variables as additional parameters. In Java, annotations only support constants that can be resolved a compile time, and every once in a while, that’s a nuisance.

In hindsight, it’s hard to understand why the Java team added simple annotations instead of full-blown decorators to Java 5. I suppose they didn’t want to add a complex multi-purpose tool. Annotations can be used for exactly one purpose. They resemble a comment. They rely on a framework to be useful. This framework can be the editor, the compiler or the runtime environment. Only a few years later the JavaScript world showed how useful decorators are.

Can decorators be added to Java?

Sure. Java 8 introduced default methods. So we could define a default method in an annotation class and execute it when the annotated method is called. We’d have to consider a couple of corner cases, though. Annotations can be applied to classes, static fields, class attributes and method parameters. We’d have to define useful semantics for each of these corner cases. But that’s not a big deal.

Wrapping it up

However, I don’t think this will ever happen. Annotations have become such an important part of the Java world it’s unlikely anybody takes the risk. So, for now, we can only marvel at the way the language designers took the syntax of the annotation and converted it into something even more useful. By the way, the flexibility of the JavaScript language allows for some tricks Java developers can only dream of. Only – Java applications tend to be a lot bigger than JavaScript applications, so this dreams would quickly turn into a nightmare. Nonetheless, the article I’ve linked in the “dig deeper” section is very interesting, and it’s full of surprises – at least for a programmer like me spending most of their day in the Java ecosystem.

Dig deeper

Exploring EcmaScript 2016 decorators in detail

Newsflash: How to Develop Efficiently In TypeScript

In one or two of my recent posts, I claimed that the TypeScript compiler is extremely fast, and that that Google Chrome caches your TypeScript code to aggressively.

Both things have changed since then. The bad news is that the editor I use, Atom, has started to compile the entire project each and every time I edit a file. I don’t know whether this is a configuration error of mine, or if it’s a bug of Atom, or even a peculiarity of the current version of TypeScript. I’m positive the error is on my side, but as long as I haven’t found the reason I reluctantly have to revoke my claim that TypeScript compiles in virtually no time.

Now for the good news. The Angular2 team recommends to use “live-server”, and it works just great. Install it via

npm i typescript live-server --save-dev

Next, open the file package.json, find the scripts section and replace it with

{
  "scripts": {
    "tsc": "tsc -p src -w",
    "start": "live-server --open=src"
  }
}

Now you can start your project by starting npm start at the command line. This starts the server, opens the browser, opens the index.html of your project within the browser and – that’s the really cool part – restarts your application each time you edit a file.

Read the full story at the Angular2 quickstart tutorial.

Getting Started with TypeScript

The other day I showed a TypeScript program to our architect. He doesn’t like JavaScript, but when he saw my TypeScript program, he was pleasantly surprised. TypeScript looks pretty familiar to Java programmers, making it a good language to get started with client-side programming. Plus, the core feature of TypeScript is types, making development much more fun. I know fans of dynamic types disagree, but wait until you’ve seen the autocompletion and refactoring features of your editor before you judge. Be that as it may: TypeScript comes with powerful type inference, too, so most of the time you can use it as a dynamically typed language and still benefit from types. If you’re still sceptical: hard-core JavaScript may be relieved to learn types are optional.

After a couple of works I’d say that TypeScript is the language of choice for me. In earlier times, I’ve propagated Dart, which is an even nicer choice as a language. Unfortunately, Dart suffered from needing a virtual machine of its own, and the lacking interoperability with existing JavaScript code. So, it didn’t make a bit impact on the market yet, so I prefer a language that compiles natively to JavaScript.

So, I’ve decided to write a tiny tutorial on TypeScript. It’s not an exhaustive step-by-step tutorial. I can’t beat the official TypeScript manual, so I won’t even try. Instead, I’ll give you a short tour-de-force from a Java programmers perspective.
Continue reading

Getting Started with AngularJS 2.0: Tools and Compiler

Update Aug 4, 2016

Recently, this article received a couple of harsh comments calling it “useless”. So I should point out that I’ve published this article some time ago when Angular2 was still being developed. At the time, it wasn’t even an alpha version. So expect an introductory-level article which may even be partially outdated. If so, please leave a comment so I can correct it. It’s a popular article, so your comment is going to help a lot of developers. Thanks!

Update Oct 06, 2016

Currently, I’m evaluating a couple of tools that weren’t available to me when I wrote the first version of the article: Webstorm, IntelliJ, angular-cli and ionic-cli. I’ll cover them in an article soon, and update this blog entry subsequently. Until then, keep in mind that I wrote the article when Angular2 was still an alpha version, so don’t be disappointed if parts of the article are outdated.

Live in the early days of AngularJS 2.0

Probably it’s still a bit early to investigate AngularJS 2 thoroughly. The release date of AngularJS 2 is still open, documentation is scarce and I’m told many important APIs are still unfinished. But that’s the fate of an early adopter. On the other hand, it’s already possible to work with the current Alpha versions, and if I’m not mistaken the fundamental decisions of what AngularJS 2 is going to look like already have been made. So I thought by myself that the time is ripe to explore AngularJS 2. Along the way, I wrote a little chess program consisting of 1500 lines, give or take a few.

Cutting a long story short: AngularJS 2.0 is fun, even today. It’s a big step forward.

Today’s article is not so much about the architecture of AngularJS – BeyondJava.net is going to cover this soon – but concentrates on how to set up an efficient development environment. Coming from a Java developer team, I’ll report many things JavaScript developers are already familiar with. Bear with me.
Continue reading

The Rise of TypeScript?

I’ve made up my mind to start a series of AngularJS 2 articles. As you may or may not know, AngularJS 2 is not being developed in JavaScript, but in TypeScript, a language compiling to JavaScript. While it’s perfectly possible to write an AngularJS 2 application in pure JavaScript, it’s made for TypeScript (and maybe Dart). My bet is that TypeScript is the language of choice if you’re serious about AngularJS 2.

So, starting a series of Angular 2 articles inevitably includes a number of articles about TypeScript. BeyondJava.net already published such an article some time ago, but that was before the release of TypeScript 1.5, so it’s time to deliver an update. During my research I stumbled upon an interesting article: The rise of TypeScript?”. I wasn’t even aware that TypeScript is on the rise, but since I’ve read the article I guess the author can safely omit the question mark. He gives a number of good reasons why TypeScript has an opportunity to lift off.

Let me pick out one interesting aspect of the article: the time is right for a language compiling to JavaScript. How is that possible?
Continue reading