DEV Community: Sean Perkins

Ionic 6.1: Improved Virtual Scroll Compatibility

Sean Perkins — Wed, 13 Apr 2022 14:42:37 +0000

Ionic Framework 6.1 improves built-in feature compatibility for features such as fade header/footers, infinite scroll and item reordering with virtual scroll libraries. This allows applications to benefit from native designed features from Ionic with the performance of virtual scrolling.

With the .ion-content-scroll-host classname, implementations can specify which container is responsible for scrolling. Many custom features in Ionic make use of the scroll position and scroll listeners.

Below are a few usage examples for popular virtual scrolling libraries in React, Vue and Angular.

React (react-virtuoso)

const Footer = () => {
  return (
    <IonInfiniteScroll threshold="100px">
      <IonInfiniteScrollContent></IonInfiniteScrollContent>
    </IonInfiniteScroll>
  )
}

const Example = () => (
  <IonPage>
    <IonContent fullscreen scrollY={false}>
      <Virtuoso 
        className="ion-content-scroll-host"
        data={items}
        style={{ height: "100%" }}
        itemContent={(item) => <IonItem>{item}</IonItem>}
        components={{ Footer }} />
    </IonContent>
  </IonPage>
);

Vue (vue-virtual-scroller)

<template>
  <ion-page>
    <ion-content :fullscreen="true" :scroll-y="false">
      <RecycleScroller 
        class="ion-content-scroll-host scroller"
        :items="items"
        :item-size="50"
      >
      <template v-slot="{ item }">
        <ion-item>{{ item }}</ion-item>
      </template>
      <template #after>
        <ion-infinite-scroll threshold="100px">
          <ion-infinite-scroll-content></ion-infinite-scroll-content>
        </ion-infinite-scroll>
      </template>
      </RecycleScroller>
    <ion-content>
  </ion-page>
</template>

<style scoped>
  .scroller {
    height: 100%;
  }
</style>

Angular (@angular/cdk/scrolling)

<ion-content [fullscreen]="true" [scrollY]="false">
  <cdk-virtual-scroll-viewport itemSize="50" class="ion-content-scroll-host">
    <ion-item *cdkVirtualFor="let item of items">
      {{ item }}
    </ion-item>
    <ion-infinite-scroll threshold="100px">
      <ion-infinite-scroll-content></ion-infinite-scroll-content>
    </ion-infinite-scroll>
  </cdk-virtual-scroll-viewport>
</ion-content>

We hope that you find value in this feature and others in the 6.1.0 release.

Ionic 6.1: Dynamically changing the breakpoint of a Sheet Modal

Sean Perkins — Wed, 13 Apr 2022 14:42:25 +0000

Ionic Framework 6.1 introduces the ability to dynamically change the current breakpoint of a sheet modal. This features enables developers to animate sheet modals to predefined breakpoints based on your application needs.

To get started with this feature, you will need to use a sheet modal in Ionic. The below example is of Angular, but this feature applies to the vanilla web component implementation and all supported frameworks.

<ion-button id="sheet-modal">Click to open modal</ion-button>
<ion-modal #modal 
  trigger="sheet-modal"
  [initialBreakpoint]="0.25" 
  [breakpoints]="[0.25, 0.5, 1]">
  <ng-template>
    <ion-content>
      <ion-list>
        <ion-item button (click)="moveTo(0.25)">
          <ion-label>Move to 0.25</ion-label>
        </ion-item>
        <ion-item button (click)="moveTo(0.5)">
          <ion-label>Move to 0.5</ion-label>
        </ion-item>
        <ion-item button (click)="moveTo(1)">
          <ion-label>Move to 1</ion-label>
        </ion-item>
      </ion-list>
    </ion-content>
  </ng-template>
</ion-modal>

The above sheet modal will initially display when the button is clicked, to the 0.25 breakpoint. It has available breakpoints for 0.25, 0.5, and 1 (fully expanded).

To change the breakpoint dynamically, we need to query the ion-modal element to access the public API function: setCurrentBreakpoint.

import { Component, ElementRef, ViewChild } from '@angular/core';

@Component({
  selector: 'app-sheet-modal-example',
  templateUrl: 'sheet-modal-example.component.html'
})
export class SheetModalExample {

  @ViewChild('#modal') modal: ElementRef;

  moveTo(breakpoint: number) {
    const { nativeElement } = this.modal;
    if (!nativeElement) {
      return;
    }
    nativeElement.setCurrentBreakpoint(breakpoint);
  }

}

That is it, your sheet modal should now dynamically change the breakpoint value after interacting with the individual items to move to a specific breakpoint.

You can use this concept to make features such as an iOS maps clone:

Source code: https://github.com/sean-perkins/ionic-6.1.0-maps-example

We hope that you find value in this feature and others in the 6.1.0 release.

Ionic 6.1: Disabling Specific Dates, Weekends and Holidays

Sean Perkins — Wed, 13 Apr 2022 14:42:07 +0000

Ionic Framework 6.1 introduces the ability to control the disabled status of each individual day within an ion-datetime.

With the isDateEnabled function, you can write custom rules to disable specific dates, weekends, months, holidays, etc.

isDateEnabled accepts a ISO 8601 date string and must return a boolean (true for enabled, false for disabled).

Here are a few common scenarios you may run into with your applications:

Disabling Specific Dates

Disables January 1, 2022.

<ion-datetime></ion-datetime>

import { getDate, getMonth, getYear } from 'date-fns';

const isDateEnabled = (dateIsoString: string) => {
  const date = new Date(dateIsoString);
  if (getDate(date) === 1 && getMonth(date) === 0 && getYear(date) === 2022) {
    return false;
  }
  return true;
};

const datetime = document.querySelector('ion-datetime');
datetime.isDateEnabled = isDateEnabled;

Disabling Weekends

Disables Saturday and Sunday.

<ion-datetime></ion-datetime>

import { isWeekend } from 'date-fns';

const isDateEnabled = (dateIsoString: string) => {
  const date = new Date(dateIsoString);
  return !isWeekend(date);
};

const datetime = document.querySelector('ion-datetime');
datetime.isDateEnabled = isDateEnabled;

Disabling Holidays

Similar to disabling specific dates, you can also disable specific dates and months without comparing the year.

Disables December 25th.

<ion-datetime></ion-datetime>

import { getDate, getMonth, getYear } from 'date-fns';

const isDateEnabled = (dateIsoString: string) => {
  const date = new Date(dateIsoString);
  if (getDate(date) === 25 && getMonth(date) === 11) {
    return false;
  }
  return true;
};

const datetime = document.querySelector('ion-datetime');
datetime.isDateEnabled = isDateEnabled;

We hope that you find value in this feature and others in the 6.1.0 release.

Lazy translation assets with Angular, Transloco and Nx Buildable Libs

Sean Perkins — Mon, 13 Sep 2021 18:21:59 +0000

When dealing with applications that support multiple languages, it becomes increasingly more costly to have single translation asset files to contain all the key-value pairs for your application.

Instead, making use of webpack's inline loaders and Nx's buildable libs; you can fetch smaller translation assets only for a feature's scope, without requesting additional data.

Requirements

Nx workspace (mono-repo) with buildable libs.
Angular
Transloco as the translation library for handling your translations.
JSON files to contain your translation key-value pairs (en.json)

Tutorial

Shared i18n Library

Available/Supported Locales

In a shared library (i.e.: @workspace/i18n) create a constant of your application's supported locales.



export const AVAILABLE_LANGS = [
    'en',
    'ja',
    'fr-ca',
    'zh-cn'
];

Inline Loader Factory

In the same shared library, create a file for simplifying the interaction of using webpack's inline loader with the expected structure to use with Transloco's library.



import { AVAILABLE_LANGS } from './available-langs.const';

export function InlineLoaderFactory(loader: (lang: string) => Promise<any>) {
    return AVAILABLE_LANGS.reduce((acc: Translation, lang: string) => {
        acc[lang] = () => loader(lang);
        return acc;
    }, {});
}

Make sure to export your inline loader factory file to the root barrel of your shared Nx library.

Feature Lib

For this tutorial, we are separating out the translation assets for an authentication experience.

We will have an Nx library for authentication/web in libs/authentication/web of our Nx mono-repo.

Buildable libs

When creating a new library make sure to use the --buildable modifier to run the schematic for making your lib buildable.

If you are adding this to an existing lib that isn't already buildable you will need to:

Create an ng-package.json file in the root of your lib: ```json

{
"$schema": "../../../node_modules/ng-packagr/ng-package.schema.json",
"dest": "../../../dist/libs/authentication/web",
"lib": {
"entryFile": "src/index.ts"
}
}

- Create a `tsconfig.lib.prod.json`:
```json


{
    "extends": "./tsconfig.lib.json",
    "compilerOptions": {
        "declarationMap": false
    },
    "angularCompilerOptions": {
        "compilationMode": "partial"
    }
}

Update your workspace.json/project.json (depending if you are using standalone configs) to include a build target: ```json

"build": {
"executor": "@nrwl/angular:ng-packagr-lite",
"outputs": ["dist/libs/authentication/web"],
"options": {
"project": "libs/authentication/web/ng-package.json"
},
"configurations": {
"production": {
"tsConfig": "libs/authentication/web/tsconfig.lib.prod.json"
},
"development": {
"tsConfig": "libs/authentication/web/tsconfig.lib.json"
}
},
"defaultConfiguration": "production"
},

- Create a `package.json` of your library's workspace qualified name:
```json


{
    "name": "@workspace/authentication/web",
    "version": "0.0.1",
    "peerDependencies": {
        "@angular/common": "^12.2.0",
        "@angular/core": "^12.2.0"
    },
    "dependencies": {
        "tslib": "^2.3.0"
    }
}

Assets

In your lib, create a new directory called assets that is located at the root (/libs/authentication/web/assets/).

In this folder, add all of the JSON translation files for your feature and supported locales.



/assets/
       en.json
       ja.json
       fr-ca.json
       zh-cn.json

Next, update your ng-package.json to include your assets in the build process.



{
    "$schema": "../../../node_modules/ng-packagr/ng-package.schema.json",
    "dest": "../../../dist/libs/client/authentication/web",
    "lib": {
        "entryFile": "src/index.ts"
    },
    "assets": ["./assets"]
}

This step is extremely important. Without it, your JSON files will be purged from the generated /dist when the library is built. This will cause your webpack inline loaders to fail to load the translation assets only in a built environment.

Configuring Transloco for Feature Module

In your feature's main Angular module, configure Transloco to make use of webpack's inline loader and our library's assets.



import { NgModule } from '@angular/core';
import { TRANSLOCO_SCOPE } from '@ngneat/transloco';

@NgModule({
    imports: [...], // Lazy routing module and feature modules
    providers: [
        {
            provide: TRANSLOCO_SCOPE,
            useValue: {
                scope: 'auth',
                loader: InlineLoaderFactory((lang: string) => import(`../../assets/i18n/${lang}.json`))
       }
    ]
})
export class AuthenticationModule {}

The scope value, is the key prefix that will be added to all translation key-value pairs that are loaded from your assets directory.

Assuming you have a translation file such as:



{
    "login_form.title": "Enter your email"
}

The key will be re-written within the context of your feature module to be accessed as auth.login_form.title. You can learn more about scopes within Transloco here.

Using your translations

In the component's module making use of Transloco, import the TranslocoModule to make use of Transloco's built in pipes and directives.



import { TranslocoModule } from '@ngneat/transloco';

@NgModule({
    imports: [TranslocoModule]
})

Now, remembering the scope you defined earlier, you can use your translation in the component's template:



<p>{{ 'auth.login_form.title' | transloco }}</p>

Verifying and Validating

Build output

You should confirm that ng-packgr is configured correctly to generate and output your JSON assets alongside your generated JS bundles.

Using Nx's build command, build your library and validate the JSON assets are in the assets directory of the dist output.



nx build authentication-web

Network traffic

After making this change, you should be able to confirm that webpack's inline-loaders are loading the translation assets when your feature module is requested by your application (when making use of lazy loading).

UI validation

Lastly you should confirm in your application's interface that your translation keys are translated from auth.login_form.title to your expected value for the active locale.

Final thoughts

Lazy loading translation assets can be super impactful to application performance. With this change in our authentication experience, we are able to request 3.0kb of translation assets for our locale, instead of 166kb for our entire application's translation asset. As our application continues to scale, our impact of translations stay consistent to the growth; instead of all users being impacted for translation assets for features they are not using.

Lastly, by using Nx buildable libs to manage our separated feature and translation assets; our library is never rebuilt for other translation changes in our application, resulting in lower CI build times and cost savings.

Angular dynamic modules at runtime with Module Federation

Sean Perkins — Thu, 20 May 2021 21:54:34 +0000

Angular 12 recently launched with the added enhancements of Webpack 5 and opening the door to using module federation. If you are looking for a great deep-dive into module federation and micro-frontends, I suggest reading: https://www.angulararchitects.io/aktuelles/the-microfrontend-revolution-module-federation-in-webpack-5/.

Micro frontends

Micro frontends and more importantly module federation, allows developers the flexibility of remotely requesting a module on the network and bootstrapping that module into their application. Similar to lazy-loading, remotely loading modules can greatly reduce the bundle size of your application and the network cost to loading modules that end up unused by your users.

There's other benefits to micro-frontends, including:

A/B serving features
Incremental updates
Independent versioning of features
Dynamic feature resolutions

Getting started

The Angular Architects package @angular-architects/module-federation creates a simple API to request modules and pull them into your application.

Assuming an NX mono-repo set-up:

To add module federation to your workspace, run:



nx add @angular-architects/module-federation@next

This will install the necessary dependency, with the schematics needed to add remote apps to be consumed by module federation.

Let's assume you have the following mono-repo:



apps/
    shell/
    remote/

Shell is your consuming application. It is the highest container, responsible for what pieces are pulled in and the composition of features.

Remote is the feature set, isolated and decoupled to be pulled in on-demand, by the shell.

To make these apps compatible with module federation, you will need to run the schematic on their projects:



nx add @angular-architects/module-federation --project shell --port 5000
nx add @angular-architects/module-federation --project remote --port 6000

You can configure the port to be whatever you desire. This only matters for local development.

This schematic will:

Generate a webpack.config.js and webpack.config.prod.js with a boilerplate for module federation
Update angular.json for the project definition, to reference the extraWebpackConfig and update the project's port to the value specified
Split the bootstrap logic of your app from main.ts to bootstrap.ts and reference the function in main.ts.

Module Federation Plugin

Inside your webpack.config.js you will want to get accommodated with the config for module federation.



module.exports = {
    output: {
        uniqueName: 'remote',
        publicPath: 'auto',
    },
    optimization: {
        runtimeChunk: false,
    },
    resolve: {
        alias: {
            ...sharedMappings.getAliases(),
        },
    },
    plugins: [
        new ModuleFederationPlugin({
            name: 'remote',
            filename: 'remoteEntry.js',
            exposes: {
                './Module':
                    './apps/remote/src/app/app.module.ts',
            },
            shared: {
                '@angular/core': {
                    singleton: true,
                    strictVersion: true,
                    requiredVersion: '>= 12.0.0',
                },
                '@angular/common': {
                    singleton: true,
                    strictVersion: true,
                    requiredVersion: '>= 12.0.0',
                },
                '@angular/common/http': {
                    singleton: true,
                    strictVersion: true,
                    requiredVersion: '>= 12.0.0',
                },
                '@angular/router': {
                    singleton: true,
                    strictVersion: true,
                    requiredVersion: '>= 12.0.0',
                },
                ...sharedMappings.getDescriptors(),
            },
        }),
        sharedMappings.getPlugin(),
    ],
};

name should align with your output.uniqueName and match your shell app's webpack config for the remotes section.
fileName is the name of the generated file's entry point to your remote module. This file name will not be renamed in the build process and is the asset you will be referencing in your shell to request the module.
exposes is the named paths to modules, components, etc. that you want to make accessible to the shell to pull in. I'll explain this further below.
shared the shared dependencies (and rules) between your remote and shell app. This allows tight control for your remote to not re-declare modules/services that you expect to be singleton, or prevent mismatched versions of Angular or other libraries existing in the eco-system. By assigning strictVersion to true, the build will quick fail if an issue occurs. Removing this option will potentially pass the build, but display warnings in the dev console.

You can now locally run your shell and remote with:



nx serve shell -o
nx serve remote -o

-o will automatically launch the apps in your default browser

Exposes (continued)

While the example schematic will generate the exposes section with the AppModule and AppComponent I would strongly advise against this.

When serving the remote and shell to develop locally, the sites will be deployed to:

localhost:5000
localhost:6000

When you make changes to the remote app folder's contents, only localhost:6000 will live-reload.

This means for local development, consuming the remote into the shell app is not sustainable for development against remote-specific functionality.

So what do I propose?

The AppModule of your remote app should be your "demo" or self-deployed landscape. You will import modules and providers to establish a foundation to locally test your remote app in isolation. The AppModule should have a separate module of the cohesive functionality you are wanting to expose, i.e: LoginModule.

With this approach, exposing and pulling in AppModule has the potential to pulling in duplicate root providers; as well as pulling duplicate assets and styles.

Instead with:



exposes: {
    './Module':
        './apps/remote/src/app/login/login.module.ts',
},

./Module is nomenclature you can define as you please. I would recommend being more specific in a diverse system.

The shell app still can access the shared functionality to pull in, but doesn't pull in more than it needs to.

I can locally develop on localhost:6000, having an accurate test bed for my application and live-dev against the changes with ease.

Now that the foundation of module federation have been set, let's jump into dynamically swapping modules at runtime.

Dynamic Runtime modules

All of the top resources available for module federation show statically referencing the modules in your shell app's route definition.



import { loadRemoteModule } from '@angular-architects/module-federation';

[...]

const routes: Routes = [
    [...]
    {
        path: 'flights',
        loadChildren: () =>
            loadRemoteModule({
                remoteEntry: 'http://localhost:3000/remoteEntry.js',
                remoteName: 'mfe1',
                exposedModule: './Module'
            })
            .then(m => m.FlightsModule)
    },
    [...]
];

This serves a purpose when your application wants to independently build and manage known features. This doesn't however allow you conditionally serve features or create an application that does not have context of what features exist at build time.

Dynamic module federation

Dynamic module federation attempts to resolve this by allowing you independently request modules before bootstrapping Angular:



import { loadRemoteEntry } from '@angular-architects/module-federation';

Promise.all([
    loadRemoteEntry('http://localhost:3000/remoteEntry.js', 'mfe1')
])
.catch(err => console.error('Error loading remote entries', err))
.then(() => import('./bootstrap'))
.catch(err => console.error(err));

Better... but still has a few drawbacks:

What if my remote module is routable? Will it recognize the route when I navigate directly to it?
How does this impact lazy loading?
Remote entries are still hard-coded

Dynamic runtime module federation

We need the ability to have a decoupled shell, that can dynamically request federated modules at runtime.

A real use case?

On our team, we want to dynamically serve separate authentication experiences for customers. Some customers use our platform's stock username/password authentication. Others have their own corporate SSO. All of them have strict branding standards that aren't compatible with each other.

We do however, want all customers to share the primary functionality of our platform - content management and learning delivery. Once they login to the application, they only need branding for their corporate logo and primary brand color; they can use all the existing interfaces.

Less rigid example?

Feature toggles in an application. Some customers have "X" others have "Y". You want to serve one app that can respond to "X" and "Y".

Getting started

Authentication deals with routing and we need to allow our users to navigate to /authentication/login and get served the correct federated module for their company.

We will be using an injection token to store our route definitions as they relate to module federation.



export const PLATFORM_ROUTES = new InjectionToken<Routes>('Platform routes for module federation');

If you used the the schematic discussed above, you should have a bootstrap.ts file. Prior to bootstrapping Angular, we need to request the registry of the modules that should exist for this user. This can be any network call, for this demo we will use a local JSON asset called platform-config.json

Platform config is going to describe all the modules, the location of the modules, the module name to bootstrap and the route to register in the shell app for the remote module.



{
    "authentication": {
        "path": "authentication",
        "remoteEntry": "http://localhost:5001/remoteEntry.js",
        "remoteName": "coreAuthentication",
        "exposedModule": "./LoginModule",
        "exposedModuleName": "LoginModule"
    }
}

path is the Angular route namespace to load the remote module under.
remoteEntry is the served location of your remote module. This would be replaced with the served location (CDN, CloudFoundry, S3 asset, etc.) in a built environment. This currently references where we will be serving our Angular apps for local development.
exposedModule is the key in your remote app's webpack.config.js for the exposed module (your nomenclature)
exposedModuleName is the name of the Angular module that was exposed, this is leveraged for lazy loading.

In bootstrap.ts we will consume this asset and build the injection token value:



import { enableProdMode } from '@angular/core';
import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
import { Routes } from '@angular/router';
import { loadRemoteModule } from '@angular-architects/module-federation';

import { AppModule } from './app/app.module';
import { PLATFORM_ROUTES } from './app/platform-routes';
import { environment } from './environments/environment';

if (environment.production) {
    enableProdMode();
}
fetch('/assets/platform-config.json').then(async (res) => {
    const config = await res.json();

    const platformRoutes: Routes = [];
    for (const [key, value] of Object.entries<any>(config)) {
        platformRoutes.push({
            path: value.path,
            loadChildren: () =>
                loadRemoteModule({
                    remoteEntry: value.remoteEntry,
                    remoteName: value.remoteName,
                    exposedModule: value.exposedModule,
                }).then((m) => m[value.exposedModuleName]),
        });
    }

    platformBrowserDynamic([
        {
            provide: PLATFORM_ROUTES,
            useValue: platformRoutes,
            multi: true,
        },
    ])
        .bootstrapModule(AppModule)
        .catch((err) => console.error(err));
});

By passing the providers to platformBrowserDynamic, we are setting a static provider value prior to bootstrap, that can be used on bootstrap.

In the module responsible for your shell app's router module declaration (typically app-routing.module.ts), update as follows:



import { NgModule } from '@angular/core';
import { RouterModule, ROUTES, Routes } from '@angular/router';

import { PLATFORM_ROUTES } from './platform-routes';

@NgModule({
    imports: [
        RouterModule.forRoot(
            [
                /* Declare root routes in the factory below */
            ],
            { initialNavigation: 'enabled' }
        ),
        {
            ngModule: RouterModule,
            providers: [
                {
                    provide: ROUTES,
                    useFactory: (
                        staticRoutes: Routes = [],
                        dynamicRoutes: Routes = []
                    ) => {
                        let rootRoutes: Routes = [];

                        if (Array.isArray(staticRoutes)) {
                            rootRoutes = [...staticRoutes];
                        }
                        if (Array.isArray(dynamicRoutes)) {
                            rootRoutes = [...rootRoutes, ...dynamicRoutes];
                        }
                        rootRoutes.push({
                            path: '**',
                            redirectTo: '/authentication/login',
                        });
                        return rootRoutes;
                    },
                    deps: [ROUTES, PLATFORM_ROUTES],
                },
            ],
        },
    ],
    exports: [RouterModule],
})
export class AppRoutingModule {}

Let's explain a bit...

RouterModule.forRoot([]) establishes a lot of necessary providers and functionality required for routing. Under the hood, all router modules roll-up the route definition to an injection token named ROUTES. We can bootstrap the module and immediately provide a new value on-top for the ROUTES value.

To allow our shell app to have it's own built-in routes as well as the dynamic runtime routes, we use a factory to concat rootRoutes and the dynamicRoutes (from our injection token PLATFORM_ROUTES).

Lastly, we have a fallback route, as routes will execute first-to-last, to handle global redirect behavior for unhandled routes.

Conclusion

At this point, we are rolling. We can now change our config while serving the different remotes and shell and see it swap out the served bundle. In a real environment, the config data would come from an endpoint.

If you read this far I appreciate it. Module federation in Angular is a very new concept and I welcome feedback and questions on this topic!

Automatically Alphabetize Translation JSON Files

Sean Perkins — Sun, 02 Feb 2020 07:36:19 +0000

If you are rapidly developing an application that supports multiple languages, it's safe to assume your translation files are constantly being updated. In a large team this can cause numerous merge conflicts, rebasing and slow-down to delivering features.

Last week, our team wanted a convenient way to keep our translations managed to aid with PR throughput as well as keep our translation files "organized" to quickly browse through available keys. As a result, we built a simple post-commit hook that automatically alphabetizes our translation files and keeps them organized for each PR - without requiring the developer to manually alphabetize the translation file or have to commit a fix as part of a PR checklist.

Implementing this efficiency requires the following project conditions:

Usage of JSON files for translations
Flat translation structure (or update the script to handle nesting)
NPM/Yarn based project
Using Git

Getting Started

You will need to install an npm package called husky that allows you invoke scripts as part of the git process (pre-commit or post-commit).

In a yarn workspace...

yarn add husky -W --save-dev

In an npm project...

npm install husky --save-dev

Translation Script

Create a TypeScript file for the translation script. You can name this file anything and include it anywhere that is within a targeted tsconfig.json. In our example, we use a Yarn NX mono-repo and have our script located in: libs/i18n/scripts/auto-order-translations.ts.

The contents of the script will include:

const fs = require('fs');
const path = require('path');
const english = require('../src/lib/en.json');
const exec = require('child_process').exec;

const orderedEnglish = {};
Object.keys(english).sort(function (a, b) {
    return a.toLowerCase().localeCompare(b.toLowerCase());
}).forEach(key => {
    orderedEnglish[key] = english[key];
});

fs.writeFile(path.resolve(__dirname, '../src/lib/en.json'), JSON.stringify(orderedEnglish, null, '\t'), function (err) {
    if (err) {
        throw err;
    }
    exec('HUSKY_SKIP_HOOKS=1 git add libs/i18n/src/lib/en.json && HUSKY_SKIP_HOOKS=1 git commit --amend --no-edit --allow-empty', function (err) {
        if (err) {
            throw err;
        }
    })
});

Important Pieces

You will need to update the path of ../src/lib/en.json to match the relative location of where your translation file is located. For our team, we only need to maintain the English translation - as a 3rd party will supply us the translated output targets.
git add libs/i18n/src/lib/en.json is the location of the translation file, from the root location of your project. This will be the same starting location as where your package.json is. This piece is crucial, as it amends the developers commit to include the sanitized translation file automatically.
a.toLowerCase().localeCompare(b.toLowerCase()) forces the keys to be in a consistent order, following casing (i.e: item comes before Item).

Misc:

To prevent an infinite loop of Husky detecting a commit hook as we amend the previous commit, we pass the flag HUSKY_SKIP_HOOKS=1 to ignore Husky from executing during the current process of our script.

Post-Commit Hook

With husky installed and our script ready to go, the last piece is executing the script when a developer is about to make a commit.

In your package.json add the following block:


"husky": {
    "hooks": {
        "post-commit": "node libs/i18n/scripts/auto-order-translations.ts"
    }
}

Note: Update the path libs/... to match the location where your script file is located.

To confirm the script is working, have your translation file keys in a random order and commit a new change. If you want to test without manually changing a file, I use this command to push a commit with no changes:

git commit --allow-empty -m "Trigger notification"

If you use GitKraken or another Git Client, you should see messages regarding the post-commit process ignoring Husky after our script executes.

The translation file should be sorted correctly on your local and remote branches.

Before

{
    "Your Team": "Your Team",
    "Name": "Name",
    "Are you sure?": "Are you sure?",
    "Thumbnail": "Thumbnail",
    "People": "People",
    "Clear": "Clear",
    "This group is locked and cannot be deleted.": "This group is locked and cannot be deleted.",
    "Email": "Email"
}

After

{
    "Are you sure?": "Are you sure?",
    "Clear": "Clear",
    "Email": "Email",
    "Name": "Name",
    "People": "People",
    "This group is locked and cannot be deleted.": "This group is locked and cannot be deleted.",
    "Thumbnail": "Thumbnail",
    "Your Team": "Your Team"
}

Using Lottie Animations inside Angular or Ionic 4

Sean Perkins — Sun, 06 Oct 2019 23:03:29 +0000

Getting Started

We will need to install the required web components to render and play the Lottie animation. We will be using the player maintained by our team at TeamHive. This package was ported from the original player to be built and compiled with StencilJS. This allows the player to be used in Webpack environments (i.e. Angular).

Install the web component:



npm install --save @teamhive/lottie-player



import { defineCustomElements } from '@teamhive/lottie-player/loader';

defineCustomElements(window);

Note:

When dealing with web components in an Angular application, you need to apply the correct schema on the module containing the component/page.



schemas: [CUSTOM_ELEMENTS_SCHEMA]

LottieFiles

LottieFiles is a website of both free and premium lottie animations that you can easily adapt and use in your application or website.

LottieFiles Website

Find an animation that you like, select it and click the "html" output to find the JSON path. This path will be used in your application.

Note:

If you are using your application offline, you will need to download the JSON and reference it locally from your application.

Integrating Into Your App

Let's add a button to our view and embed the lottie-player component with our JSON we've selected from the previous step.



<ion-button fill="outline" expand="block">
    Example
    <lottie-player slot="end" autoplay loop src="https://assets3.lottiefiles.com/packages/lf20_ZWEJL5.json">
    </lottie-player>
</ion-button>

If we run this example we should see this:

At this point you are up and running with an embedded lottie animation in your application.

Additional Styling

If in this example you want to style the animation at the end of the ion-button, you can apply this mark-up.



lottie-player {
    position: absolute;
    transform: translateX(40%) scale(0.75);
}

You can adjust the transform based on your animation's size and width of the button control. I would also recommend using a class or id selector for the styling.

Using i18n Translations within Stencil Components

Sean Perkins — Fri, 27 Sep 2019 23:47:58 +0000

Introduction

Supporting multiple languages is a common requirement for developing websites and applications. Using Stencil we are able to build extendable web components in a design system to expedite application development.

Unfortunately, any components composed of translatable text often times are forgotten or worse; additional mark-up is added to a web component to allow for it to accept a translated label.

Example of ineffective solution:

@Prop() ofLabel: string;


render() {
   return (
       <span>5 {this.ofLabel} 10 Results</span>
   );
}

Cons

Anywhere that I use this component, I will need to be aware of the translation property as well as remember to pass it in.

The Solution

If you are supporting translations in your application, you most likely already have a managed translation file for your application. We can reuse this file to manage our translations from a single point of truth!

In this example we are using an NX mono-repository from the app starter template. You can easily adapt the configurations to meet your project's needs.

Include Locales into Bundle

We have the following structure in our project:

libs/
    i18n/
        en.json
    ui/
        stencil.config.js
        src/

Update your stencil.config.ts file to copy the assets from the i18n library to include in your bundle.

copy: [
    {
        src: '../../i18n/src/lib/*.json',
        dest: 'i18n'
    }
],

Copy Locales to Public Location

We are using Angular for our enterprise stack. In order for our stencil component to have a reliable location to parse translations from, we need to expose the assets as a public resource.

Update your angular.json for your project to include the following copy job for the assets config:

"assets": [{
     "glob": "**/*.json",
     "input": "libs/ui/dist/collection/i18n",
     "output": "i18n"
}]

Translation Utils

We will be parsing translations a lot for each individual component that is rendered. To prevent writing duplicate code as well as optimistically cache the translation data, we will be creating a translation utility class to help.

In libs/ui/src/utils create a new file translation.ts.

export namespace TranslationUtils {

    /**
     * Attempts to find the closest tag with a lang attribute.
     * Falls back to english if no language is found.
     * @param element The element to find a lang attribute for.
     */
    function getLocale(element: HTMLElement = document.body) {
        const closestElement = element.closest('[lang]') as HTMLElement;
        return closestElement ? closestElement.lang : 'en';
    }

    export async function fetchTranslations() {
        const locale = getLocale();
        const existingTranslations = JSON.parse(sessionStorage.getItem(`i18n.${locale}`));
        if (existingTranslations && Object.keys(existingTranslations).length > 0) {
            return existingTranslations;
        } else {
            try {
                const result = await fetch(`/i18n/${locale}.json`);
                if (result.ok) {
                    const data = await result.json();
                    sessionStorage.setItem(`i18n.${locale}`, JSON.stringify(data));
                    return data;
                }
            } catch (exception) {
                console.error(`Error loading locale: ${locale}`, exception);
            }
        }
    }

}

This utility focuses on solving three unique challenges.

The getLocale function will evaluate the DOM to find a lang attribute to determine the active locale. If it cannot find a lang attribute, it will fall back to English.
The fetchTranslations function optimistically fetches and writes to session storage to prevent multiple requests to the translation file. It caches per locale, to allow for changing between languages easily.
The fetchTranslations function returns the contents of the locale file (i.e en.json) as a JavaScript object.

Component Implementation

In your existing web component, declare a state variable for the translations object.

@State() translations: any;

In the life cycle hook for loading the component, utilize the translation utility to fetch the translations.

async componentWillLoad() {
    this.translations = await TranslationUtils.fetchTranslations();
}

Now you will have the full collection of translations that are shared with your application. You can easily use any translation key as a JavaScript object.

render() {
    return (
         <span>5 {this.translations.of} 10</span>
    );
}

Advantages

As you manage translation file for your application, the component will always remain in sync. You can also allow the application to easily change the translations without having to maintain separate versions of a web component.

Future Proofing

To take this implementation a step further, you can easily use a MutationObserver on the element with the closest lang attribute, to handle when a browser changes translations.

Translucent Tabs in Ionic 4

Sean Perkins — Tue, 24 Sep 2019 07:06:13 +0000

What are Translucent Tabs?

Translucent tabs are a visual enhancement to native tab layouts that allow the contents of the view to bleed through the tab bar with a blurred effect. It's best utilized when your application has rich visuals and colors that can be visually depicted through the tab bar.

Ionic Core Support

If you're curious why Ionic doesn't support this out of the box, the answer is that they kind-of do. The translucent flag on the tab bar does update the styling of the tab bar to be semi-transparent. Unfortunately the way the tabs were architected, makes the tab-bar a sibling to the contents; which prevents the contents from naturally scrolling underneath the tab bar.

Here's a few open issues to track when Ionic will officially support translucent tabs:

Work-around

Let's get started with a workaround to add the translucent effect to your application. Be aware that this method requires a little extra styling configuration to your pages where you are using bottom fixed positioning (i.e. ion-fab).

Translucent Effect

Add the translucent property binding on the ion-tab-bar to be true to enable the styling presets set by the Ionic Core team.

<ion-tabs>
    <ion-tab-bar [translucent]="true" slot="bottom">
       <!--- Your Tabs --->
    </ion-tab-bar>
</ion-tabs>

This will allow the color of the content to pass through the tab bar. Unfortunately the contents will not scroll under the tabs, so next let's adjust the positioning of the tab bar.

Absolute Positioning

In the component that is containing the ion-tabs component, apply the following style.

ion-tab-bar {
    // Translucent positioning effect
    position: absolute;
    bottom: 0;
    left: 0;
    width: 100%;
}

This will make the tab-bar "pop out" of the view and always rest at the bottom of the app's container. Great! Now the contents will display under the tab bar with a translucent effect. The next problem you will face is that since you have removed the tab-bar from the viewport sizing, the bottom of your contents will always be hidden under the tab bar and preventing the user from interacting with them.

Offsetting Content Container

Now I guarantee there is a better way of handling this manipulation, but I needed a quick way to pierce the lazy-loaded router-outlets and modify the contents of the page without manually applying a class to every page or applying the same styling overrides to each page.

In your component containing the ion-tabs, implement the AfterViewInit life cycle hook and apply the following mark-up.

@ViewChild(IonTabs, { static: true }) ionTabs: IonTabs;

ngAfterViewInit() {
    this.overrideTabContainer();
}

private overrideTabContainer() {
    setTimeout(() => {
        const routerOutlet = (this.ionTabs.outlet as any).nativeEl as HTMLElement;
        const container = routerOutlet.querySelector('ion-content');
        if (container) {
             container.style.setProperty('--padding-bottom', '90px');
        }
    });
}

This code will find the ion-content inside the lazy-loaded tab and override the padded bottom to a size that is greater than the tab bars height. You could manually pull the clientHeight of the tab bar here instead of supplying a static value.

Gotcha's

Since the ion-tab-bar is now resting at the bottom of the view, commonly position fixed elements will display on the tab bar and/or under the tab bar. An instance of this will be with the ion-fab and ion-footer. To get around this, you will need to create a global style that applies the same offset that we use for the padding-bottom, to the positioning of the elements.

i.e:

// Used for the translucent tabs
ion-fab, ion-footer {
    bottom: 90px;
}

The Result

Pin-wheel Desk Layout in a Development Team

Sean Perkins — Tue, 03 Sep 2019 23:11:23 +0000

Back Story

Our team embraces a highly collaborative work environment with an open office layout. No employee has their own personal office, instead we have ample meeting space for client, personal or private meeting needs.

Each team is comprised of anywhere from 8-20 people, with approximately 5 distinct teams operating throughout the company. As team size began to grow over the years, we experienced issues with continuous collaboration as well as appropriately using physical space to its maximum potential. When new team members were hired, they were placed at the ends of a row and tables began to wrap around the office. Additionally, power cords and surge protectors were daisy-chained together to allow for all the necessary AC power - not good!

This photo is of a simple 6 person configuration. Imagine this repeated 4x in a row.

Initial Research

We researched a variety of solutions that could solve our challenges with space:

Radically change the traditional desk arrangement
Rent additional office space (lease the space underneath our current workspace)
Minimize individual desk-space to accomodate more people in a tighter space
Reduce open collaboration spaces and begin to occupy them with new desks

Each solution seemed to have more drawbacks than the previous. Why did we need to sacrifice the work environment to accommodate more people? Or rather, why did we need to increase our expenses to add a few additional employees? Or team isn’t at a size that warrants that much office space currently.

Our team re-grouped and prioritized what mattered to us in our working space.

Collaboration
We are a group of engineers and designers, working together and having continuous communication is vital. Tools like Slack work great as a crutch in work environments, but cannot replace the synergy of working in-person through challenges.

Privacy
There are times you just need to put your head down and work. Noise, foot traffic, etc. can all impact how focused you are in your work. Our team valued the ability to plug-in to their niche and quickly come together to collaborate.

Team Radius
As teams grow, distinct functions of that team begin to form. We originally were a team of full-stack engineers and realized that dedicated front-end/back-end teams was more profitable and produced more throughput. When that team grows, it’s valuable to keep those working together the most, to be within conversational reach. We valued having our operating team as close as we can without having to use meeting space.

Feels Homie
With spending so much time in an office, it starts to become an extension of yourself. You want an environment that is both comfortable and safe. We wanted an environment where you aren’t facing a wall, instead you are looking at your peers. We also valued our open office layout and did not want additional walls/silos in our team.

Our Approach

After a depth of research into different desk configurations that could meet each of these goals, we eventually settled on a variation of the pin-wheel desk configuration. Due to space constraints, we couldn’t accomplish a full spread pin-wheel desk configuration in 15’ wide and 46’ long hallway. Before moving any desks, we planned out our attack (as engineers do!).

We aligned team members that needed to collaborate the most and created spaces that accomplished both privacy, homie (natural light/window views) and placed teams within a convenient radius.

The Results

We made this change on July 10th. Since then we have had an increase in collaboration, productivity and improved cross-team communication. Team members have been able to improve their relationships with team members they did not have social collaboration with in the past. We have also increased the maximum physical capacity by 4 desk set-ups.

The team has a whole as unanimously agreed this desk configuration is an improvement over the traditional line arrangement.

What's Next?

Cable management is our next priority to improve the organization and safety of our working space.

Using Algolia With Firebase Angular Apps

Sean Perkins — Fri, 30 Aug 2019 00:24:13 +0000

What is Algolia?

Algolia is a super powerful, scalable API service that allows developers to send different forms of data into their platform and quickly perform search, sort and complex filter queries on top of it. The service is incredibly fast, by using replica indexes to pre-build common query conditions to send your data back as quick as possible.

Why use Algolia with Firebase?

Firebase has come a long way in terms of its accessibility with querying data structures, especially in Firestore. Even with these advancements, it has limitations and often time requires pre-sorted data, using Firebase’s syntax sugar with push ids (push ids contain a date hash in their generation) and sacrificing extra reads/writes and straight forward object structure. Firebase also officially recommends Algolia for performing full-text search operations in Firestore.

Getting Started

In this working example, we will be using Firebase Cloud Functions with triggers to help assist with syncing data changes from Firestore over to Algolia. We will also be using the Algolia Node.JS and JavaScript client module for interacting with their service.

Firebase Cloud Functions

In your functions directory you will need to install the following dependencies to leverage Algolia.

npm install --save algoliasearch @types/algoliasearch

For this example we will listen for whenever a new user document is created, updated or deleted in our custom Firestore collection “users”.

For each of the below examples you will need to replace appId and apiKey with your own access tokens generated through Algolia’s admin panel.

user.onCreate.ts

The userOnCreate trigger is dispatched every time a new document is created in the users collection. In the example below we initialize Algolia with our app’s id and unique API key and initialize the index we want to use in Algolia. Algolia recommends naming your index by the instance/environment you are working with (i.e. dev_, prod_, staging_, next_).

We are also replicating to indexes so that we can sort by the user’s name in either ascending or descending order. Algolia reserves objectID for correlating records in their world; we will use the new document’s path id.

import * as algoliasearch from 'algoliasearch';
import * as functions from 'firebase-functions';

export const userOnCreate = functions.firestore
   .document('users/{id}')
   .onCreate(async (change, context) => {
       const user = change.data();
       const client = algoliasearch('appId', 'apiKey');
       const index = client.initIndex('dev_users');
       await index.setSettings({
           replicas: [
               'dev_users_name_desc',
               'dev_users_name_asc'
           ]
       });
       return index.addObject({
           objectID: change.id,
           ...user
       });
   });

user.onUpdate.ts

The userOnUpdate trigger is very similar to the create trigger. The difference is that we do not need to re-specify the replica indexes since once we register them; they will automatically push data over to the replica indexes any time we write to the parent index (dev_users).

To reduce the operation cost, Algolia allows partial updates to only change specific properties on an index’s object.

import * as algoliasearch from 'algoliasearch';
import * as functions from 'firebase-functions';

export const userOnUpdate = functions.firestore
   .document('users/{id}')
   .onCreate(async (change, context) => {
       const user = change.data();
       const client = algoliasearch('appId', 'apiKey');
       const index = client.initIndex('dev_users');
       return index.partialUpdateObject({
           objectID: change.id,
           ...user
       });
   });

user.onDelete.ts

The userOnDelete trigger is the simplest operation with an initialize and delete object call to remove the Algolia object by the objectID we defined earlier.

import * as algoliasearch from 'algoliasearch';
import * as functions from 'firebase-functions';

export const userOnDelete = functions.firestore
   .document('users/{id}')
   .onCreate(async (change, context) => {
       const client = algoliasearch('appId', 'apiKey');
       const index = client.initIndex('dev_users');
       return index.deleteObject(change.id);
   });

Export all of these constants to your root index.ts file. This will register them as new Firebase Cloud Functions when you build and deploy. At this point any time you change documents in Firestore (either directly through the Firebase Console or with your app) it will trigger these functions to push and sync data across to Algolia.

firebase deploy --only functions:userOnCreate,functions:userOnUpdate,functions:userOnDelete

Application Side

You can store Algolia’s search-only access token (this is different than the apiKey used in Cloud Functions) in your environments file to easily access/import it.

Create a simple service to easily interact with your Algolia indexes.

user.service.ts

import * as algoliasearch from 'algoliasearch';

@Injectable()
export class UserService {

   client: algoliasearch.Client;

   init(config: {
       appId: string,
       apiKey: string
   }) {
       this.client = algoliasearch('appId', 'apiKey');
   }

   fetchUsers(options: algoliasearch.QueryParameters) {
       const userSearch = this.client.initIndex('dev_users');
       return userSearch.search(options);
   }

   fetchUsersByNameAsc(options: algoliasearch.QueryParameters) {
       const userSearch = this.client.initIndex('dev_users_name_asc');
       return userSearch.search(options);
   }

   fetchUsersByNameDesc(options: algoliasearch.QueryParameters) {
       const userSearch = this.client.initIndex('dev_users_name_desc');
       return userSearch.search(options);
   }

}

In your component, provide UserService and make the following method calls to test the response back from Algolia.

async ngOnInit() {
    this.init({ appId: 'foo', apiKey: 'bar' });
    const res = await this.fetchUsers({
        page: 0,
        length: 10,
        query: 'Sean'
    });
    console.log('res', res);
}

This method call will attempt to load the first page of results, up to 10 records that has a searchable attribute that matches “Sean”.

Final Thoughts

Without getting too far into the weeds of Algolia’s client and explicitly focusing on syncing data over and quickly logging that information out; we can see that Algolia serves as a powerful interface to receive the exact data we need.

In our implementation on Hive, we use Algolia to handle paginated admin tables, infinite scroll experiences, pre-filtering collection records by specific conditions and sorting table data. You can also leverage Algolia as a read-only database, only storing/syncing documents that the client should have access to. This is powerful when using concepts such as soft deletes, where you stamp a document with a deletedAt timestamp in Firestore and remove the object from Algolia. By doing this, you can always recover the document back, but all querying logic from Algolia will treat the document as being deleted.