Using GIT for offline web app syncing and storage

Offline web applications, progressive web apps (PWA) using service workers for being available offline also needs a way to sync changes with the server. Mostly we store data in JSON documents, and we could identify changes per line - which is something GIT is excellent at. So how could we make the browser a GIT client?

I've been working on this for some months now, and compiled libgit2 to webassembly using emscripten - and it turns out to work very well.

Some video demos:

Cloning a repository:
Merging of file changes:

The project is here:

Link and watch changes in Angular libraries

ngmakelib now has a new feature that will watch for changes in your Angular library sources and rebuild. By using this with npm link you may make modifications in your library and see it immediately in your consuming app.

Angular for Java EE developers

Being a Java EE developer for a long time and trying to find a development platform in these times where more and more business logic is placed in the frontend code, Angular (NOT AngularJS) became a natural choice.

Being used to Java Server Faces with backend beans, coding with Angular is quite similar. You still have a HTML template and a separate class (Angular components) with the template logic, but now this is all part of the frontend code.

Also quite a bit of the code you would earlier place in EJB session beans can be put in Angular services, which can be injected into components using dependency injection.

All together with TypeScript which gives you static types, decorations (annotations), classes and interfaces that any Java developer will miss when coding with Javascript.

Now that the client / frontend does more and more of the traditional backend work, and the backend is more about providing data and access control than application business logic - Angular is a familiar pl…

Angular components not reloading on route change

Spent a long time wondering why route changes caused strange effects on my component, and found out that it was because my component wasn't reloading at all. I had this assumption that when a route parameter changed (e.g. /projects/1 changed to /projects/2 ) the component for the route would be reloaded. But this is not the default behaviour of the Angular router.

The default behaviour of the Angular router is to reuse the route if the configuration is the same (and not reload the component). But we can override this by providing a RouteReuseStrategy to our @NgModule:

providers: [ { provide: RouteReuseStrategy, useClass: AARouteReuseStrategy } ] The full custom implementation of the RouteReuseStrategy will then be like this (and it's the shouldReuseRoute method that changes the behaviour so that the component is reloaded on route parameter change): export class AARouteReuseStrategy extends RouteReuseStrategy { shouldDetach(route: ActivatedRouteSnapshot…

Multiple router outlets in Angular

Multiple router outlets in Angular makes it possible to have different sections in the view where the components are determined by the URL, and each outlet can have their own navigation.

Sometimes though - let's say you use named router outlets for the toolbar and the left side menu, you want the main URL to control the components to be showed for all outlets, not just the main outlet. In this case the router outlet configurations should be children on the main path as shown in the config snippet below.

This way the URL /projects/2018/myorganization will show a left side menu and a toolbar in addition to the main content component, while /projects/2018 will only show the toolbar.

If you want the toolbar only to show at the projects root path, but not children then add pathMatch: 'full' .

RouterModule.forChild([ { path: 'projects', children: [ { path: '', …

Angular 5 - Ahead of Time build configuration for rollup

Earlier the @angular Ahead of Time compilation cookbook showed you the compilation steps using the @angular/compiler-cli (ngc) and rollup. From Angular 5 it seems to be all about the Angular CLI (using ng build --prod). In some cases though it's nice to have the rollup recipe. We also want to benefit from the build optimizer and rxjs esm module which is default in Angular 5. So I've written down the configuration steps here for building a rollup-based AoT build for Angular 5. The typescript configuration for the @angular/compiler-cli (ngc). Store in file tsconfig_aot.json. { "compilerOptions": { "outDir": "js", "module": "es2015", "moduleResolution": "node", "target": "es5", "emitDecoratorMetadata": true, "experimentalDecorators": true, "lib": [ "dom", "es2017" …

Creating Angular libraries

When your app grows and you make components that could be reused in other apps it's a good thing to split out that code in a library. Also if your app is big already and someone else is going to add a new feature to it, it's much easier if they can work on that feature in a small isolated project and when ready import it into the main app as a library.

The architecture of Angular with modules help us organize the application code into blocks of functionality. The step of splitting into libraries should build on that, but add the benefits of not having to see code not relevant to the modules we're currently working on and to easily install and reuse in several applications without having to duplicate code across projects.

Creating an Angular library is basically about packaging compiled NgModules into a format that can be installed into another application using a package manager like npm. It could be done as easily adding the typescript sources and html templates to a tar.…