In case you need to update data without refreshing your browser you've got different options. One of them is polling, which means continuously requesting data from the server. In case you haven't access to sockets polling is a neat and simple way to update data without any user interaction required.

Polling vs. WebSockets

Before diving right into how to implement polling in Angular let's take quick glance at the difference between polling and sockets. I've always liked the approach of explaining it via the analogy of a dialog between client and server.

When polling data the dialog would be:

[10:00:00] Client: Is there something new?
[10:00:00] Server: No.
[10:00:05] Client: Is there something new?
[10:00:05] Server: No.
[10:00:10] Client: Is there something new?
[10:00:10] Server: Yes.

The client (in our case most likely our JavaScript) is "asking" the server in a defined interval for new data. It may even happen that there is new data but we're getting the data a few seconds later, which means polling is not really realtime.

On the otherhand WebSockets work differently:

[10:00:00] No communication between client and server.
[10:00:05] No communication between client and server.
[10:00:10] Server: Dude, there's new data!
[10:00:10] Client: Yeah!

In this case it's the other way round; instead of the client permanently asking for new data the server is simply informing the client whenever new data is available. Data is (very likely) received instantaneously - or in other words this approach is realtime.

From a logical perspective of view the sockets approach do indeed make more sense. Remembering the time when my mother cooked for me she would have probably killed me if I'd asked every five seconds "Is dinner ready??" instead of me simply waiting for her to tell me "Dinner is ready!".

So, why to use polling? Often you just don't have access to sockets. When working with Node you can simply use socket.io to make use of sockets. PHP on the other hand makes it a bit more complicated, especially since the way PHP works isn't the best choice for such things. To compensate for this polling is often enough to simply update things on your client without having to refresh or require any other interaction. Keep in mind that if you're going to implement realtime applications (chats, collaboration tools, ...) sockets are most likely the way to go.

Our application

To show how polling is working in Angular we're going to implement a simple application which gets some tweets from Twitter.

System prerequisites

The example application was implemented using the following package versions:

PHP v7.0.28
Angular CLI v6.0.3
rxjs v6.1.0
TypeScript 2.7.2

You can find all used package versions in the package.json respectively the composer.json in the GitHub repository.

Server

We're going to use the twitter-php library to keep this as simple as always.

// server/index.php

<?php
require_once 'vendor/autoload.php';

// Allow getting data from our API
header('Access-Control-Allow-Origin: *');

// Set our response to JSON
header('Content-type: application/json');

try {
    $twitter = new Twitter('<YOUR TWITTER CONSUMER KEY>', '<YOUR TWITTER CONSUMER SECRET>');
    
    // Search twitter for tweets
    $response = $twitter->request('search/tweets', 'GET', [
        'q' => 'javascript',
        'lang' => 'en',
        'count' => 5
    ]);
} catch(TwitterException $e) {
    $response = ['error' => $e->getMessage()];
}

exit(json_encode($response));

Of course you need to replace <YOUR TWITTER CONSUMER KEY> and <YOUR TWITTER CONSUMER SECRET> with proper values. To get these values register your application at the Twitter Application Management.

We're going to use the built-in webserver of PHP to start this file:

php -S localhost:8000

Opening http://localhost:8000 searches for tweets containing the word javascript (specified via the q key) and returns a response like:

{
  "statuses": [
    // a list of tweets
  ],
  "search_metadata": {
    // search metadata
  }
}

Done. Whenever you're requesting this you're most likely to get new tweets. Now we're going to poll this file and show some tweets.

Angular client

Implementation of our client is fairly simple.

Models

Important: Managing models will be handled the way described in my post Working with models in Angular.

For our application we're going to need three different models: one for the response, one for a single status and one for a single author. Since the hierachy begins with the response let's implement this model at first:

Note: For the sake of simplicity we're going to ignore many of the properties we're getting from our API.

// models/twitter-response.model.ts

import {Deserializable} from "./deserializable.model";
import {Status} from "./status.model";

interface SearchMetadata {
  completed_in: number;
  max_id: number;
  max_id_str: string;
  next_results: string;
  query: string;
  refresh_url: string;
  count: number;
  since_id: number;
  since_id_str: string;
}

export class TwitterResponse implements Deserializable {
  statuses: Status[];
  searchMetadata: SearchMetadata;

  deserialize(input: any) {
    Object.assign(<any>this, input);

    input.statuses && (this.statuses = input.statuses.map((status: Status) => new Status().deserialize(status)));

    return this;
  }
}

A single status is represented by the following model:

// models/status.model.ts

import {Deserializable} from "./deserializable.model";
import {User} from "./user.model";

export class Status implements Deserializable {
  id: number;
  text: string;
  user: User;

  deserialize(input: any) {
    Object.assign(<any>this, input);

    return this;
  }
}

The last model we're going to need is the one representing the user (or author):

// models/user.model.ts

import {Deserializable} from "./deserializable.model";

export class User implements Deserializable {
  id: number;
  name: string;
  screen_name: string;

  deserialize(input: any) {
    Object.assign(<any>this, input);

    return this;
  }
}

That's it for our models. Now

Service

Next we're going to need a service which requests the data from our API:

import {Injectable} from '@angular/core';
import {HttpClient} from '@angular/common/http';
import {TwitterResponse} from "../models/twitter-response.model";
import {Observable} from "rxjs/internal/Observable";
import {map} from "rxjs/operators";

@Injectable({
  providedIn: 'root'
})
export class ApiService {
  constructor(private http: HttpClient) {
  }

  getTweets(): Observable<TwitterResponse> {
    return this.http.get<TwitterResponse>('http://localhost:8000')
      .pipe(
        map(res => new TwitterResponse().deserialize(res))
      );
  }
}

Subscribing to our Observable will now give us an instance of TwitterResponse.

Component

The component will handle the polling using RxJS. The component will implement the OnInit interface where the polling will be started.

// app.component.ts

import {Component, OnInit} from '@angular/core';
import {ApiService} from "./services/api.service";
import {interval} from "rxjs/internal/observable/interval";
import {startWith, switchMap} from "rxjs/operators";
import {Status} from "./models/status.model";

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent implements OnInit {
  statuses: Status[];

  constructor(private apiService: ApiService) {
  }

  ngOnInit() {
    interval(5000)
      .pipe(
        startWith(0),
        switchMap(() => this.apiService.getTweets())
      )
      .subscribe(res => this.statuses = res.statuses})
    ;
  }
}

interval is an observable which is piped. It's pretty obvious what happens here: every 5 seconds (starting at 0 to make an "initial call") the apiService.getTweets() is called and the components property statuses is re-assigned.

Important: In case you're using an older version of Angular your implementation would look like this:

Observable
  .interval(5000)
  .startWith(0)
  .switchMap(() => this.apiservice.getTweets())
  .subscribe(res => this.statuses = res.statuses);

Template

The last part is the template, which is just iterating over our statuses and display our tweets:

<ul>
    <li *ngFor="let status of statuses">
        <blockquote class="twitter-tweet">
            <p>{{status.text}}</p>
            by <a href="https://twitter.com/{{status.user.screen_name}}">{{status.user.name}} (@{{status.user.screen_name}})</a>
        </blockquote>
    </li>
</ul>

Thanks to Angular the view is updated automatically everytime new tweets are coming in:

Conclusion

As you can see it's fairly easy to do polling (with required additional tasks like updating our view) in Angular.

This technique can be used for various things like voting systems, messaging, etc.. And, as always, you can find the entire source code for this post on GitHub.

P.S.

I've promised to explain why there hasn't been a blog post for such a long time. To keep the answer to this as simple as possible: I'm no longer single.

One thing I really like about mature frameworks is that they all implement some kind of dependency injection. Recently I've played around with this technology in TypeScript to get a better understanding of how it works beneath the surface.

What is dependency injection (DI)?

In case you have no idea what DI is, I highly recommend to get in touch with it. Since this post should not be about the What? but more about the How? let's try to keep this as simple possible at this point:

Dependency injection is a technique whereby one object supplies the dependencies of another object.

Quote from Wiki

What does that mean? Instead of manually constructing your objects some piece (often called Injector) of your software is responsible for constructing objects.

Imagine the following code:

class Foo {
}

class Bar {
  foo: Foo;
  
  constructor() {
    this.foo = new Foo();
  }
}

class Foobar {
  foo: Foo;
  bar: Bar;
  
  constructor() {
    this.foo = new Foo();
    this.bar = new Bar();
  }
}

This is bad for multiple reasons like having direct and non-exchangable dependencies between classes, testing would be really hard, following your code becomes really hard, re-usability of components becomes harder, etc.. Dependency Injection on the other hand injects dependencies into your constructor, making all these bad things obsolet:

class Foo {
}

class Bar {
  constructor(foo: Foo) {
  }
}

class Foobar {
  constructor(foo: Foo, bar: Bar) {
  }
}

Better.

To get an instance of Foobar you'd need to construct it the following way:

const foobar = new Foobar(new Foo(), new Bar(new Foo()));

Not cool.

By using an Injector, which is responsible for creating objects, you can simply do something like:

const foobar = Injector.resolve<Foobar>(Foobar); // returns an instance of Foobar, with all injected dependencies

Better.

There are numerous resons about why you should dependency injection, including testability, maintainability, readability, etc.. Again, if you don't know about it yet, it's past time to learn something essential.

Dependency injection in TypeScript

This post will be about the implementation of our very own (and very basic) Injector. In case you're just looking for some existing solution to get DI in your project you should take a look at InversifyJS, a pretty neat IoC container for TypeScript.

What we're going to do in this post is we'll implement our very own Injector class, which is able to resolve instances by injecting all necessary dependencies. For this we'll implement a @Service decorator (you might know this as @Injectable if you're used to Angular) which defines our services and the actual Injector which will resolve instances.

Before diving right into the implementation there might be some things you should know about TypeScript and DI:

Reflection and decorators

We're going to use the reflect-metadata package to get reflection capabilities at runtime. With this package it's possible to get information about how a class is implemented - an example:

const Service = () : ClassDecorator => {
  return target => {
    console.log(Reflect.getMetadata('design:paramtypes', target));
  };
};

class Bar {}

@Service()
class Foo {
  constructor(bar: Bar, baz: string) {}
}

This would log:

[ [Function: Bar], [Function: String] ]

Hence we do know about the required dependencies to inject. In case you're confused why Bar is a Function here: I'm going to cover this in the next section.

Important: it's important to note that classes without decorators do not have any metadata. This seems like a design choice of reflect-metadata, though I'm not certain about the reasoning behind it.

The type of target

One thing I was pretty confused about at first was the type of target of my Service decorator. Function seemed odd, since it's obviously an object instead of a function. But that's because of how JavaScript works; classes are just special functions:

class Foo {
    constructor() {
        // the constructor
    }
    bar() {
        // a method
    }
}

Becomes

var Foo = /** @class */ (function () {
    function Foo() {
        // the constructor
    }
    Foo.prototype.bar = function () {
        // a method
    };
    return Foo;
}());

After compilation.

But Function is nothing we'd want to use for a type, since it's way too generic. Since we're not dealing with an actual instance at this point we need a type which describes what type we get after invoking our target with new:

interface Type<T> {
  new(...args: any[]): T;
}

Type<T> is able to tell us what an object is instances of - or in other words: what are we getting when we call it with new. Looking back at our @Service decorator the actual type would be:

const Service = () : ClassDecorator => {
  return target => {
    // `target` in this case is `Type<Foo>`, not `Foo`
  };
};

One thing which bothered me here was ClassDecorator, which looks like this:

declare type ClassDecorator = <TFunction extends Function>(target: TFunction) => TFunction | void;

That's unfortunate, since we now do know the type of our object. To get a more flexible and generic type for class decorators:

export type GenericClassDecorator<T> = (target: T) => void;

Interfaces are gone after compilation

Since interfaces are not part of JavaScript they simply disappear after your TypeScript is compiled. Nothing new, but that means we can't use interfaces for dependency injection. An example:

interface LoggerInterface {
  write(message: string);
}

class Server {
  constructor(logger: LoggerInterface) {
    this.logger.write('Service called');
  }
}

There'll be no way for our Injector to know what to inject here, since the interface is gone at runtime.

That's actually a pity, because it means we always have to type-hint our real classes instead of interfaces. Especially when it comes to testing this may be become really unforunate.

There are workarounds, e.g. using classes instead of interfaces (which feels pretty weird and takes away the meaningfulness of interfaces) or something like

interface LoggerInterface {
  kind: 'logger';
}

class FileLogger implements LoggerInterface {
  kind: 'logger';
}

But I really don't like this approach, since its redundant and pretty ugly.

Circular dependencies causes trouble

In case you're trying to do something like:

@Service()
class Bar {
  constructor(foo: Foo) {}
}

@Service()
class Foo {
  constructor(bar: Bar) {}
}

You'll get a ReferenceError, telling you:

ReferenceError: Foo is not defined 

The reason for this is quite obvious: Foo doesn't exist at the time TypeScript tries to get information on Bar.

I don't want to go into detail here, but one possible workaround would be implementing something like Angulars forwardRef.

Implementing our very own Injector

Okay, enough theory. Let's implement a very basic Injector class.

We're going to use all the things we've learned from above, starting with our @Service decorator.

The @Service decorator

We're going to decorate all services, otherwise they wouldn't emit meta data (making it impossible to inject dependencies).

// ServiceDecorator.ts

const Service = () : GenericClassDecorator<Type<object>> => {
  return (target: Type<object>) => {
    // do something with `target`, e.g. some kind of validation or passing it to the Injector and store them
  };
};

The Injector

The injector is capable of resolving requested instances. It may have additional capabilities like storing resolved instances (I like to call them shared instances), but for the sake of simplicity we're gonna implement it as simple as possible for now.

// Injector.ts

export const Injector = new class {
  // Injector implementation
};

The reason for exporting a constant instead of a class (like export class Injector [...]) is that our Injector is a singleton. Otherwise we'd never get the same instance of our Injector, meaning everytime you import the Injector you'll get an instance of it which has no services registered. (Like every singleton this has some downsides, especially when it comes to testing.)

The next thing we need to implement is a method for resolving our instances:

// Injector.ts

export const Injector = new class {
  // resolving instances
  resolve<T>(target: Type<any>): T {
    // tokens are required dependencies, while injections are resolved tokens from the Injector
    let tokens = Reflect.getMetadata('design:paramtypes', target) || [],
        injections = tokens.map(token => Injector.resolve<any>(token));
    
    return new target(...injections);
  }
};

That's it. Our Injector is now able to resolve requested instances. Let's get back to our (now slightly extended) example at the beginning and resolve it via the Injector:

@Service()
class Foo {
  doFooStuff() {
    console.log('foo');
  }
}

@Service()
class Bar {
  constructor(public foo: Foo) {
  }

  doBarStuff() {
    console.log('bar');
  }
}

@Service()
class Foobar {
  constructor(public foo: Foo, public bar: Bar) {
  }
}

const foobar = Injector.resolve<Foobar>(Foobar);
foobar.bar.doBarStuff();
foobar.foo.doFooStuff();
foobar.bar.foo.doFooStuff();

Console output:

bar
foo
foo

Meaning that our Injector successfully injected all dependencies. Wohoo!

Conclusion

Dependency injection is a powerful tool you should definitely utilise. This post is about how DI works and should give you a glimpse of how to implement your very own injector.

There are still many things to do. To name a few things:

• error handling
• handle circular dependencies
• store resolved instances
• ability to inject more than constructor tokens
• etc.

But basically this is how an injector could work.

As said at the beginning I've just recently begun with digging in DI implementations. If there's anything bothering you about this article or how the injector is implemented feel free to tell me in the comments or via mail.

And, as always, the entire code (including examples and tests) can be found on GitHub.

Changelog

12.05.2018

• Changed description of DI, thanks to dpash.
• Removed fragments of storing capabilities, thanks to vforv.

Usually data for Vue apps come from APIs, but ocassionally it may happen that you're rendering a Twig template with all the data you need and which you want to pass to your Vue app - without implementing an additional API.

Use case

Think of a controller to edit a user, where the actual form is a standalone Vue app:

namespace App\Controller;

class EditRulesController
{
    public function indexAction(User $user)
    {
        // additional and mighty code
        return $this->render('user/edit.html.twig', [
            'user' => $user
        ]);
    }
}

In addition your twig template (user/edit.html.twig):

{% block body %}
<h1>Editing user {{user.name}}</h1>
<div id="user-edit-app"></div>
{% endblock }

To make your form reactive instead of just a static standard form you may use a Vue app:

new Vue({
  el: '#user-edit-app',
  data: {
    username: ''
  },
  template: '<div class="user-edit-form">' + 
  	'<input type="text" v-model="username">' +
    '<span style="display: block;">How cool is your name: {{coolness}}</span>' +
    '<input type="submit" v-on:click="send">' +
  '</div>',
  computed: {
  	coolness: function() {
    	switch(this.username.toLowerCase()) {
      	case 'nehalist':
        case 'kevin':
        	return 'Pretty cool';
        case 'bob':
        	return 'Awesome!';
        case 'ajit pai':
        	return 'Terrible';
      	default:
        	return 'Not cool';
      }
    }
  },
  methods: {
    send: function() {
    	// send your form ...
    }
  }
});

Probably the mightiest thing I've ever implemented.

After your app is rendered you'll see something like this:

The problem now: since you've already rendered your twig template you do already know the name of the user you're editing. But how to get the name (or even the entire User object) into your vue app and your form? Glady that's pretty easy.

Utilising beforeMount and data attributes to inject data

First let's inject the data to our app container (in the twig template):

{% block body %}
<h1>Editing user {{user.name}}</h1>
<div id="user-edit-app" data-name="{{ user.name }}"></div>
{% endblock }

To get access to our data within our view app we're going to utilise Vue's beforeMount method:

new Vue({
  el: '#user-edit-app',
  data: {
    username: ''
  },
  // [...] `template` & `computed` truncated
  beforeMount: function() {
    this.username = this.$el.attributes['data-name'].value;
  }
});

That's it. Now our app renders with the username input already being filled with the proper name.

Note: This method does not work with server-side rendering, since the beforeMount method is never called.

Getting the entire user object

In case you're wanting the entire user object within your Vue app you need to serialize your user object and parse it within your Vue app.

You're either using the Serializer component, or implement a very simple toArray method within your entity. For the sake of simplicity we're going for latter in this article, but in the real world I'd suggest using serializers for this:

// src/Entity/User.php

class User
{
    protected $name;
    
    // [...] truncated setters, ...
    
    public function getName()
    {
        return $this->name;
    }
    
    public function toArray()
    {
        return [
            'name' => $this->getName()
        ];
    }
}

Your twig template now might look like this:

{% block body %}
<h1>Editing user {{user.name}}</h1>
<div id="user-edit-app" data-user="{{ user.toArray|json_encode }}"></div>
{% endblock }

The json_encode is a Twig function to return a value as JSON.

All you need to now is to slightly change our Vue apps beforeMount method:

new Vue({
  el: '#user-edit-app',
  data: {
    user: null,
    username: ''
  },
  // [...] `template` & `computed` truncated
  beforeMount: function() {
    this.user = JSON.parse(this.$el.attributes['data-user']).value;
    this.username = this.user.name;
  }
});

It might be a good idea to validate the data- attributes before assigning it to your Vue instance, but basically this is enough to inject data without needing an additional API.

I've never really talked about client projects - let's change that by taking a look at the VUSION product configurator, my most recent project for SES-imagotag which was also my first Vue.js project.

The finished product

Before diving into the tech stuff, you may want to take a look at the finished product at vusion.ses-imagotag.com. The website itself was implemented by a colleague, while I was responsible for implementing the product configurator.

Look at this fancy notebook image!

Requirements and technology stack

Okay, let's get nerdy.

The product configurator had two interesting requirements: it should be embeddable with JavaScript and all its filters should be flexible (with all rules, mapping values, etc.) and be managed in an administration interface.

The administration was implemented in "plain" Symfony (using Symfony Form components, etc.) in combination with a mySQL database, while for the client we decided to give Vue.js a try. The only alternative would have been React, but I always wanted to try out Vue - which was no mistake by any means, but more on that later.

You won't find any screenshots of the filter administration. I guess I'm not allowed to post such screenshots, sorry.

Embeddable with plain JavaScript

A fun and new thing for me to do was to create an application which can be embedded via plain JavaScript. To visualize how this is happening:

Another fancy image!

In short a very small loader script gathers client-related information and an array of .css and .js files required to run the application, which are then dynamically injected into the client. After loading is finished (usually just a few milliseconds) the Vue application (coming from the dynamically injected files) is injected in a specific div container.

Thanks to this the configurator can be embedded on basically every other website by just including the loader and the proper div container.

Vue.js impressions

Vue did a great job for this application. Since this was my first Vue application everything was new for me - but nevertheless everything felt pretty straight-forward and, to my pleasure, little to no magic was involved. Thinking of the first time when I used Angular and stumbled upon Observables and RXJs? Even Tom Riddle would have been pretty confused at first by the magic happening there.

The only thing which was kinda confusing at the beginning was how Vue is handling the this pointer. Speaking in code:

export default {
  data: function() {
    return {
      foo: 'bar'
    }
  },
  methods: {
    hello: function() {
      return this.foo;
    }
  }
}

Interestingly the bar function would return "bar" here, instead of complaining that this.foo is not defined. This is because how Vue handles this: the Vue instance proxies some of its properties (in case you're interesting see here). This is pretty convenient once you're used to it, but it cost some "Whoops."-moments when using arrow functions.

Everything else was, as said above, pretty straight-forward. Things worked like expected - nothing more I want from a framework. The app is structured pretty simple:

In case you want to ask "why the heck did he put curly brackets in the Filter Type component": I have no idea how to represent repetitive components in such a diagram. That my way of saying "these things are repetitive!".

Filter type components are repetetive and depending on how filters are configured in the administration.

And, of course, the application is completely responsive:

Okay, that's the last fancy image.

Conclusion

Even though this application was pretty small compared to the things I usually do, it was a really fun and interesting project. Vue is really fun and I'm definitely going again for it when there's a choice.

And gladly this project is publicly accessible so I'm allowed to talk about it - most of my applications are used internally (member databases, single sign on portals, ...), hence I can't really talk freely about them. Hopefully there'll be more of such projects in the future, I really enjoy writing such posts (and making cool diagrams and fancy notebook/smartphone images!).

Occasionally I stumble upon the need to download files from POST requests. An example would be generating PDF files, where the PDF content is dependent on the request. Interestingly this is not as straightforward as you may think, but it's not that hard either.

A simple server

We're going to implement a really simple server which is generating PDFs from the POST request:

<?php
require_once 'vendor/autoload.php';

if($_SERVER['REQUEST_METHOD'] === 'POST') {
    header('Content-type: application/pdf');
    http_response_code(200);

    // Contents
    $pdfContent = !empty($_POST['content']) ? $_POST['content'] : 'no content specified';
    
    // Generate the PDOF
    $pdf = new FPDF();
    $pdf->AddPage();
    $pdf->SetFont('Arial','B',16);
    $pdf->Cell(40,10, $pdfContent);
    
    return $pdf->Output(null, 'foobar-' . time() . '.pdf');
}

// Bad method
http_response_code(405);
exit();

Note: This code uses the FPDF library to generate PDF files. For demonstration purposes the pdf is filled with the content from $_POST['content'].

FPDF automatically takes care about setting the Content-Disposition to attachment. In case you don't use FPDF and need to set it manually simply add this before the output:

header('Content-Disposition: attachment; filename="filename.ext"');

Download the file

The more interesting thing about this is how the file is downloaded after sending the HTTP request. Let's dive straight into it:

<!doctype html>
<html>
<head>
  <meta charset="utf-8">
  <title>Download POST Request</title>
</head>
<body>
Enter a text and click the button: <input type="text" id="content" value="Text for the generated pdf">
<button id="download">Send AJAX Request and download file</button>

<script>
  document.getElementById('download').addEventListener('click', function () {
    var content = document.getElementById('content').value;
    var request = new XMLHttpRequest();
    request.open('POST', '../server/', true);
    request.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded; charset=UTF-8');
    request.responseType = 'blob';

    request.onload = function() {
      // Only handle status code 200
      if(request.status === 200) {
        // Try to find out the filename from the content disposition `filename` value
        var disposition = request.getResponseHeader('content-disposition');
        var matches = /"([^"]*)"/.exec(disposition);
        var filename = (matches != null && matches[1] ? matches[1] : 'file.pdf');

        // The actual download
        var blob = new Blob([request.response], { type: 'application/pdf' });
        var link = document.createElement('a');
        link.href = window.URL.createObjectURL(blob);
        link.download = filename;

        document.body.appendChild(link);

        link.click();

        document.body.removeChild(link);
      }
      
      // some error handling should be done here...
    };

    request.send('content=' + content);
  });
</script>
</body>
</html>

Inhales deeply...

The actual download is done by creating a Blob object, which is used for a newly created a tag with a link to the created Blob object which is automatically clicked which ultimately opens the "Save file" dialog. Additionally it's appended to the body (which is a fix for Firefox) and is removed from the body afterwards (we don't want to have tons of invisible a tags on our body).

Well, as easy as vertically centering content in divs! (Flexbox is cheating!)

Keep in mind that this implementation uses plain JavaScript (to make it easier for everybody to follow the example), but the actual download works the same for most frameworks (jQuery, Vue, Angular, ...).

And, of course, you can find the entire implementation for this on GitHub.

Holy moly, I'm overdue. Over a month ago was my 27th birthday, but I completely missed out the blog post to congratulate myself. It deeply hurts my heart that I failed at congratulating myself - but to make me feel better let me explain what happened and give you a brief summary of my year.

Work, work and... more work

The reason why I haven't been able to even visit my blog was the last project I worked on. It had a ridiculous deadline, which required to work on weekends, do overtime and all the stuff that makes you just want to go to bed when the day is done instead of writing blog posts about the same things you may have done the entire day.

But we did it, the project went live on schedule and here I am again. Wohoo!

No bad news this year!

Does anybody remember my last birthday post? It was horrendous. It was about surgeries, loosing money and dying cats. This time it's not!

No bad news this time! Everything worked as expected; a pretty calm and quiet year, but that's exactly what I wanted. I'm still having the same job, still driving the same shitty car (oh, did I mention that I don't like my car?), no surgeries, no money losses, no pets died. The last thing was actually the other way round: I adopted a new cat!

From a developers point of view

I learned a lot of new things; especially regarding Angular 2 (which was part of a project which took around 6 months) and Symfony (which is part of basically every project I'm working on).

I really fell in love with TypeScript, hence my next open source projects will probably be written in TS. That being said, I'm currently working on multiple new open source projects. Sadly development was really slowed down the last months - but I guess I'll have more time during winter holidays.

My current project for work involves VueJS. I don't know much about it yet, but if I like it you can expect some VueJS posts here in the future.

What next?

As mentioned above I'm currently working on multiple open source projects. I'll talk about them as soon as they left the "more than an idea and more than 3 files"-status.

One thing I'm currently thinking to do is video posts (vlogs or whatever you want to call them). Videos would enhance the way of communicating to a certain degree, but it also takes a lot of time. We'll see if this ever become reality.

Another thing is I'd like to blog more. At least 2 posts a month would be decent. My blog has between 200 and 400 visitors every day right now. This is insane, actually way more than I'd expect. But it's really appreciated to see that - gives a lot of motivation.

In short my plan is to make my upcoming year a bit more exciting. I really appreciated the quiet and calm year, but now it's time for a bit more action.

Oh, and before I forget...

Belated happy birthday, me!

P.S. Please forgive me the usage of "Holy moly".

One thing I've got pretty used to is using models in Angular; using objects which hold your data may be pretty useful. It makes the developer live significantly easier - so let me show you what I'm talking about and how I handle models in Angular.

The API

Let's assume we've got an API which returns our users:

GET /api/user

{
    "status": "success",
    "response": [
        {
            "id": 1,
            "name": "John",
            "car": {
                "brand": "BMW",
                "year": 2015
            }
        },
        {
            "id": 2,
            "name": Bob",
            "car": {
                "brand": "Koenigsegg",
                "year": 2014
            }
        }
    ]
}

Basic models

We're going to create two very simple models; one for User and one for Car.

Our user model:

// src/app/shared/models/user.model.ts

import {Car} from "./car.model";

export class User {
  id: number;
  name: string;
  car: Car;
}

And the car model:

// src/app/shared/models/car.model.ts

export class Car {
  brand: string;
  year: number;
}

These two objects will hold our data from the API. We're going to extend these models later, first let's create a service for getting our users:

// src/app/core/service/user.service.ts

import {Injectable} from "@angular/core";
import {Http, Response} from "@angular/http";
import 'rxjs/add/operator/map';
import {User} from "../../shared/models/user.model";

@Injectable()
export class UserService {
  constructor(private http: Http) {}

  getUser() {
    return this.http.get('/api/user')
      .map((res: Response) => res.json().response);
  }
}

Calling getUser() now results in:

(2) [Object, Object]
[
  { id: 1, name: "John", car: Object },
  { id: 2, name: "Bob", car: Object }
]

But that's not exactly what we wanted. We want to get an array of User objects from our service. Let's do this.

Deserialization

We want to deserialize our JSON to our objects. Let's create an interface which provides an API for deserialization:

// src/app/shared/models/deserializable.model.ts

export interface Deserializable {
  deserialize(input: any): this;
}

Now we can extend our models and implement our interface. Let's start with the User model:

// src/app/shared/models/user.model.ts

import {Car} from "./car.model";
import {Deserializable} from "./deserializable.model";

export class User implements Deserializable {
  id: number;
  name: string;
  car: Car;

  deserialize(input: any) {
    Object.assign(this, input);
    return this;
  }
}

The interesting part here is the deserialize method. Basically we're just assigning the input object to this - or, in other words, we're merging the input object with the User object.

But there's still one minor issue here: the car member won't be an instance of Car but still be an Object. We need to tell our deserialize method this manually:

deserialize(input: any): User {
  Object.assign(this, input);
  this.car = new Car().deserialize(input.car);
  return this;
}

And, of course, we now need to implement our Deserializable interface for Car too:

// src/app/shared/models/car.model.ts

import {Deserializable} from "./deserializable.model";

export class Car implements Deserializable {
  brand: string;
  year: number;

  deserialize(input: any): this {
    Object.assign(this, input);
    return this;
  }
}

Now we can go back to our service and tell it what we want to get: we want to get an array of User, not just objects:

// src/app/core/service/user.service.ts

getUser(): Observable<User[]> {
  return this.http.get('/api/user')
    .map((res: Response) => res.json().response.map((user: User) => new User().deserialize(user)));
}

Calling getUser now results in:

(2) [User, User]
[
  User { id: 1, name: "John", car: Car { brand: "BMW", year: 2015 } },
  User { id: 2, name: "Bob", car: Car { brand: "Koenigsegg", year: 2014 } }
]

Which is exactly what we wanted. Yay!

But why do we want that?

Handling raw JSON objects is really painful and hard to maintain. Having "real" entity objects which store data has obvious advantages (maintaining and extensibility) - an example:

Users have a firstName and a lastName. If you're handling the raw JSON you'll have to print out the full name of your user within your templates like this:

<ul>
  <li *ngFor="let user of users">{{ user.firstName }} {{ user.lastName }}</li>
</ul>

One day your customer calls and tells that the order of first- and lastname should be switched. An endless joy which can be done by a (skilled) potato, since all you need to do is to go through every template and switch the expressions.

But if your user is a User object, you can simply implement a function to print the fullname:

getFullName() {
  return this.firstName + ' ' + this.lastName;
}

// Just another example, assuming our Car class does implement a `isSportsCar` method
hasSportsCar() {
  return this.car.isSportsCar();
}

You can now simply call this function in your template:

<ul>
  <li *ngFor="let user of users">{{ user.getFullName() }}</li>
</ul>

And whenever a change is required you need to change one single line. Simple, but effective.

Another good reason for using models like this is that we're working with Typescript. We want to know the type of things when we use them and not just define everything as any. In combination with a good IDE (and you definitely should use a good IDE) this makes life a lot easier.

Of course this can be used for handling forms too:

form: FormGroup;

createForm() {
  this.form = this.fb.group({
    id: null,
    name: ['', Validators.required],
    car: null
  });
}

private prepareSave(): User {
  return new User().deserialize(this.form.value);
}

onSubmit() {
  const user = this.prepareSave(); // `user` is now an instance of "User"
  // this.http.post('/api/user', user)...
}

Changelog

12.05.2018

• Changed the Deserializable interface from Deserializable<T> to Deserializable. There's no reason for it to be generic.

I haven't written any Angular(2(/4)(+)(wtf?)) posts so far - but since I've been working with Angular (okay, let's just call it Angular) for some time now let's do so.

An interesting thing about Angular is that uploading files is barely handled by anyone. It's not mentioned in the docs and the first thing you find by using Google is a third party lib, ng2-file-upload.

But what I needed was a simple FileInput field within a form, along with other input fields, which can be send to a REST api. Think of updating your profile, including the possibility of updating your avatar.
Speaking in REST this would lead to a payload something like:

POST /api/user
{
    "name": "Bob the Builder",
    "avatar": <... yeah, what's here? ...>
}

There are actually different solutions for this and I'd like to cover two of them here, since I ended up using both approaches.

Prerequisites

Before we're diving right into the solutions we're going to need a few things before.

For this example I'll use Angular CLI (since I haven't had the opportunity to play around with it so far) which currently uses Angular 4.2.4. But this should work in Angular 2.x.x as well as in other versions.

You can find the entire source code for this entire project at GitHub.

First of all we're going to need a model for our user:

// src/app/shared/models/User.ts

export class User {
    id: number;
    avatar: string|any;
}

This object will held our (client-side) user object and will be used in both approaches.

Base64 encoding

The solution I've used for "smaller" things (like changing an avatar or similar) is to encode the file client-side, send the encoded string to the server and finally decode and save it there.

Let's create a very simple component for this uploading method called Base64UploadComponent.

First of all we're going to need an HTML template:

// src/app/base64-upload/base64-upload.component.html

<form [formGroup]="form" (ngSubmit)="onSubmit()">
  <div class="form-group">
    <label for="name">Name</label>
    <input type="text" class="form-control" id="name" placeholder="Bob" formControlName="name">
  </div>
  <div class="form-group">
    <label for="avatar">Avatar</label>
    <input type="file" id="avatar" (change)="onFileChange($event)" #fileInput>
    <button type="button" class="btn btn-sm btn-default" (click)="clearFile()">clear file</button>
  </div>
  <button type="submit" [disabled]="form.invalid || loading" class="btn btn-success">Submit <i class="fa fa-spinner fa-spin fa-fw" *ngIf="loading"></i></button>
</form>

There's no magic in this file, but if you haven't read the article about Reactive Forms you should probably do that before. The really interesting part here is our file input:

<input type="file" id="avatar" (change)="onFileChange($event)" #fileInput>

We're attaching a change listener here (onFileChange) here which will handle what happens if you select a file to upload. This is actually a really simple function:

  onFileChange(event) {
    let reader = new FileReader();
    if(event.target.files && event.target.files.length > 0) {
      let file = event.target.files[0];
      reader.readAsDataURL(file);
      reader.onload = () => {
        this.form.get('avatar').setValue({
          filename: file.name,
          filetype: file.type,
          value: reader.result.split(',')[1]
        })
      };
    }
  }

The FileReader is responsible for reading our file contents. As soon we've selected a file we're setting our form value for our avatar to an object which contains the filename, the filetype and the value (which is the base64 encoded string!).

And, well, that's it. When submitting our form our avatar form control now helds the information about the avatar, which can be decoded and saved on our backend.

The entire component

For simplicity here's the entire component:

// src/app/formdata-upload/base64-upload.component.ts

import {Component, ElementRef, ViewChild} from '@angular/core';
import {FormBuilder, FormGroup, Validators} from "@angular/forms";

@Component({
  selector: 'base64-upload',
  templateUrl: './base64-upload.component.html'
})
export class Base64UploadComponent {
  form: FormGroup;
  loading: boolean = false;

  @ViewChild('fileInput') fileInput: ElementRef;

  constructor(private fb: FormBuilder) {
    this.createForm();
  }

  createForm() {
    this.form = this.fb.group({
      name: ['', Validators.required],
      avatar: null
    });
  }

  onFileChange(event) {
    let reader = new FileReader();
    if(event.target.files && event.target.files.length > 0) {
      let file = event.target.files[0];
      reader.readAsDataURL(file);
      reader.onload = () => {
        this.form.get('avatar').setValue({
          filename: file.name,
          filetype: file.type,
          value: reader.result.split(',')[1]
        })
      };
    }
  }

  onSubmit() {
    const formModel = this.form.value;
    this.loading = true;
    // In a real-world app you'd have a http request / service call here like
    // this.http.post('apiUrl', formModel)
    setTimeout(() => {
      console.log(formModel);
      alert('done!');
      this.loading = false;
    }, 1000);
  }

  clearFile() {
    this.form.get('avatar').setValue(null);
    this.fileInput.nativeElement.value = '';
  }
}

Final payload

Our payload (aka the formModel) should now look something like this:

{
  name: "John",
  avatar: {
    filename: "10x10png",
    filetype: "image/png",
    value: "iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKBAMAAAB/HNKOAAAAGFBMVEXMzMyWlpajo6O3t7fFxcWcnJyxsbG+vr50Rsl6AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAAJklEQVQImWNgwADKDAwsAQyuDAzMAgyMbOYMAgyuLApAUhnMRgIANvcCBwsFJwYAAAAASUVORK5CYII="
  }
}

Saving files (with PHP)

In case you're using PHP you'll need something like this to save the file on your server:

file_put_contents($payload['avatar']['filename'], base64_decode($payload['avatar']['value']));

Downsides

This approach has one downside: the payload gets bigger. Depending on the image it can get really big. There's an interesting article by David Calhoun about when to Base64 encode images (and when not to).

Using FormData

Another approach is using FormData. This makes it possible to send binaries - which is good. But it's slightly more awkward to implement as you'll see.

For this we're creating a FormdataUploadComponent which uses the exact same template as above:

// src/app/formdata-upload/formdata-upload.component.html

<form [formGroup]="form" (ngSubmit)="onSubmit()">
  <div class="form-group">
    <label for="name">Name</label>
    <input type="text" class="form-control" id="name" placeholder="Bob" formControlName="name">
  </div>
  <div class="form-group">
    <label for="avatar">Avatar</label>
    <input type="file" id="avatar" (change)="onFileChange($event)" #fileInput>
    <button type="button" class="btn btn-sm btn-default" (click)="clearFile()">clear file</button>
  </div>
  <button type="submit" [disabled]="form.invalid || loading" class="btn btn-success">Submit <i class="fa fa-spinner fa-spin fa-fw" *ngIf="loading"></i></button>
</form>

Our change listener is now slightly different:

  onFileChange(event) {
    if(event.target.files.length > 0) {
      let file = event.target.files[0];
      this.form.get('avatar').setValue(file);
    }
  }

We're just assigning the value of the uploaded file to our avatar form value here. But before sending our form we need to create a FormData instance of our form which will be send to our server:

  private prepareSave(): any {
    let input = new FormData();
    // This can be done a lot prettier; for example automatically assigning values by looping through `this.form.controls`, but we'll keep it as simple as possible here
    input.append('name', this.form.get('name').value);
    input.append('avatar', this.form.get('avatar').value);
    return input;
  }

  onSubmit() {
    const formModel = this.prepareSave();
    this.loading = true;
    // In a real-world app you'd have a http request / service call here like
    // this.http.post('apiUrl', formModel)
    setTimeout(() => {
      // FormData cannot be inspected (see "Key difference"), hence no need to log it here
      alert('done!');
      this.loading = false;
    }, 1000);
  }

And... done!

The entire component

Again, here's the entire component:

// src/app/formdata-upload/formdata-upload.component.ts

import {Component, ElementRef, ViewChild} from '@angular/core';
import {FormBuilder, FormGroup, Validators} from "@angular/forms";

@Component({
  selector: 'formdata-upload',
  templateUrl: './formdata-upload.component.html'
})
export class FormdataUploadComponent {
  form: FormGroup;
  loading: boolean = false;

  @ViewChild('fileInput') fileInput: ElementRef;

  constructor(private fb: FormBuilder) {
    this.createForm();
  }

  createForm() {
    this.form = this.fb.group({
      name: ['', Validators.required],
      avatar: null
    });
  }

  onFileChange(event) {
    if(event.target.files.length > 0) {
      let file = event.target.files[0];
      this.form.get('avatar').setValue(file);
    }
  }

  private prepareSave(): any {
    let input = new FormData();
    input.append('name', this.form.get('name').value);
    input.append('avatar', this.form.get('avatar').value);
    return input;
  }

  onSubmit() {
    const formModel = this.prepareSave();
    this.loading = true;
    // In a real-world app you'd have a http request / service call here like
    // this.http.post('apiUrl', formModel)
    setTimeout(() => {
      // FormData cannot be inspected (see "Key difference"), hence no need to log it here
      alert('done!');
      this.loading = false;
    }, 1000);
  }

  clearFile() {
    this.form.get('avatar').setValue(null);
    this.fileInput.nativeElement.value = '';
  }
}

Key difference

Keep in mind that with this method our form is now part of our request and no longer part of our content. Speaking in PHP again (more specifically in Symfonys HttpFoundation\Request (which is also part of Laravel)) this would mean that the values for our form are now accessed by

$avatar = $request->request->get('avatar');

instead of

$avatar = $request->getContent()['avatar'];

Main advantage of this method is that the file is send as binary, which saves a lot of space.

As you may have noticed things are looking slightly different here. That's because I upgraded Ghost to version 1.0. Really cool version, I love the new editor!

One problem with the update was the installation. Everything related to nehalist.io is hosted on Uberspace - a great hoster. But sadly you can't simply run the Ghost CLI command ghost install and everything works. You run into problems with permissions, you are no root, etc.. It's a shared hoster - I get the point of not being able to sudo commands :)...

Installing Ghost 1.0 without Ghost CLI is interestingly slightly more complicated than I thought it'd be (probably because I've built the thing myself at first...), but still no magic. In case you're running into problems with Ghost CLI just follow the steps below and you should be good.

Different method: installing Ghost as NPM module

Regarding the official docs it's possible to install Ghost as a NPM module, which makes updating way easier than the method below. Detailed instructions on how to do that can be found on the Stickleback blog (thanks to Tom Risager for this information!).

Important note: There's a bug with paths when installing Ghost as npm module; Ghost doesn't use the process directory for finding the content directory specified within the config.<environment>.json and instead uses the Ghost installation directory. That means that the content directory is set to node_modules/ghost/content/, which doesn't make a lot of sense.

As long as this hasn't been officially fixed, a simple workaround is to remove the trailing slash from the contentPath entry in your configuration (hence from contentPath: "content/" to contentPath: "content"). Ghost no longer uses the path as relative path and uses the correct content directory within your ghost installation.

0. Migrate

In case you want to migrate from a previous installation just follow the official guide on how to do that.

1. Install yarn

You actually don't need Yarn, but since Ghost provides a yarn.lock file it might be a good idea to make use of it. Also, generally speaking yarn is just better than npm:

curl -o- -L https://yarnpkg.com/install.sh | bash

2. Download the zip

Initially I just cloned the repo and built the thing myself - don't do that. Just download the latest version, it already includes the built version:

curl -L https://ghost.org/zip/ghost-latest.zip -o ghost-latest.zip

And extract the thing wherever you want to, e.g.:

unzip ghost-latest.zip -d ghost && cd ghost

3. Install dependencies

cd into the directory where you've unzipped Ghost and run

yarn install

to install all dependencies.

4. Configuration

Since we're not using Ghost CLI we need to create the configuration file manually. Gladly there are some predefined environment configurations available within the ghost directory, hence we can simply copy them (into the root directory of the Ghost installation):

cp core/server/config/env/config.production.json config.production.json

Edit the config.production.json to your needs (especially the database settings). Additionally you need to specify the URL and server settings within your configuration file; in the end your file should look something like this:

{
    "url": "<URL_OF_YOUR_BLOG>",
    "server": {
        "host": "127.0.0.1",
        "port": <DESIRED_PORT>
    },
    "database": {
        "client": "mysql",
        "connection": {
            "host"     : "127.0.0.1",
            "user"     : "<DB_USER>",
            "password" : "<DB_PASSWORD>",
            "database" : "<DB_NAME>"
        }
    },
    "auth": {
        "type": "password"
    },
    "paths": {
        "contentPath": "content/"
    },
    "logging": {
        "level": "info",
        "rotation": {
            "enabled": true
        },
        "transports": ["file", "stdout"]
    }
}

5. Knex migrator

Ghost uses a tool namend "Knex migrator" for database migrations. You first need to install it:

npm install -g knex-migrator

After that run

NODE_ENV=production knex-migrator init

This will create all the tables you need for Ghost within your database.

6. Done

That's it. You can now start Ghost with

NODE_ENV=production node index.js

Not using Ghost CLI has probably its downsides, but in case you can't simply run it this might be one solution to get Ghost 1.0 working.