DEV Community: Julian Finkler

Sign Android apps using 1Password

Julian Finkler — Thu, 20 Nov 2025 13:05:22 +0000

German is also available: https://dev.to/devtronic/android-apps-mithilfe-von-1password-signiere-472o

Android developers know: If you want to upload an app to the Google Play Store, the app bundle or APK must be signed with a key.

As an individual developer, the process is relatively straightforward:

Create a Java Key Store (JKS)
Add a signing key to the JKS
Create a key.properties file containing details such as the key alias and password
Use this to sign the app

The JKS should not be committed

From a security perspective, neither the JKS nor the properties file should be committed to a VCS. This introduces several challenges:

I need to ensure the JKS is stored in a secure location to avoid loss.
When working in a team, every developer must store the JKS and properties file locally.
If a new key is added to the JKS, all other developers must update their file accordingly.

This can become very tedious, which is why I looked for an alternative, better approach that avoids dealing with files.

1Password to the rescue

1Password is primarily a password manager. However, over the years, especially for developers, quite a few useful features have been added. One of them is the 1Password CLI – a very practical tool that allows you to retrieve data from 1Password.

That’s when I had an idea: Why store and exchange these highly sensitive files manually if we can manage them centrally in 1Password instead? I hoped for the following advantages:

A single location to store the information
Gradle reads the information directly from 1Password – no need to place files manually
New keys are automatically available to all developers when the JKS in 1Password is updated
No sensitive data in the repository (especially relevant in the age of AI agents)

Setup Instructions

1Password CLI

First, install the 1Password CLI (op). You can find out how in the official documentation: https://developer.1password.com/docs/cli/get-started/

Then run the command op signin in your terminal to log in.

Create the JKS

If you don’t have a JKS yet, you can create one easily in Android Studio via

Build > Generate Signed App Bundle or APK.

It’s important to write down the values you enter there — we will transfer them to 1Password in the next step.

Creating a JKS in Android Studio

Store the information in 1Password

Before Gradle can load the information from 1Password, an entry must exist.

I first created a new vault (name: AndroidDevelopment). Then I created a new entry of type password.

As a naming convention, I use something URL-safe. Username and password can be left empty. Instead, add the following fields:

KEY_ALIAS = Text → Enter the key alias
KEYSTORE_PASSWORD = Password → Password of the JKS
KEY_PASSWORD = Password → Password of the key
Finally, add the keystore.jks file as an attachment (the filename will be used exactly as-is)

Signature information created in 1Password

You can then save the entry.

Adjust the Gradle script

Finally, Gradle needs to be configured to load data from 1Password using the CLI.

I've summarized the required changes in this GitHub Gist. The only thing you need to adapt is line 5 (val secretsItem). Here you need to specify the correct path to your 1Password entry (op://VAULT_NAME/ENTRY_NAME). Apart from that, you can use the script 1:1.

https://gist.github.com/devtronic/8db7a0a8607eabce0afb97c55fd60819

How it works

The core of the solution is the _runOp_ function, which communicates with the 1Password CLI. Additionally, there are two tasks:

prepareKeystore → Loads the JKS from 1Password and places the file in the correct location
cleanupKeystore → Deletes the JKS right after the build process

Hooks for assembleRelease and bundleRelease are then configured to trigger the tasks.

The variables keystorePassword, keyAliasValue, and keyPasswordValue are loaded accordingly and later used in the signingConfigs.

Build the app

Now you’re ready to build the app. During the build, you’ll see the familiar 1Password popup asking you to grant access.

Grant access to 1Password

Conclusion

With just a few steps, this method ensures that signing Android apps remains simple even in larger teams. Additionally, it allows secure signing within CI/CD pipelines, without needing to commit the JKS or load it via workarounds.

Android Apps mithilfe von 1Password signieren

Julian Finkler — Thu, 20 Nov 2025 12:58:50 +0000

(Zuerst erschienen auf: https://www.linkedin.com/pulse/android-apps-mithilfe-von-1password-signieren-julian-finkler-erlce)

Android Entwickler wissen: Wenn man eine App in den Google Play Store hochladen möchte, muss das App Bundle bzw. das APK mit einem Schlüssel signiert sein.

Als einzelner Entwickler ist der Prozess relativ trivial:

Man legt einen Java Key Store, kurz JKS, an
Man legt in diesem JKS einen Schlüssel zum signieren ab.
Man legt eine key.properties Datei an, in der die die Details, wie Schlüssel oder das Passwort des Schlüssels stehen.
Man signiert die App damit.

Der JKS sollte nicht eingecheckt werden

Aus Sicht der Sicherheit sollten natürlich sowohl der JKS als auch die Properties-Datei nicht in ein VCS eingecheckt werden. Das bringt eine Reihe von Herausforderungen mit sich:

Ich muss mich darum kümmern, dass der JKS an einem sicheren Ort gegen Verlust gesichert wird.
Wenn im Team gearbeitet wird, muss jeder Entwickler bei sich den JKS sowie die Properties Datei hinterlegen.
Wenn ein Entwickler im JKS einen neuen Schlüssel hinzufügt müssen alle anderen die Datei aktualisieren.

Das ganze kann mitunter sehr mühselig sein, weswegen ich einen alternativen, besseren Weg gesucht habe, als mit Dateien zu hantieren.

1Password zur Hilfe

1Password ist in erster Linie ein Passwort Manager. Im Laufe der Jahre sind aber, gerade für Entwickler, ziemlich praktische Funktionen dazu gekommen. Darunter ist die 1Password CLI ein sehr praktisches Werkzeug, mit dem man unter anderem Daten aus 1Password lesen kann.

So kam mir die Idee: Warum sollte man diese hochsensiblen Daten irgendwo ablegen und austauschen, wenn man es auch zentral in 1Password tun kann. Folgende Vorteile erhoffte ich mir:

Ein Ort, an dem die Information liegt.
Gradle liest die Informationen direkt aus 1Password, ohne dass die Dateien von Hand abgelegt werden müssen.
Neue Schlüssel stehen automatisch allen Entwicklern zur Verfügung, wenn jemand den JKS in 1Password aktualisiert.
Keine sensiblen Daten im Repository (Gerade in Zeiten von KI Agenten ist das relevanter denn je)

Anleitung zum Einrichten

1Password CLI

Zuerst solltest du die 1Password CLI (op) installieren. Wie das geht, erfährst du in der offiziellen Doku: https://developer.1password.com/docs/cli/get-started/

Anschließend führst du auf der Kommandozeile den Befehl op signin aus, um dich einzuloggen.

JKS anlegen

Falls du noch keinen JKS hast, kannst du ihn in Android Studio ganz einfach über Build > Generate Signed App Bundle or APK anlegen. Wichtig ist, dass du dir die Werte dieser Felder irgendwo notierst, diese übernehmen wir im nächsten Schritt in 1Password.

JKS in Android Studio anlegen

Informationen in 1Password hinterlegen

Bevor die Informationen aus 1Password geladen werden können, muss dazu natürlich ein Eintrag existieren.

Ich habe dafür zunächst einen neuen Vault (Name: AndroidDevelopment) angelegt. Anschließend legt man darin ein neues Objekt vom Typen Passwort an.

Als Name habe ich mir angewöhnt, etwas URL-sicheres zu vergeben. Benutzername und Passwort können leer bleiben. Stattdessen fügen wir folgende Felder hinzu:

KEY_ALIAS = Text. Dort wird der Alias des Schlüssel eingegeben
KEYSTORE_PASSWORD = Passwort. Dort wird das Passwort des JKS eingegeben
KEY_PASSWORD = Passwort. Dort wird das Passwort des Schlüssels eingegeben
Und als letztes wird noch die keystore.jks als Anhand hinzugefügt. (Der Dateiname wird später genau so weiterverwendet)

Signatur Informationen in 1Password anlegen

Anschließend kann der Eintrag gespeichert werden.

Gradle Script anpassen

Zum schluss muss man Gradle noch dazu bringen, die Daten mittels 1Password CLI aus 1Password zu laden.

Die Anpassungen habe ich in diesem Gist auf GitHub zusammengefasst. Das Einzige was von dir noch angepasst werden muss ist Zeile 5 (val secretsItem). Dort musst du den bei dir richtigen Pfad zum oben angelegten Eintrag in 1Password hinterlegen (op://VAULT_NAME/NAME_DES_EINTRAGS). Ansonsten kannst du das Script 1:1 verwenden.

https://gist.github.com/devtronic/8db7a0a8607eabce0afb97c55fd60819

Funktionsweise

Kernstück des Ganzen ist die runOp Funktion, welche mit der 1Password CLI kommuniziert. Darüber hinaus gibt es noch zwei Tasks:

prepareKeystore -> Lädt den JKS aus 1Password und legt die Datei an der richtigen Stelle ab
cleanupKeystore -> Löscht den JKS direkt nach dem Build Vorgang.

Damit die Tasks ausgeführt werden, werden noch die Hooks für assembleRelease und bundleRelease eingerichtet.

In die Variablen keystorePassword, keyAliasValue und keyPasswordValue werden die entsprechenden Werte zum signieren geladen, welche dann später in die signingConfigs übernommen werden.

App bauen

Nun bist du an dem Punkt angekommen, wo du die App bauen darfst. Beim Build Vorgang wirst du das bekannte Fenster von 1Password sehen, wo du den Zugriff auf 1Password genehmigen musst.

Zugriff auf 1Password genehmigen

Fazit

Mit ein paar Handgriffen kann man mit diesem Vorgehen sicherstellen, dass auch in größeren Teams das signieren von Android Apps einfach gestaltet werden kann. Außerdem besteht somit auch die Möglichkeit, Apps in einer CI/CD Pipeline sicher zu signieren, ohne dass der JKS eingecheckt oder über Umwege geladen werden muss.

Install ionCube Loader in Docker

Julian Finkler — Wed, 06 Nov 2024 07:04:24 +0000

I wrote something that I need for my projects and I think this could be useful for you too.

You can install the ionCube loader automatically during image creation with the following script.

# Change the tag as needed
FROM php:8.3-apache

COPY --chmod=775 ioncube-loader-setup.sh /tmp/ioncube-loader-setup.sh
RUN set -x && bash -c /tmp/ioncube-loader-setup.sh

# ioncube-loader-setup.sh

########################
# ionCube INSTALLATION #
########################

PHP_EXTENSION_DIR=$(php -r 'echo ini_get("extension_dir");')
echo "PHP_EXTENSION_DIR is $PHP_EXTENSION_DIR"
PHP_CONFIG_DIR=$(php -i | grep -ohP "with-config-file-scan-dir=([^']+)" | cut -d= -f2)
echo "PHP_CONFIG_DIR is $PHP_CONFIG_DIR"
PHP_VERSION=$(php -r 'list($major, $minor, $fix) = explode(".", phpversion(), 3); echo $major.".".$minor;')
echo "PHP_VERSION is $PHP_VERSION"

# Detect the correct ionCube loader architecture
IONCUBE_ARCH=""
ARCH=$(uname -m)
if [[ $ARCH == x86_64* ]]; then
  IONCUBE_ARCH="x86-64"
elif [[ $ARCH == i*86 ]]; then
  IONCUBE_ARCH="x86"
elif  [[ $ARCH = aarch64 ]]; then
  IONCUBE_ARCH="aarch64"
elif  [[ $ARCH == arm* ]]; then
  IONCUBE_ARCH="armv7l"
else
  echo "Unsupported ionCube loader architecture!" 1>&2
  exit 1
fi
echo "Detected ionCube loader architecture is $IONCUBE_ARCH based on $ARCH"

echo "Downloading the loader"
curl -O https://downloads.ioncube.com/loader_downloads/ioncube_loaders_lin_$IONCUBE_ARCH.tar.gz

echo "Extracting the loader"
tar -xzvf ioncube_loaders_lin_$IONCUBE_ARCH.tar.gz

LOADER_FILE=$(ls ioncube/*8.3*.so | cat)
LOADER_FILENAME=$(echo $LOADER_FILE | cut -d/ -f2)

if [ ! -f $LOADER_FILE ]; then
  echo "No loader found for PHP $LOADER_LOADER_VERSION" 1>&2
  exit 2
fi

echo "Copy loader file $LOADER_FILE to $PHP_EXTENSION_DIR"
cp $LOADER_FILE "$PHP_EXTENSION_DIR"

echo "Writing PHP config $PHP_CONFIG_DIR/00-ioncube.ini"
cat <<EOF | tee $PHP_CONFIG_DIR/00-ioncube.ini
zend_extension=$LOADER_FILENAME
EOF

# Cleanup
rm -rf ./ioncube
rm ioncube_loaders_lin_$IONCUBE_ARCH.tar.gz
rm -f "${0}"

https://gist.github.com/devtronic/e7780dfdb31f4aa6df261739ef987d77

Dependency Injection with Flutter

Julian Finkler — Fri, 18 Jun 2021 05:57:01 +0000

You know dependency injection? You love dependency injection!
Unfortunately, Flutter don't provide any built-in DI feature.

For this, I created last year the flutter_catalyst package with is a port of the catalyst package which is only supported for Dart native.

flutter_catalyst was a good starting point for me to implement DI in my Flutter apps but in large projects it's a mess to configure.

In the last two months I created a new package catalyst_builder which supports all platforms and is easy to configure.

This package uses the build_runner which performs tasks when you run it.
catalyst_builder has a build_runner task that reads annotations from your dart files and generate a service provider for DI.

Setup

Run flutter pub add catalyst_builder or add the package to your pubspec.yaml

# pubspec.yaml
dependencies:
  catalyst_builder: ^1.0.1

Since we use the build_runner you need to add this to your dev_dependencies:

# pubspec.yaml

dev_dependencies:
  build_runner: ^2.0.4

Create a build.yaml beside your pubspec.yaml. This file contains the configuration for the service provider (output file name and provider class name)

targets:
  $default:
    auto_apply_builders: true
    builders:
      catalyst_builder|buildServiceProvider:
        options:
          providerClassName: 'AppServiceProvider'
          outputName: 'app_service_provider.dart'

Run flutter pub get to install the packages

Now run flutter pub run build_runner watch --delete-conflicting-outputs which watches for changes and create the service provider dart file

Usage

You can declare every class as a service with the @Service annotation from the catalyst_builder package:

@Service()
class MyService {
   final String username = 'TestUser';
}

Ensure that flutter pub run build_runner watch --delete-conflicting-outputs is running. You should see now a app_service_provider.dart file that you can include in your project.

Create the service provider and retrieve the service from it:

var myProvider = AppServiceProvider();
myProvider.boot(); // This is important

var myService = myProvider.resolve<MyService>();
//  also works: MyService myService = myProvider.resolve();
print(myService.username); // prints TestUser

Thats all for a simple service.

Nested services a.k.a. Dependency Injection

In the real world you've services that depend on other services that depend on configuration parameters etc.

catalyst_builder also supports this scenario:

@Service()
class ServiceA {}

@Service()
class ServiceB {
    final ServiceA serviceA;
    ServiceB(this.ServiceA);
}

class ServiceC {} 

@Service()
class ServiceD {
    final ServiceC serviceC;
    ServiceD(@Parameter('otherService') this.ServiceC);
}


void main() {
    var myProvider = AppServiceProvider();
    myProvider.boot();

    // This works:
    var serviceB = myProvider.resolve<ServiceB>();

    // This not because ServiceC is not known as a service:
    var serviceD = myProvider.resolve<ServiceD>();

    // But this works, because the provider contains a 
    // parameter with the same name as the required argument:
    myProvider.parameters['serviceC'] = ServiceC();
    var serviceD = myProvider.resolve<ServiceD>();

    // This also works, because the provider contains a 
    // parameter with the name which is given in the 
    // Parameter annotation.
    myProvider.parameters['otherService'] = ServiceC();
    var serviceD = myProvider.resolve<ServiceD>();
}

Service lifetime

By default, all services are singeltons. You will get the same instance everytime you call resolve<T>.

You can specify the lifetime with the lifetime argument in the @Service annotation:

/// Transient services are always recreated
@Service(lifetime: ServiceLifetime.transient)
class TransientService {}

/// Default is singleton
@Service(lifetime: ServiceLifetime.singleton)
class SingletonService {}

Code Against Interfaces, Not Implementations.

Every programmer would tell you that you shouldn't depend on implementations but interfaces.

Also this is possible with the exposeAs Property in the @Service annotation. Expose as will return the implementation if you request the type that you provide as exposeAs. This also works for nested services.

// interface
abstract class BaseService {}

// implementation
@Service(exposeAs: BaseService)
class MyService implements BaseService {}

Preloading services

Some services are background services (connectivity checks for example).
Decorate this services with @Preload() to create a instance of the service while boot()-ing the provider.

@Service()
@Preload()
class MyService {
  MyService(){
    print('Service was created');
  }
}

void main() {
  ServiceProvider provider;
  provider.boot(); // prints "Service was created" 
  provider.resolve<MyService>(); // Nothing printed
}

Flutter specific tips:

Screens (widgets) should be always transient services.
You can use resolve<T> in the router:

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      debugShowCheckedModeBanner: false,
      initialRoute: '/',
      routes: {
        '/': (_) => container.resolve<HomeScreen>(),
      },
    );
  }
}

Hope you like and use the package ;-)

Debug Mobile Websites with Chrome & Android Chrome

Julian Finkler — Mon, 29 Jun 2020 05:06:51 +0000

Do you already know this cool Google Chrome feature?

This allows you to debug your websites directly on your Android device. All you need to do is:

Enable USB Debugging on your device
Connect it to your computer
Open Chrome on your mobile device
Open the Chrome dev tools on the computer
Click on the 3 dots menu > More tools > Remote devices
Select the device and allow USB-Debugging on your mobile device.
Click the "Inspect" button for the site you want to debug:
DEBUG!

Reusable Angular forms in no time

Julian Finkler — Sun, 07 Jun 2020 12:30:55 +0000

Imagine this situation:

Your team lead assigns you the task to create a list view (e.g.
a list of orders) and a form view to edit the list entries. You find out, that the product area which is also part of the software provides the same logic. You start with copying the code of the list view (which is fortunately just an separated component which only needs a data source passed in). Then you start copying step by step the form template. A textfield here, a checkbox there. Oh, I need a select field and the other template doesn't contain it - no prob, HTML is nice AF and I can write the markup on my own. After a while you're done and the form works as expected.

Recognize yourself in that workflow? Me too.

What's wrong with it?

Let's check what are the negative aspects of this:

If you copy code you're violating the D.R.Y. principle
The style of fields may vary since you need to write some markup on your own.
If you want to add a tooltip to all text fields you've to edit all files containing a text field. (You will forget one, believe me 😅)
Your edit form is violating the Single-responsibility principle since it must validate all fields against general business logic (Not empty, min, max etc), contains listeners of field selection etc.

How to make it better?

First of all you can create simple components for each field. For example a TextFieldComponent or a CheckboxComponent. This would solve problem 1, 3 and partially 2. Why partially 2? Because it's still possible to modify the outer markup in the html where you use the component.

What else? Forms without writing HTML? No way!

You're right. Without writing any HTML it's not possible but you can reduce the HTML to a minimum.
I created a Angular library which is called @mintware-de/form-builder.
It provides all functionality you need to create reusable, maintainable and extensible forms in Angular.

Real world example

Create a new minimal Angular project using

ng new form-example --minimal --skip-tests --inline-style --inline-template

Install the package

npm i -d @mintware-de/form-builder@^2.0.0

Create a form fields module

In a previous section I mentioned that's an good idea to separate fields into it's own components. First, create a new module called form-fields inside your src/app directory and cd into the module directory.

ng g m form-fields
cd src/app/form-fields

As described in the getting started import and export the FormBuilderModule and the ReactiveFormsModule in your FormFieldsModule.

// ...
  imports: [
    CommonModule,
    FormBuilderModule,   // New
    ReactiveFormsModule  // New
  ],
  exports: [
    FormBuilderModule,   // New
    ReactiveFormsModule  // New
  ]
// ...

Import the FormFieldsModule in your AppModule.

Creating form field components

Let's start with creating a text field component which has a inline template, inline styles and no tests.

ng g c text-field --inline-template --inline-style --skip-tests

Why using inline template?
The template of the form components are really small in the most cases.
Additionally to this, mostly you don't need to write TypeScript code in the component itself.
That's the reason why I prefer inline templates.

Create the options interface and the form type

A form component for the form builder consists of 3 parts:

The Angular component
An options interface which is used for configuring the component
The form type which connects the component and the options. The form type also defines the validation rules.

Now create the options and the type next to the text-field.component.

|- src/app/form-fields
|  |- text-field
|  |  |- text-field.component.ts
|  |  |- text-field.options.ts    <-- New
|  |  |- text-field.type.ts       <-- New

Create an empty interface for the text field options. We will add needed properties later.

// text-field.options.ts
export interface TextFieldOptions {

}

The form type must extend the AbstractType<TOptions> class. The naming convention for the class name is the PascalCased file name without the suffix. In this case simply TextField.

As TOptions you need to pass the created TextFieldOptions type and implement the abstract member component. Set the value to TextFieldComponent.
The referenced component will be used to render the form field.

The complete file should look like this:

// text-field.type.ts
import {AbstractType, Constructor} from '@mintware-de/form-builder';
import {TextFieldOptions} from './text-field.options';
import {TextFieldComponent} from './text-field.component';

export class TextField extends AbstractType<TextFieldOptions> {
    public readonly component: Constructor = TextFieldComponent;
}

Write the component code

First of all, add the TextFieldComponent to the FormFieldsModule inside the entryComponents section.
This is necessary since the form builder render the components
with a ComponentFactory.

// form-fields.module.ts
import { NgModule } from '@angular/core';
import { CommonModule } from '@angular/common';
import { TextFieldComponent } from './text-field/text-field.component';

@NgModule({
  declarations: [
    TextFieldComponent,
  ],
  entryComponents: [
    TextFieldComponent, // New
  ],
  imports: [
    CommonModule
  ]
})
export class FormFieldsModule {
}

Open the TextFieldComponent and replace the implements OnInit with
extends AbstractFormFieldComponent<AbstractType<TextFieldOptions>>

// text-field.component.ts
import { Component } from '@angular/core'; // modified
import {
  AbstractFormFieldComponent,
  AbstractType
} from '@mintware-de/form-builder'; // new
import { TextFieldOptions } from './text-field.options'; // new

@Component({
  selector: 'app-text-field',
  template: `
    <p>
      text-field works!
    </p>
  `,
  // modified
})
export class TextFieldComponent
  extends AbstractFormFieldComponent<AbstractType<TextFieldOptions>> { // modified

  // modified

}

Why not using extends TextField directly?
Since the TextField imports the TextFieldComponent a direct use of TextField inside the TextFieldComponent would cause a circular reference.

Add the input field

Now we need to add some HTML code which contains the input element. We use the [formControl] attribute on the input to link the input element with the FormControl in the Angular FormGroup.
The AbstractFormGroupComponent a property mwElement which contains the form control.

Update the template of the TextFieldComponent:

<input type="text" [formControl]="mwElement">

Congrats, you just created your first form field 👏. Let's create a form to use and reuse the the form field.

Create a form and use the form field

Open the AppComponent and replace the content with this:

import {Component} from '@angular/core';
import {FormModel} from '@mintware-de/form-builder';
import {TextField} from './form-fields/text-field/text-field.type';

@Component({
  selector: 'app-root',
  // Display the form by using the MwFormBuilder Component
  // Pass the formModel and formData and set a submit action
  // The action is only called if the form is valid
  template: `
    <mw-form-builder #myForm
                     [mwFormModel]="formModel"
                     [mwFormData]="formData"
                     (mwFormSubmit)="submit($event)">
    </mw-form-builder>

    <button type="button" (click)="myForm.submit()">Submit</button>
  `
})
export class AppComponent {
  // Create a form model. 
  // The naming and nesting is equal to the formData
  public formModel: FormModel = {
    firstName: new TextField({}),
    lastName: new TextField({})
  };

  // Set the initial form data
  public formData: { firstName: string, lastName: string } = {
    firstName: 'John',
    lastName: 'Doe',
  };

  // Create a submit handler
  public submit(data: { firstName: string, lastName: string }): void {
    console.log("Form was submitted: %o", data);
  }
}

Run ng serve to start the app.

Press the button and something like
Form was submitted: {firstName: "John", lastName: "Doe"}
is written to the console.

Adding options to the text field

Cool, text fields without labels. That's what I call usability 😬
Ok, let's add a few options to our text field:

Label: The string which is used as the label
Required: A boolean which defaults to true and marks the field as required or not.

Edit the TextFieldOptions interface and add the fields:

// text-field.options.ts
export interface TextFieldOptions {
  label: string;      // new
  required?: boolean; // new
}

Now update the HTML code of the TextFieldComponent and use the properties. You can access the options object in the mwFieldType property, which comes from AbstractFormFieldComponent.

<div>
  <label [for]="mwPath">{{ mwFieldType.options.label }}</label>
  <input type="text"
         [formControl]="mwElement"
         [id]="mwPath"
         [required]="mwFieldType.options.required">
   <div *ngIf="mwElement.errors && mwElement.errors.required">
       {{mwFieldType.options.label}} is required.
   </div>
</div>

Since the label property is not nullable, you've to set it in the form model in the AppComponent.

public formModel: FormModel = {
  firstName: new TextField({
    label: 'First name', // new
  }),
  lastName: new TextField({
    label: 'Last name',  // new
  })
};

Reload the page and voilà, the form fields has labels:

Almost done. We just need to add the required validation and set the default state to true.

Option defaults & validation

To set default values for optional options, you need to add a constructor to the TextField type. In the constructor you can use Object.assign({}, ...); to set the defaults in the options object. Validators can be added by overriding the validators getter.

import {AbstractType, Constructor} from '@mintware-de/form-builder';
import {TextFieldOptions} from './text-field.options';
import {TextFieldComponent} from './text-field.component';
import {ValidatorFn, Validators} from '@angular/forms';

export class TextField extends AbstractType<TextFieldOptions> {
  public readonly component: Constructor = TextFieldComponent;

  constructor(opts: TextFieldOptions) {
    // Set the field defaults
    super(Object.assign({
      required: true,
    }, opts));
  }

  public get validators(): ValidatorFn[] {
    const validators: ValidatorFn[] = [];

    // Only add the required validator if the field is required
    if (this.options.required) {
      validators.push(Validators.required);
    }

    return validators;
  }
}

Reload the page and clear the inputs. You should see the error message and if you try to submit the form, the submit method is not called since both fields are required by default.

FAQ

Is the form builder compatible with Angular Material?

Yep

Can I create collection fields and nested forms?

Collections or Array fields and nested forms are both supported.
Guides:

Collections
Form groups for nested forms.

...Complex layouts?

Yes, there is a special FormType called AbstractLayoutType. Guide: Layout types

Example: https://gist.github.com/devtronic/807e8bfc712330ef13a5c9b8bf5a71cf

I hope everything was clear and you enjoyed reading my post.

Questions, Suggestions etc. ➡️ Comments

Server Side: Dart vs. PHP

Julian Finkler — Wed, 01 Apr 2020 10:44:19 +0000

I'm courious, please comment 🙂

If you've to choose between Dart and PHP:

Which one do you prefer for server side programming?:
...

Why?:
...

Why not (Dart|PHP)?:
...

TypeScript: Effizient Flat-Daten in einen Baum umwandeln

Julian Finkler — Mon, 03 Feb 2020 18:34:15 +0000

Manchmal stehst du vor der Herausforderung, Flat-Daten in eine Baum-Struktur umzuwandeln. Jeder Flat-Datensatz beinhaltet dabei in der Regel eine Id und eine ParentId wobei letzteres die Id des jeweils übergeordneten Knoten ist. Ist die ParentId null handelt es sich um einen Wurzelknoten.

Zum Beispiel sollst du

[
  {
    "Id": 1,
    "Name": "1",
    "ParentId": null
  },
  {
    "Id": 2,
    "Name": "1 - 1",
    "ParentId": 1
  },
  {
    "Id": 3,
    "Name": "1 - 2",
    "ParentId": 1
  },
  {
    "Id": 4,
    "Name": "1 - 3",
    "ParentId": 1
  },
  {
    "Id": 5,
    "Name": "1 - 2 - 1",
    "ParentId": 3
  }
]

in folgende Struktur umwandeln:

[
  {
    "Id": 1,
    "Name": "1",
    "ParentId": null,
    "Children": [
      {
        "Id": 2,
        "Name": "1 - 1",
        "ParentId": 1,
        "Children": []
      },
      {
        "Id": 3,
        "Name": "1 - 2",
        "ParentId": 1,
        "Children": [
          {
            "Id": 5,
            "Name": "1 - 2 - 1",
            "ParentId": 3,
            "Children": []
          }
        ]
      },
      {
        "Id": 4,
        "Name": "1 - 3",
        "ParentId": 1,
        "Children": []
      }
    ]
  }
]

Der rekursive Ansatz

Der erste Ansatz an den man dabei denkt, wäre folgendes rekursives Konstrukt:

Man sucht sich alle Wurzelknoten (ParentId = null) raus und verschiebt diese in ein neues Array.
Anschließend iteriert man rekursiv über die restlichen Knoten und prüft, ob die ParentId des aktuellen Knoten der Id einem der Wurzelknoten bzw. deren Kindknoten entspricht.
Falls dem so ist, fügt man dem gefundenen Knoten den aktuellen Knoten als Kindknoten hinzu. Falls nicht, schiebt man den Knoten wieder in die Liste zurück.

Ein großer Nachteil:
Wir müssen für jeden Knoten im Worst-Case den kompletten Baum rekursiv runter laufen.

Der Do-While-Shift-Push-Reference-Type Ansatz

Ok, den Namen habe ich mir gerade ausgedacht, gibt aber genau wieder, wie es effizienter und auch sauberer geht.

In JavaScript ist alles was kein primitiver Datentyp ist, ein Objekt. Objekte sind, Reference-Types. Primitive Datentypen sind Value-Types.

Wer den Unterschied nicht kennt:

(Quelle: Internet)

Dieses Verhalten können wir uns zu Nutze machen.

Dass ein Knoten ein Reference-Type sind, ist denke ich klar. Bei dem Children-Property am Knoten handelt es sich um ein Array mit weiteren Knoten. Ein Array ist ebenfalls kein primitiver Datentyp und somit auch ein Reference-Type.

Der Ansatz ist folgender:

Man erzeugt ein leeres Array für den tree.
Man erzeugt eine leere Map.
In einer do-while (oder while je nachdem was du mehr magst 😅) Iterierst du so lange, bis das Datenarray leer ist. In jeder iteration machst du folgendes:
1. Erzeuge eine leeres array, welches die Kindknoten für den aktuellen Eintrag halten soll.
2. data.shift() um den nächsten Eintrag aus dem Daten-Array zu holen
3. Prüfe ob der Eintrag ein Wurzelknoten ist.
  - Falls ja, erzeuge einen Baumknoten und ordne diesem das gerade erzeugte Array als Array für die Kindknoten hinzu. Diesen Baumknoten fügst du in das tree Array ein und legst in der Map einen Eintrag mit der ID des Knoten und den Kindknoten array hinzu.
  - Falls nein und die ParentId in der Map vorhanden ist, wiederhole den vorherigen Schritt mit der Ausnahme, dass du den Baumknoten nicht dem tree Array sondern dem Kindknoten Array aus der Map hinzufügst.
  - Ansonsten machst du ein data.push(node) um den Knoten wieder hinten anzufügen.

Als Code könnte es zum Beispiel so aussehen:

interface FlatNode {
  Id: number;
  Name: string;
  ParentId?: number;
}

interface TreeNode extends FlatNode {
  Children: TreeNode[];
}

const data: FlatNode[] = [
  {Id: 1, Name: '1', ParentId: null},
  {Id: 2, Name: '1 - 1', ParentId: 1},
  {Id: 3, Name: '1 - 2', ParentId: 1},
  {Id: 4, Name: '1 - 3', ParentId: 1},
  {Id: 5, Name: '1 - 2 - 1', ParentId: 3},
];

const tree: TreeNode[] = [];
const childrenMap = {};
let notFoundCounter = 0;

do {
  const next = data.shift();

  const nextChildren = [];
  if (next.ParentId == null) {
    tree.push({...next, Children: nextChildren});
  } else if (next.ParentId in childrenMap) {
    childrenMap[next.ParentId].push({...next, Children: nextChildren});
  } else {
    notFoundCounter++;
    data.push(next);
    continue;
  }

  childrenMap[next.Id] = nextChildren;
  if (notFoundCounter > 0) {
    notFoundCounter--;
  }
} while (data.length > 0 && notFoundCounter < data.length);

Und das wars auch schon 🙂
Da es sich bei der Map lediglich um Referenzen zu den Arrays mit den Kindknoten der jeweiligen Knoten handelt, ist der Overhead an Speicherverbrauch entsprechend gering.

Wer's bequemer haben möchte, kann es natürlich auch noch in eine Funktion packen:

function unflat<T>(data: T[],
                   id: (o: T) => (string | number),
                   parentId: (o: T) => (string | number),
                   childrenPropertyName: string = 'Children',
): (T & any)[] {

  if (!data || data.length <= 0) {
    return [];
  }

  const tree = [];
  const childrenMap = {};

  let notFoundCounter = 0;

  do {
    const current = data.shift();

    const nextChildren = [];
    const currentParentId = parentId(current);

    if (currentParentId == null) {
      tree.push({...current, [childrenPropertyName]: nextChildren});
    } else if (currentParentId in childrenMap) {
      childrenMap[currentParentId].push({...current, [childrenPropertyName]: nextChildren});
    } else {
      notFoundCounter++;
      data.push(current);
      continue;
    }

    childrenMap[id(current)] = nextChildren;
    if (notFoundCounter > 0) {
      notFoundCounter--;
    }
  } while (data.length > 0 && notFoundCounter < data.length);

  return tree;
}

const data: FlatNode[] = [
  {Id: 1, Name: '1', ParentId: null},
  {Id: 2, Name: '1 - 1', ParentId: 1},
  {Id: 3, Name: '1 - 2', ParentId: 1},
  {Id: 4, Name: '1 - 3', ParentId: 1},
  {Id: 5, Name: '1 - 2 - 1', ParentId: 3},
];

const tree = unflat(data, (o) => o.Id, (o) => o.ParentId);
console.log(tree);

Ich finde dieses Beispiel ist ein gutes Beispiel dafür, dass man nicht immer nur auf Algorithmen selber sondern auch auf die Datenhaltung schauen sollte, wenn man schnellen und zugleich verständlichen Code schreiben möchte.

Was hältst du von dem Ansatz? Vorschläge? Alternativen? Ab in die Kommentare damit.

Eine Angular Library schreiben

Julian Finkler — Sun, 01 Dec 2019 12:40:12 +0000

Es kommt vor, dass man Code für eine Angular Anwendung schreibt, den man eigentlich in mehreren Projekten benötigt.
Anstatt den Code zu kopieren und somit gegen das DRY Prinzip zu verstoßen, ist es sinnvoll, den Code zu isolieren und als eigene Angular Library zu veröffentlichen.

Neues Projekt anlegen

Um die Library entwickeln zu können, müssen wir zuerst ein neues Angular Projekt bzw. einen Workspace anlegen.

Workspaces unterscheiden sich von "normalen" Angular Anwendungen darin, dass es kein einzelnes Projekt gibt, sondern einen Arbeitsbereich hat, in dem man mehrere Projekte hinzufügen kann.

Wir brauchen somit:

ein Library Projekt in welchem wir den Code, den wir isolieren wollen, schreiben und
eine Angular Anwendung, mit welcher wir die Library testen können.

Legen wir als erstes einmal den Workspace an. Ich möchte in meinem konkreten Fall einen Form Generator schreiben. Durch die Option --create-application=false wird ein Workspace anstatt einem Projekt erzeugt

$ ng new form-builder --create-application=false

Would you like to add Angular routing? No
Which stylesheet format would you like to use? CSS

CREATE form-builder/README.md (1028 bytes)
CREATE form-builder/.editorconfig (246 bytes)
CREATE form-builder/.gitignore (629 bytes)
CREATE form-builder/angular.json (135 bytes)
CREATE form-builder/package.json (1263 bytes)
CREATE form-builder/tsconfig.json (435 bytes)
CREATE form-builder/tslint.json (1621 bytes)

// ...

Als nächstes wechseln wir in das Workspace Verzeichnis und legen das Library Projekt und die Beispiel Anwendung an

$ cd form-builder
$ ng g library form-builder
$ ng g application form-builder-example

Im Verzeichnis projects sollten bei dir nun 3 Projekte liegen. Einmal das Library Projekt, dann die Angular Anwendung und dann noch die e2e Tests der Angular Anwendung.

projects/
|- form-builder
|- form-builder-example/
|- form-builder-example-e2e/

Das Library Projekt hat einen Ordner src/lib. In diesem befindet sich der Code deiner Library. Außerdem existiert eine Datei src/public-api.ts. In dieser musst du alles hinterlegen, was du aus deiner Library für andere Anwendungen verfügbar machen möchtest. Das können z.B. Komponenten oder Services sein.

Build Script

Als nächstes musst du in der Workspace übergreifenden package.json zwei neue Scripts hinzufügen.

{
  "scripts": {
    // ...
    "lib:build": "ng build form-builder",
    "lib:dev": "ng build form-builder --watch"
  }
}

lib:build dient zum bauen der Library und lib:dev zum ausführen des build Prozess während der Entwicklungszeit.

Führe zunächst einmal npm run lib:build aus, um die Library einmal initial zu bauen.

Library einbinden

Um nun deine Library in der Example Anwendung verwenden zu können, musst du in der Example Anwendung im AppModule (projects/form-builder-example/src/app/app.module.ts) im @NgModule Decorator unter imports die Library importieren.
Wichtig: wir wollen die gebaute Version verwenden, deshalb achte darauf, dass du die richtige Datei aus dem dist/ Verzeichnis importierst.

// projects/form-builder-example/src/app/app.module.ts

// ...

import {FormBuilderModule} from '../../../../dist/form-builder'; // <--

@NgModule({
  // ...
  imports: [
    // ...
    FormBuilderModule, // <--
  ],
  // ...
})
export class AppModule {
}

Nun kannst du in einer Kommandozeile ng serve und in einer zweiten npm run lib:dev ausführen.

Unter http://localhost:4200 kannst du deine Testanwendung aufrufen.

Library verwenden

Du kannst nun wie gewohnt im Verzeichnis deiner Example Anwendung den Code aus der Library verwenden. In meinem konkreten Fall habe ich z.B. im app.component.html einfach die <form-builder> Komponente eingebunden.

Zusammenfassung

Du weißt nun was ein Angular Workspace ist und kannst einen solchen anlegen. Außerdem weißt du nun, wie du ein Library Projekt anlegst und in einer example Anwendung einbindest und testen kannst.

Zum veröffentlichen der Library im NPM Repository, kannst du dir am besten die Dokumentation anschauen.

Danke für's lesen und ich hoffe ich konnte alles verständlich rüberbringen.

Fragen und Anregungen gerne in die Kommentare🙂

Clean Architecture in TypeScript Projekt: Angular als Plugin

Julian Finkler — Sat, 30 Nov 2019 22:25:00 +0000

Im letzten Teil des Beitrags haben wir die Business Logik unseres Aufgaben Tools programmiert. In diesem Teil geht es darum, unsere Anwendung zum Leben zu erwecken.
Ich verwende hierzu Angular und ich gehe davon aus, dass du dich damit schon auskennst, weil ich nicht näher auf die Installation der CLI etc. eingehen werde.

Neues Angular Projekt

Als erstes starten wir, außerhalb des Verzeichnisses des letzten Beitrags, ein neues Angular Projekt.

$ ng new todo-app

Would you like to add Angular routing? No
Which stylesheet format would you like to use? CSS
CREATE todo-app/README.md (1024 bytes)
CREATE todo-app/.editorconfig (246 bytes)
CREATE todo-app/.gitignore (629 bytes)
CREATE todo-app/angular.json (3825 bytes)
CREATE todo-app/package.json (1307 bytes)
CREATE todo-app/tsconfig.json (435 bytes)
CREATE todo-app/tslint.json (1621 bytes)
CREATE todo-app/src/favicon.ico (5430 bytes)
CREATE todo-app/src/index.html (294 bytes)
CREATE todo-app/src/main.ts (372 bytes)
CREATE todo-app/src/polyfills.ts (2841 bytes)
CREATE todo-app/src/styles.css (80 bytes)
CREATE todo-app/src/test.ts (642 bytes)
CREATE todo-app/src/browserslist (388 bytes)
CREATE todo-app/src/karma.conf.js (1021 bytes)
CREATE todo-app/src/tsconfig.app.json (166 bytes)
CREATE todo-app/src/tsconfig.spec.json (256 bytes)
CREATE todo-app/src/tslint.json (244 bytes)
CREATE todo-app/src/assets/.gitkeep (0 bytes)
CREATE todo-app/src/environments/environment.prod.ts (51 bytes)
CREATE todo-app/src/environments/environment.ts (662 bytes)
CREATE todo-app/src/app/app.module.ts (314 bytes)
CREATE todo-app/src/app/app.component.css (0 bytes)
CREATE todo-app/src/app/app.component.html (1120 bytes)
CREATE todo-app/src/app/app.component.spec.ts (984 bytes)
CREATE todo-app/src/app/app.component.ts (212 bytes)
CREATE todo-app/e2e/protractor.conf.js (752 bytes)
CREATE todo-app/e2e/tsconfig.e2e.json (213 bytes)
CREATE todo-app/e2e/src/app.e2e-spec.ts (637 bytes)
CREATE todo-app/e2e/src/app.po.ts (251 bytes)
...

Business Logik hinzufügen

Als nächstes kopierst du den Inhalt deiner Business Logik, aus dem letzten Beitrag, nach todo-app/src/app, damit folgende Struktur entsteht:

todo-app/
|- src/
|  |- app/
|  |  |- core/
|  |  |  |- entity/
|  |  |  |- repository/
|  |  |  |- use-case/
|  |  |- data/
|  |  |- infrastructure/
|  |  |- presentation/
|  |  |- app.module.ts

...

Angular Core Module erzeugen

Dieser Schritt entfällt da die UseCases mit @Injectable({providedIn: 'root'}) dekoriert werden.

Weiter zum nächsten Schritt

~~Als nächstes erzeugen wir ein Core Modul für Angular. Darin werden all unsere Use Cases und Services registriert.~~

$ ng g m core

Nun sollte eine Datei src/app/core/core.module.ts bei dir angelegt worden sein, welche du nun öffnest.
In dem @NgModule Decorator fügst du nun das Feld providers: [] hinzu, in welchem du deine UseCases hinterlegst.

// src/app/core/core.module.ts
import {AddToDoUseCase, DeleteToDoUseCase, EditToDoUseCase, ShowToDoListUseCase} from './use-case';

@NgModule({
  // ...
  providers: [
    AddToDoUseCase,
    DeleteToDoUseCase,
    EditToDoUseCase,
    ShowToDoListUseCase,
  ]
})
export class CoreModule {
}

~~Nun musst du noch das CoreModule in dem AppModule importieren, damit in der Angular Anwendung auf die UseCases zugegriffen werden kann.~~

// src/app/app.module.ts
import {CoreModule} from './core/core.module';

@NgModule({
  imports: [
    CoreModule, // <--
  ],
})
export class AppModule { }

Dependency Injection Fehler beheben

Wenn du jetzt mit ng serve die Anwendung 'servierst', wirst du beim Aufruf der Anwendung nichts sehen und in der Konsole einen Fehler wie Can't resolve all parameters for AddToDoUseCase: (?, ?, ?). sehen.

Das liegt daran, dass Angular die Abhängigkeiten nicht automatisch injiziert. Hierfür gibt es nun zwei Lösungen.

Du verdrahtest alles manuell im CoreModule ({useClass: AddToDoUseCase, dependencies: [...]})
Du fügst den UseCases die @Injectable() Decorator von Angular hinzu.

Beide Lösungen haben Vor- und Nachteile. Bei der ersten Lösung hältst du deinen Code getrennt vom Angular Kram, du hast jedoch jede Menge zu tun um Services zu verdrahten.
Bei der zweiten Lösung koppelst du Angular Code an deine UseCases, sparst dir aber auf der anderen Seite viel Schreibarbeit.

Und damit kommen wir zu dem 'Beweis' dass sich Architekturen in der Praxis selten 1:1 umsetzen lassen. Ich persönlich habe Variante 1 ausprobiert, diese hat mich jedoch extrem ausgebremst, weswegen ich mittlerweile Variante 2 nutze - auch wenn es nicht schön ist. Aber hey, es ist lediglich ein Decorator der mir die Arbeit sehr vereinfacht und die Fehlerrate reduziert (falsch verdrahtete Services etc.) 😅.
(Wer für Lösung 1 eine Alternative kennt, bitte kommentieren 🙂)

Deine Aufgabe besteht nun darin, alle vier UseCases mit @Injectable({providedIn: 'root'}) zu dekorieren.

Nach dem du das erledigt hast, sollte die Anwendung ohne Probleme laden.

Presentation Layer

Als nächstes machen wir uns an die Liste der Aufgaben. Generiere hierzu einfach mit ng g c presentation/todo-list die Angular Komponente.

Als nächstes ersetzt du noch den Inhalt der Datei src/app/app.component.html mit

<h1>Meine Aufgaben</h1>
<app-todo-list></app-todo-list>

ViewModel und Presenter anlegen

Wie du dich sicherlich erinnerst, verwenden unsere UseCases einen Presenter um Daten darzustellen. Presenter bereiten die Daten entsprechend für die View auf und schreiben die Daten in das ViewModel.

Ich habe mir als Namenskonvention [component].view-model.ts und [component].presenter.ts angeeignet. Somit haben die Dateinamen im Verzeichnis der Komponente den gleichen Aufbau.

ViewModel

Da wir in unserer Anwendung die Aufgaben nicht wirklich für die View aufbereiten müssen, reicht es wenn wir einfach das ToDo Entity missbrauchen und dem ViewModel eine Property vom Typen ToDo[] geben.

// src/app/presentation/todo-list/todo-list.view-model.ts
import {ToDo} from '../../core/entity';

export class TodoListViewModel {
  public toDos: ToDo[] = null;
}

Presenter

Weiter geht es mit dem Presenter. Wenn du dir jetzt denkst, dass du da den ShowToDoListPresenter verwenden musst, liegst du goldrichtig!

Unser TodoListPresenter erweitert einfach den ShowToDoListPresenter<T>. Als Typ-Argument geben wir das gerade angelegte TodoListViewModel an. Außerdem rufen wir im Konstruktor super(TodoListViewModel); auf.

Jetzt musst du nur noch die displayToDos Methode implementieren, welche lediglich toDos in das ViewModel schreibt, und schon ist unser Presenter für die Aufgabenliste fertig.

// src/app/presentation/todo-list/todo-list.presenter.ts
import {ShowToDoListPresenter} from '../../core/use-case';
import {TodoListViewModel} from './todo-list.view-model';
import {ToDo} from '../../core/entity';

export class TodoListPresenter extends ShowToDoListPresenter<TodoListViewModel> {

  constructor() {
    super(TodoListViewModel);
  }

  public displayToDos(toDos: ToDo[]): void {
    this.viewModel.toDos = toDos;
  }
}

TodoListPresenter bekannt machen

Aktuell weiß Angular noch nicht, was für ShowToDoListPresenter<T> injected werden soll. Um das zu ändern, erzeugst du erst einmal das PresentationModule

$ ng g m presentation

Anschließend referenzierst du dieses im AppModule. In diesem entfernst du zusätzlich die Verwendung der TodoListComponent.

// src/app/app.module.ts
import {BrowserModule} from '@angular/platform-browser';
import {NgModule} from '@angular/core';

import {AppComponent} from './app.component';
import {CoreModule} from './core/core.module';
import {PresentationModule} from './presentation/presentation.module';

@NgModule({
  declarations: [
    AppComponent,
  ],
  imports: [
    BrowserModule,
    CoreModule,
    PresentationModule,
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule {
}

Im PresentationModule fügst du unter declarations und exports die TodoListComponent hinzu und verdrahtest unter providers die beiden Presenter.

// src/app/presentation/presentation.module.ts
import {NgModule} from '@angular/core';
import {CommonModule} from '@angular/common';
import {TodoListComponent} from './todo-list/todo-list.component';
import {ShowToDoListPresenter} from '../core/use-case';
import {TodoListPresenter} from './todo-list/todo-list.presenter';

@NgModule({
  declarations: [
    TodoListComponent, // <--
  ],
  imports: [
    CommonModule,
  ],
  exports: [
    TodoListComponent, // <--
  ],
  providers: [
    {provide: ShowToDoListPresenter, useClass: TodoListPresenter}, // <--
  ]
})
export class PresentationModule {
}

Component zum Leben erwecken

Nach wie vor macht unsere Anwendung nichts als

Meine Aufgaben

todo-list works!

ausgeben. Das wollen wir jetzt ändern.

Injecte zunächst den ShowToDoListUseCase als private readonly und den ShowToDoListPresenter<T> als public readonly.
Im body des Konstruktors rufst du dann presenter.reset() auf, wodurch das ViewModel neu initialisiert wird. Danach rufst du useCase.execute() auf, um die Business Logic unserer Aufgaben-Liste

// src/app/presentation/todo-list/todo-list.component.ts
constructor(private readonly useCase: ShowToDoListUseCase,
            public readonly presenter: ShowToDoListPresenter<TodoListViewModel>,
) {
  presenter.reset();

  useCase.execute();
}

Wenn du die Seite jetzt wieder Aufrufst, erscheint wieder ein Fehler.
Die Ursache ist in Zeile 3 zu finden.

AppComponent.ngfactory.js? [sm]:1 ERROR Error: StaticInjectorError(AppModule)[EditToDoUseCase -> TodoRepository]: 
  StaticInjectorError(Platform: core)[EditToDoUseCase -> TodoRepository]: 
    NullInjectorError: No provider for TodoRepository!

...

Klar, wir haben ja noch gar keine Datenquelle für unsere Aufgaben.

Daten Layer

Als nächstes müssen wir das TodoRepository implementieren. Dieses wird sich im DataModule befinden, welches mit ng g m data angelegt wird.
Dieses musst du, wie auch schon die anderen Module im AppModule importieren.

TodoRepository implementieren

Das Repository ist nichts anderes als ein Angular Service. Diesen erzeugst du mit ng g s data/repository/todo-repository. Die Klasse selber muss natürlich vom TodoRepository aus dem Core extenden.

Um das Beispiel einfach zu halten, werden die Aufgaben nur temporär gespeichert, also nach einem Neuladen der Seite ist die Aufgabenliste wieder leer.

// src/app/data/repository/todo-repository.service.ts
import {Injectable} from '@angular/core';
import {TodoRepository} from "../../core/repository";
import {ToDo} from "../../core/entity";

@Injectable({
  providedIn: 'root'
})
export class TodoRepositoryService extends TodoRepository {

  private toDos: ToDo[] = [];

  public async createToDo(todo: ToDo): Promise<ToDo> {
    this.toDos.push(todo);
    return this.toDos[this.toDos.length - 1];
  }

  public async deleteToDo(id: number): Promise<void> {
    if (this.toDos[id] === null) {
      throw new Error('Diese Aufgabe existiert nicht.');
    }

    this.toDos.splice(id, 1);

    return;
  }

  public async editToDo(id: number, todo: ToDo): Promise<ToDo> {
    if (this.toDos[id] === null) {
      throw new Error('Diese Aufgabe existiert nicht.');
    }

    this.toDos[id] = todo;
    return this.toDos[id];
  }

  public async getAllToDos(): Promise<ToDo[]> {
    return this.toDos;
  }
}

Auch in diesem Fall muss der Service im DataModule bereitgestellt werden

// src/app/data/data.module.ts
providers: [
  {provide: TodoRepository, useClass: TodoRepositoryService}
]

Wenn du die Seite jetzt neu lädst sollte der Fehler verschwinden.

Liste + Aktionsbuttons rendern

Na, schon aus der Puste?🙂 Ist nicht mehr viel, versprochen.
Als nächstes soll die Liste mit den Aufgaben sowie Buttons zum anlegen, bearbeiten und löschen angezeigt werden.

Wechsle dafür erst einmal in das Template der TodoListComponent.

<!-- src/app/presentation/todo-list/todo-list.component.ts -->
<button (click)="addToDo()">Aufgabe hinzufügen</button>
<ul>
  <li *ngFor="let todo of presenter.viewModel.toDos; index as id">
    <label>
      <input type="checkbox" [checked]="todo.isDone" (change)="setToDoState(id, todo)">
      {{ todo.description }}
    </label>
    <button (click)="editToDo(id, todo)">Bearbeiten</button>
    <button (click)="deleteToDo(id)">Löschen</button>
  </li>
</ul>

Sollte soweit verständlich sein. Der erste Button ist zum hinzufügen von Aufgaben, die ungeordnete Liste zeigt die Aufgaben an, wobei die Checkbox den Status der Aufgabe anzeigt. Mit den beiden Buttons lässt sich die Aufgabe bearbeiten bzw. löschen.

Als nächstes müssen wir den Code für die Buttons schreiben. Wechsle also in den TypeScript Teil der Komponente.
Dort fügst du als erstes einmal die anderen UseCases als private readonly im Konstruktor hinzu.

// src/app/presentation/todo-list/todo-list.component.ts
constructor(private readonly useCase: ShowToDoListUseCase,
            public readonly presenter: ShowToDoListPresenter<TodoListViewModel>,
            private readonly addToDoUseCase: AddToDoUseCase, // <--
            private readonly editToDoUseCase: EditToDoUseCase, // <--
            private readonly deleteToDoUseCase: DeleteToDoUseCase, // <--
) {
  presenter.reset();

  useCase.execute();
}

Anschließend fügst du noch die Funktionen hinzu, welche die Buttons im Template aufrufen.

// src/app/presentation/todo-list/todo-list.component.ts
public addToDo() {
  this.addToDoUseCase.execute();
}

public setToDoState(id: number, todo: ToDo) {
  this.editToDoUseCase.execute({id, todo, onlyToggleDone: true})
}

public editToDo(id: number, todo: ToDo) {
  this.editToDoUseCase.execute({id, todo, onlyToggleDone: false})
}

public deleteToDo(id: number) {
  this.deleteToDoUseCase.execute(id);
}

Wenn du jetzt die Seite lädst, dann sollte... es wieder ein Fehler geben 😉

AppComponent.ngfactory.js? [sm]:1 ERROR Error: StaticInjectorError(AppModule)[EditToDoUseCase -> InteractionService]: 
  StaticInjectorError(Platform: core)[EditToDoUseCase -> InteractionService]: 
    NullInjectorError: No provider for InteractionService!

Stimmt, unser Interaction Service fehlt noch.

Infrastruktur Modul und InteractionService

Als letzten Schritt, muss noch das Infrastruktur Modul sowie der InteractionService erzeugt werden. (Modul nicht vergessen zu importieren)

$ ng g m infrastructure 
$ ng g s infrastructure/service/interaction

Im InfrastructureModule verlinkst du wieder den Service aus dem Core:

// src/app/infrastructure/infrastructure.module.ts

import * as CoreService from "../core/service";

// ...

providers: [
  {provide: CoreService.InteractionService, useClass: InteractionService},
]

Die Implementierung des InteractionService ist auch überschaubar, hier verwenden wir einfach die Standard JS Funktionen confirm und prompt.

import {Injectable} from '@angular/core';
import * as CoreService from "../../core/service";

@Injectable({
  providedIn: 'root'
})
export class InteractionService implements CoreService.InteractionService {

  public async confirm(message: string): Promise<boolean> {
    return confirm(message);
  }

  public async enterString(currentValue?: string): Promise<string> {
    return prompt("Eingabe:", currentValue);
  }
}

Und damit bist du fertig🙂.

Falls es bei dir Probleme gibt, schau mal bei GitHub vorbei. Dort findest du den kompletten Code.

Zusammenfassung

Du hast heute die Application Logic für die Business Logic aus dem vorherigen Beitrag implementiert. Aus abstrakten Services wurden konkrete Implementationen. Service Abhängigkeiten werden per Dependency Injection injiziert.
Schau dir einmal den tatsächlich geschriebenen Code im Data / Infrastructure / Presentation Layer an.
Ich persönlich war anfangs ziemlich erstaunt, wie wenig das ist.

Außerdem ist die Kopplung so lose, dass du den TodoRepositoryService problemlos durch einen Service ersetzen könntest, der mit einer API kommuniziert und Daten permanent speichert.

Fragen / Anregungen gerne in die Kommentare 🙂

JavaScript: Map an array of objects to a dictionary

Julian Finkler — Sat, 23 Nov 2019 20:45:39 +0000

The easiest way for converting an array of objects to a dictionary in JavaScript / TypeScript:

let data = [
  {id: 1, country: 'Germany', population: 83623528},
  {id: 2, country: 'Austria', population: 8975552},
  {id: 3, country: 'Switzerland', population: 8616571}
];

let dictionary = Object.assign({}, ...data.map((x) => ({[x.id]: x.country})));
// {1: "Germany", 2: "Austria", 3: "Switzerland"}

Clean Architecture in TypeScript Projekt: Geschäftslogik

Julian Finkler — Fri, 22 Nov 2019 08:42:06 +0000

Vorweg: In diesem Beitrag geht es nicht darum Clean Architecture zu erklären, sondern wie meine Erfahrung in einem TypeScript Projekt waren und wie man die Architektur in einem TypeScript bzw. später Angular Projekt implementieren kann.

title: "Clean Architecture in einem TypeScript Projekt"

series: Clean Architecture in Typescript

Dieses Jahr habe ich mich ziemlich viel mit Architekturen und Design Patterns auseinander gesetzt.
Irgendwann Mitte des Jahres bin ich auf Clean Architecture von Robert C. Martin gestoßen und war über den Lösungsansatz ziemlich begeistert.

Alles easy going... nicht

Als begeisterter Programmierer wollte ich natürlich das ganze Konzept nun in meine Projekte einbauen. Somit fing ich an, mir das ganze einmal näher anzuschauen. Alles schien auf den ersten Blick im Diagramm ganz logisch und einfach umsetzbar. Es gibt verschiedene Schichten (wie bei der Zwiebel-Architektur), wobei die jeweilige Schicht nur Code in der eigenen Schicht und den inneren Schichten kennt, jedoch nichts äußeres - auch keine Referenzen, Imports etc.. Grundsätzlich lässt sich das mit dem DIP lösen.

Und dann ging es langsam mit den Fragen wie "Wer erzeugt die Instanzen meiner Klassen?" oder "Wie strukturiere ich meinen Code am besten?" los.

Tatsächlich brauchte es 4-6 Wochen bis ich das ganze Konzept hinter Clean Architecture verstanden habe und noch mal zwei weitere Wochen um was halbwegs lauffähiges, was sich an die Architektur hält, zu programmieren.

Eine Architektur lässt sich in der Praxis nie zu 100% umsetzen...

...wenn man Produktiv bleiben möchte. 🙂

Ich habe versucht, die Architektur haargenau in einem Angular Projekt umzusetzen. Das Ergebnis war ernüchternd. Die ganzen Vorteile die geschaffen wurden, wurden durch einen Slowdown überdeckt. Viele neue Dateien, welche zum Teil nur Datenstrukturen abbilden und keine vernünftige Ordnerstruktur (Screaming Architecture; ist meiner Meinung nach in Kombination mit Clean Architecture der Obergau) machten ein produktives arbeiten im Projekt unmöglich.
Also hieß es git reset --hard origin/master

Grundstruktur definieren

Durch die Erkenntnis, dass es viele neue Dateien geben wird, wollte ich nun zuerst einmal die Ordnerstruktur festlegen. Diese verwende ich mittlerweile überwiegend, da sie für mich gut funktioniert.

Root
|- core/
|  |- entity/
|  |- repository/
|  |- use-case/
|- data/
|- infrastructure/
|- presentation/

core beinhaltet alles an Business Logic. Dieser Ordner repräsentiert also die beiden innersten Layer. Ich könnte problemlos den Code vom core Verzeichnis von einem Angular Projekt in ein Vue Projekt kopieren und müsste darin nichts ändern um die Businesslogik zu übernehmen.

In data werden Datenmodelle, welche z.B. für den Austausch mit einer API benötigt werden, gespeichert. Außerdem befinden sich in diesem Ordner auch die Implementierungen der abstrakten Repositories aus dem Core Verzeichnis.

Im Verzeichnis infrastructure sind z.B. Implementierungen der abstrakten Services, welche im Core benötigt werden, zu finden. Hierbei fällt z.B. ein TranslationService oder ein InteractionService der mit dem Benutzer interagiert.

Ich denke, die Bedeutung vom Verzeichnis presentation ist klar. Hier findet sich alles, was mit UI zu tun hat.

Grundpfeiler: UseCase und Presenter

Ich habe im Verzeichnis core noch einen Ordner arch angelegt. In diesem befinden sich mit den folgenden drei Dateien, der "Basiscode" für die Architektur:

// core/arch/index.ts
export * from './use-case';
export * from './presenter';

// core/arch/presenter.ts
export abstract class Presenter<TView> {
  public viewModel: TView;

  constructor(private template: new() => TView,
  ) {
  }

  public reset(): void {
    const model = new this.template();

    if (this.viewModel == null) {
      this.viewModel = model;
    } else {
      Object.assign(this.viewModel, model);
    }
  }
}

// core/arch/use-case.ts
export interface IUseCase<TRequest, TPresenter> {
    readonly presenter: TPresenter;

    execute(request: TRequest): Promise<void>;
}

Eine "To Do App" soll es sein

Bei SPAs ist eine Aufgaben App das "Hallo, Welt!" schlecht hin. Also los geht's. (Den Code gibt's auf GitHub)
Zunächst schreiben wir nur Business Logic, später wird diese in einer Angular Anwendung verwendet.

Erst einmal Use-Cases definieren

Die Use-Cases einer To Do App sind relativ überschaubar:

Liste der Aufgaben anzeigen
Aufgabe hinzufügen
Aufgabe bearbeiten
Aufgabe löschen
Aufgabe abhaken
Aufgabe abhaken rückgängig machen

Da wir Informatiker "bequem" sind, reichen uns auch vier Use-Cases

Liste der Aufgaben anzeigen
Aufgabe hinzufügen
Aufgabe bearbeiten (abgehakt ist eine Boolesche Variable 🤓)
Aufgabe löschen

Entity erstellen

Weiter geht's mit dem Model für eine Aufgabe. Um es einfach zu halten, gibt es nur eine Beschreibung und ein "Erledigt" Flag:

// core/entity/to-do.ts
export class ToDo {
    constructor(public description: string,
                public isDone: boolean = false,
    ) {
    }
}

Repository anlegen

Damit Aufgaben geladen, gespeichert und gelöscht werden können, wird ein Repository benötigt. Da wir uns zunächst im Core bewegen und im nächsten Schritt erst unsere Use Cases implementieren, reicht es eine abstrakte Klasse mit vier abstrakten Methoden anzulegen. Warum bei editToDo und deleteToDo eine id benötigt wird und woher die kommt, erkläre ich später.

// core/repository/todo.repository.ts
import {ToDo} from '../entity';

export abstract class TodoRepository {
    public abstract getAllToDos(): Promise<ToDo[]>;

    public abstract createToDo(todo: ToDo): Promise<ToDo>;

    public abstract editToDo(id: number, todo: ToDo): Promise<ToDo>;

    public abstract deleteToDo(id: number): Promise<void>;
}

Services anlegen

Damit der User nicht aus versehen eine Aufgabe löscht, muss nach dem Klick auf den löschen Button das löschen zuerst bestätigen. Um das einheitlich abzubilden schreiben wir einen abstrakten interaction.service.ts unter core/service (Verzeichnis anlegen😉). Diese Klasse enthält eine abstrakte Methode confirm, welche einen string als Input bekommt (Die Nachricht die bestätigt werden soll) und ein Promise<boolean> mit dem Ergebnis zurück gibt.
Außerdem enthält die Klasse noch eine abstrakte Methode enterString. Du kannst dir sicherlich denken wofür. Richtig, zum Bearbeiten der Aufgaben Beschreibung.

// core/service/interaction.service.ts
export abstract class InteractionService {

    public abstract confirm(message: string): Promise<boolean>;

    public abstract enterString(currentValue?: string): Promise<string>;
}

Use Cases

Nun geht's ans Eingemachte. Im Verzeichnis core/use-case wird nun die Datei show-to-do-list.use-case.ts angelegt. In dieser wird der UseCase zum Darstellen der Liste mit den bestehenden Aufgaben programmiert. Der UseCase selber lädt die Aufgaben aus dem TodoRepository und stellt diese mithilfe des Presenters dar.

Starten wir mit dem (abstrakten) List Presenter, dieser leitet von Presenter<T> ab, wobei das Typ Argument 1:1 durchgereicht wird. Es wird als nächstes noch eine abstrakte Methode benötigt, welche die geladenen Aufgaben entgegen nimmt.

// core/use-case/show-to-do-list.use-case.ts
import {IUseCase, Presenter} from '../arch';
import {ToDo} from '../entity';
import {TodoRepository} from '../repository';

export abstract class ShowToDoListPresenter<T> extends Presenter<T> {
    public abstract displayToDos(toDos: ToDo[]): void;
}

Als nächstes wird der eigentliche UseCase geschrieben. Dieser leitet vom IUseCase<T1, T1> ab. Wobei als T1 void übergeben wird, weil es ja keine request im eigentlichen Sinne gibt und als T2 der ShowListPresenter<any> übergeben wird.

Im constructor wird später der konkrete Presenter und das konkrete TodoRepository injected.

Die execute Methode ist relativ einfach gestrickt. Hier werden zuerst alle Aufgaben aus dem repository geladen und anschließend an den Presenter weitergegeben.

// core/use-case/show-to-do-list.use-case.ts
export class ShowToDoListUseCase implements IUseCase<void, ShowToDoListPresenter<any>> {

    constructor(public readonly presenter: ShowToDoListPresenter<any>,
                private readonly repository: TodoRepository,
    ) {
    }

    public async execute(request: void): Promise<void> {
        try {
            const allToDos = await this.repository.getAllToDos();
            this.presenter.displayToDos(allToDos);
        } catch (e) {
            console.error('Failed to load or present to dos: %o', e);
            throw e;
        }
    }
}

Neue Aufgabe anlegen

Der nächste UseCase der implementiert werden soll, ist add-to-do.use-case.ts. Auch hier implementieren wir wieder den IUseCase jedoch mit zwei mal void als Typ, da wir keine Request und auch keinen Presenter haben. Stattdessen injecten wir einfach den ShowToDoListUseCase und führen diesen aus, nachdem die Aufgabe hinzugefügt wurde

// core/use-case/add-to-do.use-case.ts
import {IUseCase} from '../arch';
import {ShowToDoListUseCase} from './show-to-do-list-use.case';
import {InteractionService} from '../service';
import {TodoRepository} from '../repository';
import {ToDo} from '../entity';

export class AddToDoUseCase implements IUseCase<void, void> {
    public readonly presenter: void;

    constructor(private readonly interaction: InteractionService,
                private readonly repository: TodoRepository,
                private readonly listUseCase: ShowToDoListUseCase,
    ) {
    }

    public async execute(request: void): Promise<void> {

        try {
            const description = await this.interaction.enterString();
            if (description == null || description.trim() === '') {
                return;
            }

            const todo = new ToDo(description);
            await this.repository.createToDo(todo);

            await this.listUseCase.execute();
        } catch (e) {
            console.error('Failed to create a todo: %o', e);
            throw e;
        }

    }
}

Aufgabe bearbeiten

Zum bearbeiten von Aufgaben erstellst du den edit-to-do.use-case.ts.
In diesem Fall leitet der UseCase wieder von IUseCase ab. Als Request Typen wird EditToDoRequest und als Presenter Typen void übergeben.

Die Request Klasse hat drei Felder, die id der Aufgabe, das todo selber und ein Flag onlyToggleDone welches angibt, ob die Aufgabe lediglich als erledigt / nicht erledigt markiert werden soll.

In den UseCase selber wird wieder der InteractionService, das TodoRepository und der ShowToDoListUseCase injected.

Im execute wird zunächst geprüft, ob lediglich der Status der Aufgabe geändert werden soll. Ist das der Fall wird das isDone Flag der Aufgabe umgekehrt. Falls nicht, wird solange nach einer neuen Aufgaben Beschreibung gefragt, bis der User die Eingabe abbricht (null) oder mindestens ein nicht Whitespace Zeichen eingibt.

Anschließend wird in beiden Fällen die Aufgabe mit dem Repository gespeichert und der ShowToDoListUseCase ausgeführt, um die Liste zu aktualisieren.

// core/use-case/edit-to-do.use-case.ts
import {IUseCase} from '../arch';
import {ToDo} from '../entity';
import {InteractionService} from '../service';
import {TodoRepository} from '../repository';
import {ShowToDoListUseCase} from './show-to-do-list.use-case';

export class EditToDoRequest {

    constructor(public readonly id: number,
                public readonly todo: ToDo,
                public readonly onlyToggleDone: boolean = false,
    ) {
    }
}

export class EditToDoUseCase implements IUseCase<EditToDoRequest, void> {
    readonly presenter: void;

    constructor(private readonly interaction: InteractionService,
                private readonly repository: TodoRepository,
                private readonly listUseCase: ShowToDoListUseCase,
    ) {
    }

    public async execute(request: EditToDoRequest): Promise<void> {
        try {
            const todo = new ToDo(request.todo.description, request.todo.isDone);
            if (request.onlyToggleDone) {
                todo.isDone = !todo.isDone;
            } else {
                do {
                    todo.description = await this.interaction.enterString(todo.description);
                    if (todo.description == null) {
                        return;
                    }
                } while (todo.description.trim() == '')
            }

            await this.repository.editToDo(request.id, todo);

            await this.listUseCase.execute();
        } catch (e) {
            console.error('Failed to edit a todo: %o', e);
            throw e;
        }
    }
}

Aufgabe löschen

Zuletzt fehlt nun noch der Use Case zum löschen einer Aufgabe.
In diesem UseCase wird als Request Typ eine Zahl, nämlich die ID der Aufgabe übergeben.
Der Konstruktor sollte mittlerweile klar sein.

Beim execute wird der Nutzer zunächst gefragt, ob die Aufgabe gelöscht werden soll. Beantwortet der diese Frage mit false, wird die Ausführung des UseCase abgebrochen.
Andernfalls wird die Aufgabe mithilfe des TodoRepository gelöscht und die Liste der Aufgaben mit dem ShowToDoListUseCase aktualisiert.

// core/use-case/delete-to-do.use-case.ts
import {IUseCase} from '../arch';
import {InteractionService} from '../service';
import {TodoRepository} from '../repository';
import {ShowToDoListUseCase} from './show-to-do-list.use-case';

export class DeleteToDoUseCase implements IUseCase<number, void> {
    readonly presenter: void;

    constructor(private readonly interaction: InteractionService,
                private readonly repository: TodoRepository,
                private readonly listUseCase: ShowToDoListUseCase,
    ) {
    }

    public async execute(id: number): Promise<void> {
        try {
            if (!await this.interaction.confirm('Soll die Aufgabe gelöscht werden?')) {
                return;
            }

            await this.repository.deleteToDo(id);

            await this.listUseCase.execute();
        } catch (e) {
            console.error('Failed to delete a todo: %o', e);
            throw e;
        }
    }

}

Zusammenfassung

Du hast nun die komplette Business Logik unserer Aufgaben App programmiert.
Wie du sicherlich festgestellt hast, wurde noch keinen Gedanke an die Datenhaltung oder an das UI verschwendet, und das ist gut so.
Der Code ist so allgemein wie möglich gehalten, dass es sich hierbei um eine Konsolen-Anwendung oder eine Browser Anwendung handeln könnte.
Erst mit der Implementierung der Services und der Controller wird definiert, wo die Anwendung später laufen wird, wobei alles "drum-herum" als "Plugins" für deine Anwendung zu verstehen ist. Die Datenbank ist ein Plugin, das UI ist ein Plugin und auch ein Framework ist lediglich ein Plugin. Programmiere nicht nach einem Framework sondern passe das Framework an, sodass es mit deiner Anwendung funktioniert 😉 (z.B. per Wrapper Klassen).

Danke für's lesen, ich hoffe es war verständlich bis hier hin.

Im zweiten Teil des Beitrags geht es darum, die Services zu implementieren und mit Angular die Anwendung zum laufen zu bringen.