DEV Community: TeamHive

Triggering GitHub Actions Using Repository Dispatches

Josh Gibson — Sun, 15 Mar 2020 20:30:04 +0000

TL;DR: Using HTTP requests, you can send repository dispatches to trigger GitHub Actions workflows

GitHub Actions is a quickly growing and quickly developing CI/CD platform that is free to all GitHub users. While the platform is still relatively young, features are being released constantly by the Actions team and the community of developers utilizing the platform and developing open source actions for it continues to expand.

One feature that has been at the front of many current and potential users minds is the flexibility of triggering actions. Unsurprisingly, triggering actions based on commits, releases, and branches is simple to configure. GitHub has also made it easy to schedule tasks using cron notation. What becomes less obvious, though, is how users could either manually trigger an action or have a third party service trigger an action. Other platforms like Jenkins make this simple with the ability to build jobs from the click of a button in their web console, or by installing plugins that enable remote services to act as triggers.

While GitHub actions does not yet have a similar feature in their web console, this functionality does exist in the form of repository dispatches. A repository dispatch is essentially just an HTTP request to your repository asking GitHub to kick off any action or webhook. Using this feature, you can both manually trigger GitHub actions using repository dispatches, or you can set up an application to trigger the action by sending a request.

Setting up your action

In your workflow yml file, you need to add a trigger for the on key that says that the workflow will accept repository dispatches.

The simplest configuration is to have the workflow trigger on any repository dispatch:



on:
    repository_dispatch:

If you have multiple workflows that might be triggered by separate dispatches, however, you can specify specific event types that will trigger the workflow.



on:
    repository_dispatch:
        types: [start-example-workflow]

In the above example, only dispatches with the event type "start-example-workflow" will trigger the workflow.

Custom Parameters

Throughout your action, you can also use information provided by the "client-payload" of the dispatch. Using the expression



${{ github.event.client_payload.example-key }}

will give you access to all of the data provided in the client payload. This will allow you to use the data as environment variables for bash commands or as inputs to other actions.

Constructing the request

The payload of a repository dispatch is quite simple:



{
    "event_type": "my_event_type",
    "client_payload": {
        "example-key": "example-value"
    }
}

This request also needs the following set of headers:



Accept:  application/vnd.github.everest-preview+json
Content-Type: application/json
Authorization: Bearer {{personal_access_token}}

At this point, I should clarify that in order to trigger the workflow, the request must be authenticated with a personal access token for a user that is authorized to access the repository.

To create an access token, follow these steps from GitHub and be sure that you have given the token access to the repo scope.

With that payload, you can POST the request to https://api.github.com/repos/:owner/:repo/dispatches to trigger workflows that are set up to accept the dispatch.

Using Postman

If your goal is to simply trigger these workflows with a push of a button, Postman might be one of the easiest ways to set up these POST requests and send them GitHub.

The first step is to create a new environment in Postman to store your personal access token. To do this, click the gear in the upper right hand corner to manage environments and create a new environment called GitHub.

From there, you should add a new environment with your personal access token as the variable token.

Once this environment is set up, you can now create a new collection of requests that will trigger your GitHub Actions workflows. To use the token that is a part of your environment, make sure your environment is selected in the upper right hand corner of your application, and then add the token to the Bearer Authorization of your request.

Next set the appropriate headers.

You can now set the appropriate payload for your dispatch and send the request. If everything is appropriately set up, you should get a 204 No Content Response.

Finally, you can save the request and send the dispatch whenever you want to manually trigger the workflow.

What's next?

Given that these triggers are simple HTTP Requests, you can obviously take advantage of this feature to integrate your actions with third party services. In the next article, we'll investigate strategies to trigger actions with integrations from services such as Slack and Sanity.io, a configurable CMS.

Creating a Transaction Interceptor Using Nest.js

Josh Gibson — Mon, 10 Feb 2020 15:22:13 +0000

TL;DR - Nest.js interceptors allow you to create transactions, attach them to each request, and use those in your controllers. See the final implementation here.

Nest.js is one of the fastest growing backend libraries in the Node.js world. Its clear structure, adjacency to Angular, and its similarities to Spring have all led to the framework to bloom in adoption. Additionally, abstracting away repetitive behavior that might have been tedious or verbose in an express app is a breeze with Nest. Between the built-in decorators, pipes, and the ability to extend all of this behavior, serious abstraction is highly encouraged by the framework. If you haven't used Nest.js, we at TeamHive, highly recommend it. Streamlining API development has never been easier than with Nest and it has simplified our development rapidly.

One such repetitive behavior is the process of setting up and appropriately tearing down transactions. If you use a transactional database with your Nest app, one of the greatest benefits is that you can ensure data integrity. If you wrap your requests in a transaction, and the request fails at any point, you can always rollback the transaction and all modifications made up to that point will be reverted. This process, however, is quite tedious. At the start of each request, you must create a transaction, run all of your queries within that transaction, determine if the request succeeded, and then either commit the transaction or it rollback on a failure. While none of these steps are particularly difficult to implement, wrapping every request in appropriate try/catch blocks that can handle the closing of the transaction would result in duplicated code all over the application.

The simplest way to implement this feature would instead be using Nest.js Interceptors. If you come from the express world, you will be familiar with the idea of middleware. A middleware is essentially a function that receives a request and returns a response based on that request. The power of middleware, however, comes from the fact that they can be chained together. In this way, for example, one middleware function can authorize the request, another one can transform it, and a final middleware could fetch some data and respond to the request. The problem with middleware, however, is that they only exist at one point in the middleware chain. There is no simple way to have a function that can both set up some data before the request is handled and also run some logic after the request. An interceptor, on the other hand allows for just this. By using RxJs Observables, Interceptors allow you to inject logic into any point of the request life cycle. For a transaction interceptor, this is perfect because we need to both set up the transaction before the request is handled, and either commit it or roll it back depending on the success of the request.

Implementation

To create an interceptor, all you have to do is create a class that implements the NestInterceptor interface, meaning it has a function called intercept which will receive an ExecutionContext and a CallHandler and will return an Observable. Below is an interceptor in its simplest form.

import { CallHandler, ExecutionContext, Injectable, NestInterceptor } from '@nestjs/common';
import { Observable } from 'rxjs';

@Injectable()
export class TransactionInterceptor implements NestInterceptor {

    async intercept(
        context: ExecutionContext,
        next: CallHandler
    ): Promise<Observable<any>> {
        return next.handle();
    }
}

The first step to creating the interceptor is going to be creating the transaction. Depending on what database, adaptor, or ORM you use, this part will vary, however, the concept should be the same. In this example, we are going to be using Sequelize as an ORM to create the transaction. With Sequelize, all you need to create a transaction is an established Sequelize instance with a database connection. Nest.js makes this simple as we can simply inject our Sequelize instance into the interceptor. If you are using an ORM that requires a Singleton, creating that as Singleton attached to a provider makes it easy to access throughout the Nest application.

Once that Sequelize instance is available in the intercept function, you can simply create the transaction and attach it to the request using the ExecutionContext.

@Injectable()
export class TransactionInterceptor implements NestInterceptor {

    constructor(
        @InjectConnection()
        private readonly sequelizeInstance: Sequelize
    ) { }

    async intercept(
        context: ExecutionContext,
        next: CallHandler
    ): Promise<Observable<any>> {
        const httpContext = context.switchToHttp();
        const req = httpContext.getRequest();

        const transaction: Transaction = await this.sequelizeInstance.transaction();
        req.transaction = transaction;
        return next.handle();
    }
}

At this point the transaction is available on the request, so any controller function could access it using the @Req parameter decorator; however, this is not only verbose, but is not typed by default and leads to the duplicated code of getting the transaction from the request. Instead, using Nest's createParamDecorator function, we can easily create a decorator that will get this transaction for us.

import { createParamDecorator } from '@nestjs/common';

export const TransactionParam: () => ParameterDecorator = () => {
    return createParamDecorator((_data, req) => {
        return req.transaction;
    });
};

With this decorator, any parameter you decorator in a controller function that is being intercepted by the TransactionInterceptor will receive a transaction that will be created per request.


@Get()
@UseInterceptors(TransactionInterceptor)
async handleGetRequest(
    @TransactionParam() transaction: Transaction
) {
    // make queries using your transaction here.
}

Stopping here, though, will not be any help. The transaction is getting created, but there is no logic to either commit the transaction upon success, or roll it back on errors. To do this, we can tap into the Observable returned from the handle() function. In the code below the function passed into tap() will be run when the request is handled successfully. The function passed into catchError will run when an error is thrown by the request handler.

Final Implementation

@Injectable()
export class TransactionInterceptor implements NestInterceptor {

    constructor(
        @InjectConnection()
        private readonly sequelizeInstance: Sequelize
    ) { }

    async intercept(
        context: ExecutionContext,
        next: CallHandler
    ): Promise<Observable<any>> {
        const httpContext = context.switchToHttp();
        const req = httpContext.getRequest();

        const transaction: Transaction = await this.sequelizeInstance.transaction();
        req.transaction = transaction;
        return next.handle().pipe(
            tap(() => {
                transaction.commit();
            }),
            catchError(err => {
                transaction.rollback();
                return throwError(err);
            })
        );
    }
}

With this code, any error thrown in the controller will cause the transaction to roll back and data will return to its original state. Additionally, errors are still thrown up the stack so all existing error handling/logging will continue to work.

Why use a transaction interceptor?

To start, the benefits of using transactions should be pretty clear. While we like to pretend our code doesn't fail, it inevitably will in production. If your requests make multiple writes or creates multiple objects that are related, it's important that if this process fails or is interrupted, data can be returned to a valid state. Transactions are the easiest way to ensure that and are one of the largest benefits of relational databases.

As mentioned earlier, the interceptor's main benefit is to make using transactions easier while not duplicating code. Once using the interceptor, all the logic of creating and managing the transaction is abstracted. As a developer, your only responsibility is to run your queries under that existing transaction. In this way, the repetitive and uninteresting work of creating and tearing down the transaction is removed, making developers much more likely to take advantage of the transactions that their database makes available to them.

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

Passing an Object or Array to Stencil through markup

Scott M Gerstl — Thu, 19 Sep 2019 16:40:22 +0000

Common Code

export interface SomeValue {
  name: string;
  value: string;
}

Passing an Object

import { Component, h, Prop, Watch } from '@stencil/core';
import { SomeValue } from './some-value.interface';
@Component({
  tag: 'object-sample',
  styleUrl: '...',
  shadow: true
})
export class ObjectSample {
  private _objectData: SomeValue;
  @Prop() objectData: SomeValue | string;

  @Watch('objectData')
  objectDataWatcher(newValue: SomeValue | string) {
    if (typeof newValue === 'string') {
      this._objectData = JSON.parse(newValue);
    }
    else {
      this._objectData = newValue;
    }
  }

  componentWillLoad() {
    this.objectDataWatcher(this.objectData);
  }

  render() {
    return (
      <div class='object-data'>
        <span>{this._objectData.name}</span>
        <span>{this._objectData.value}</span>
      </div>
    );
  }
}

<object-sample 
   object-data='{"name": "Bird", "value": "Chirp"}'>
</object-sample>

Passing an Array

import { Component, h, Prop, Watch } from '@stencil/core';
import { SomeValue } from './some-value.interface';
@Component({
  tag: 'array-sample',
  styleUrl: '...',
  shadow: true
})
export class ArraySample {

  private _arrayData: SomeValue[];
  @Prop() arrayData: SomeValue[] | string;

  @Watch('arrayData')
  arrayDataWatcher(newValue: SomeValue[] | string) {
    if (typeof newValue === 'string') {
       this._arrayData = JSON.parse(newValue);
    }
    else {
      this._arrayData = newValue;
    }
  }

  componentWillLoad() {
    this.arrayDataWatcher(this.arrayData);
  }

  render() {
    return [
      <div class='array-size'>{ this._arrayData.length }</div>,
      this._arrayData.map(x =>
        <div class='row'>
          <span>{x.name}</span>
          <span>{x.value}</span>
        </div>
      )
    ];
  }
}

<array-sample 
   array-data='[{"name": "Cat", "value": "Meow"}, {"name": "Dog", "value": "Woof"}]'>
</array-sample>

Key Concepts

The @Prop() datatype must contain string if a type is defined
Use a @Watch() function to parse the json string value
Call the @Watch() function in the componentWillLoad() function for the first parse of the json data
- The @Watch() function does not fire on the first load of the component
The value passed to the @Prop() must follow strict json syntax

Version Consideration

These examples are Stencil One. If you are using pre @stencil/core@one Check out the Breaking changes document to see what updates are needed to get this sample to work for you in the beta

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.

DEV Community: TeamHive

Triggering GitHub Actions Using Repository Dispatches

Setting up your action

Custom Parameters

Constructing the request

Using Postman

What's next?

Creating a Transaction Interceptor Using Nest.js

Implementation

Final Implementation

Why use a transaction interceptor?

Automatically Alphabetize Translation JSON Files

Getting Started

Translation Script

Important Pieces

Post-Commit Hook

Before

After

Using Lottie Animations inside Angular or Ionic 4

Getting Started

LottieFiles

Integrating Into Your App

Additional Styling

Using i18n Translations within Stencil Components

Introduction

Cons

The Solution

Include Locales into Bundle

Copy Locales to Public Location

Translation Utils

Component Implementation

Advantages

Future Proofing

Translucent Tabs in Ionic 4

What are Translucent Tabs?

Ionic Core Support

Work-around

Translucent Effect

Absolute Positioning

Offsetting Content Container

Gotcha's

The Result

Passing an Object or Array to Stencil through markup

Common Code

Passing an Object

Passing an Array

Key Concepts

Version Consideration

Pin-wheel Desk Layout in a Development Team

Back Story

Initial Research

Our Approach

The Results

What's Next?

Using Algolia With Firebase Angular Apps

What is Algolia?

Why use Algolia with Firebase?

Getting Started

Firebase Cloud Functions

Application Side

Final Thoughts

Additional Resources