DEV Community: Livio Brunner

Screenbean - Pimp your screenshots 💅

Livio Brunner — Wed, 15 Jun 2022 13:46:42 +0000

✨ScreenBean✨ is a tool to add colorful backgrounds to screenshots. This idea came to me when browsing Dribbble. I've realized a lot of promo pictures have the same pattern:

Rounded corners of the product
Drop shadow around the product
Background using the primary, accent or other complementary colors
Sometimes additional complementary shapes in the background

Here is an example of the current Dribbble startpage and you can see what I mean.

💡 Motivation

I often have to pitch new websites or pages to colleagues at work. Since I wanna leave a good impression, I wanna spice up my screenshots to make them stand out more. Though whenever I tried to promote my website it never looked as good as the ones on Dribbble. Probably because I am not a designer -- but I have recognized that adding things like rounded corners make a huge difference.

After a while I wanted to automate this process. So on a boring Friday evening I wrote ScreenBean just for the fun of it.

📝 Technical Decisions

First and foremost I wanted to keep the app alive and "don't worry about it ever again". I don't have any interest in generating revenue with ScreenBean -- but I also don't wanna loose money. So I tried to implement everything client-side. For sure it would be the better technical decision to use a Serverless function to, for instance, generate the images. Though in my context I just didn't want to spend a dime.

👨‍💻 Tech Stack

At the heart of ScreenBeans implementation are two libraries from NPM:

html-to-image: Generate images from DOM elements client-side
node-vibrant: Extract prominent colors from an image

So with these two libraries all I had to do was essentially creating the images using normal HTML/CSS dynamically. Then I can just generate the *.png graphic using html-to-image. Thanks to node-vibrant I can take prominent colors of the image so it usually looks complementary.

I have used React to help me with building the different preview images, the upload mechanism and saving the images.

Since the application is client-side only I could just use free-tier of Netlify for my deployment.

I am a huge fan of TypeScript, though for this project I have decided not to use it. Since I don't need to handle a lot of data throughout the application there did not seem to be a huge benefit of using it.

Demo | Github

Why we chose WebComponents for our Design System

Livio Brunner — Thu, 05 May 2022 19:07:16 +0000

I have worked on a UI library for an internal Design System at a large-scale company (10'000+ employees). I want to walk through my thought process why I have been advocating for Web Components.

Context

I was asked to help creating an Angular-based UI Kit which contains our commonly used components such as inputs, buttons and so on.
Early on I questioned this decision. The rational behind it was that most product teams were using Angular.

Though as I later found out, that was not necessarily true. In Switzerland, where I am located, it's true that most teams were using Angular (probably because it felt more natural to C# developers which was the dominating backend language). Though the more I was trying to do "market research" (=reaching out to teams within the company) I have realized that in e.g. Spain, Poland and the US React was clearly dominant. Whereas in Asian countries Vue was the goto frontend framework. We also worked with external companies which sometimes used completely different frameworks. I came to realisation that basically every framework you can imagine was still in use -- from Backbone.js to Svelte.

So for me creating a UI library with Angular wouldn't cut the vision I had; I want one UI Kit which can be consumed within the company. No matter if or what framework you use.

What the heck are Web Components?

For a long time I honestly did not understand what "Web Components" are. To this day I still believe "Web Components" is just a marketing term or "Syntax Sugar"
for different sets to HTML specifications.

Let me break the specifications down for you:


Custom Elements	The Custom Elements specification lays the foundation for designing and using new types of DOM elements.
Shadow DOM	The shadow DOM specification defines how to use encapsulated style and markup in web components.
ES Modules	The ES Modules specification defines the inclusion and reuse of JS documents in a standards based, modular, performant way.
HTML Template	The HTML template element specification defines how to declare fragments of markup that go unused at page load, but can be instantiated later on at runtime.

The table above was taken from webcomponents.org

So in a nutshell Web Components is a term to bundle up all of those specifications.

Why Web Components

Now that we understand what Web Components are I want to dissect how that can serve us given the context I was in.

Shadow DOM and Custom Properties

Shadow DOM essentially encapsulates CSS and HTML. The reason why this is really useful is because you have more control what is considered public and private API of a component.

To explain it further, let's have a look at how probably most folks used UI libraries like Bootstrap back in the good ol' days.

Usually you'd copy/paste a HTML block and sometimes also import some JavaScript whenever you want to use a component. Often times you'd also customize the HTML with additional CSS code to make it look more according to your branding.

Now imagine Bootstrap would introduce some changes in its CSS of a component. Since anyone has full access to overwrite any CSS of a Bootstrap component, ugprading to the latest Bootstrap version may lead to some nasty side-effects. There is no control from Bootstraps side how the components will be used and modified.

For a library like Bootstrap this may not be a big deal, though with a Design Systems UI library you want to consolidate the components as much as possible and only allow certain things to change.

Now with Shadow DOM and the Custom Properties specifications you can fully encapsulate the HTML and CSS of a component, but still allow customization to be made via Custom CSS Properties. So this means your components API is much more explicit and not everything is just public.

This gives much more sanity to library authors of UI Kits and also allows to use SemVer in a much more sane manner since you know exactly when a components API is considered broken (e.g. removing a custom property). This makes an upgrade of your library much more predictable (given they did not pierce through the Shadow DOM).

Framework Agnosticity

One of our biggest struggles was serving teams with very varying tech stacks. Whilst it is a very feasible and good option to just use vanilla HTML, CSS and JS without Web Components for your UI Kit, I believe the developer experience will suffer. On top of that you won't be able to prevent using private component APIs as mentioned above or.

Generally speaking, Web Components are quite well supported for most frameworks.

There is one big caveat though; React v18 does not support handling rich data or handling events of Web Components.

Source: custom-elements-everywhere.com

With React v19 this should be resolved, but this is at the time of this writing not stable for
production use.

So apart from React you should be able to use Web Components (including Preact) -- though I'll go into more details later in this article how you can workaround that limitation as well as support JSX as first-class citizen.

Downsides of Web Components and how to workaround it

Writing a Web Component with Vanilla JS-only is cumbersome. A lot of code needs to be added in order to do the simplest things which you'd normally expect in frameworks like Vue, Angular or React.

It is in a developers nature to simply reduce redundant code and abstract low-level interfaces. Unfortunately, this will most likely lead in a sort-of Frankenstein-framework which most probably is not even half as good as other already existing frameworks and might not even be documented. Therefore I came to the conclusion; Web Components do not replace your frontend framework

Fortunately, there are some amazing libraries and frameworks already out there. For instance:

These frameworks off course have some major differences in philosophies, implementation and style. For us, the one we chose is Stencil.

Stencil

Stencil is a toolchain for building reusable, scalable Design Systems. Generate small, blazing fast, and 100% standards based Web Components that run in every browser.

Stencil has some really great features and philosophies I subscribe to. One of its most compelling features for me is that it is essentially just a "toolchain" which generates Web Components with minimal runtime code.

Compiler

This is fundamentally different to runtime frameworks like Angular, Vue or React where these libraries have their own runtime code which needs to be shipped to a browser. Stencil on the other hand compiles the Web Component for you with all its necessary functionality during build time which leads to a smaller
bundle size.

TypeScript

This is opinionated but I absolutely love that Stencil fully embraces TypeScript. It embraces it so far that it even uses TypeScript reflection API to auto-generate Markdown documentation for you. For instance, all your events and props will get automatically documentened with the proper typing.
This is really useful because if you build a UI Kit the documentation is absolutely detremental. While it
does not completely remove the need for documentation, at least you don't need to document the component
atanomy.

In my opinion, a Stencil component takes best of both the Angular and React world; phenomenal TypeScript support as well as TSX.

import { Component, Prop, h } from '@stencil/core';

@Component({
  tag: 'my-first-component',
})
export class MyComponent {

  // Indicate that name should be a public property on the component
  @Prop() name: string;

  render() {
    return (
      <p>
        My name is {this.name}
      </p>
    );
  }
}

Example of a Stencil Component

Framework Bindings

As I mentioned Web Components have some limitations with React. Though Stencil actually provides Framework
Bindings which essentially wrap a Web Component with the target frameworks Component API.

So for instance if you use the React Framework binding, it will automatically generate a React component with all the Props & Events and connect these internally with the Web Component. This is possible because Stencil heavily uses the TypeScript reflection API to auto-generate these integrations.

This also enables an awesome developer experience. Your Web Component will almost become indistinguishable to native React components.

// Without using framework bindings
function MyComponent() {
    return <ui-kit-component></ui-kit-component>
}

// With using framework bindings
import { UiKitComponent } from '@my-ui-kit/react';

function MyComponent() {
    return <UiKitComponent />
}

Conclusion

For us Web Components with Stencil have worked out great so far. In addition, with the Framework Bindings we can give a natural developer experience for React, Angular and Vue developers. Thanks to Shadow DOM and Custom Properties there is now a much clearer interface what is considered public and private functionality of
a component. This aids especially the users of the library so they are less likely to shoot themselves in the foot
by over-customizing the UI-Kit components.

Instead of building multiple UI Kits in Angular, Vue or React, we can just simply have one-source-of-truths and target whatever framework we'd like.

Use Stencil with GatsbyJS

Livio Brunner — Mon, 29 Mar 2021 00:00:00 +0000

Livio is a member of the NestJS core team and creator of the @nestjs/terminus integration.

Stencil is one of my favorite frameworks and in my opinion combines the best of both the Angular and React worlds. Though not only that! Stencil is just a toolchain for building your Web Components - that run in every major browser.

Unfortunately, there is a caveat with Web Components:
They only run with JavaScript and do not work with SSR.

Whilst that is true - if you've built your Web Components library with Stencil - you are covered by their amazing SSR integration!

Let's have a look at how we were able to run our UI library with GatsbyJS!

With this article, I won't go into details on how you set up a Stencil project. So make sure you understand the fundamentals of Stencil already.

Check out the final repository here

Setup the Project

I am going to assume in this article that you have already set up a Stencil project. In my case, this project is called @my-company/webcomponents.

In order to replicate my setup, execute the following commands. We will end up with a simple mono-repository. Though if you want to keep things separated - that would work too!

# ✅ Create the project folder
mkdir stencil-gatsbyjs
cd stencil-gatsbyjs
npm init -y

# ✅ Setup Git (optional)

mkdir packages
cd packages

# ✅ Setup Stencil
# Select "components"
# Choose name "webcomponents" or whatever name you want
npm init stencil

# ✅ Setup GatsbyJS
# Choose name "docs" or whatever name you want
# "Yes" to everything else
npm init gatsby

# ✅ Setup Lerna (optional)
cd ..
npx lerna init
npx lerna bootstrap

My folder structure now looks like this:

$ tree -I node_modules
.
├── lerna.json
├── package.json
└── packages
    ├── docs
    │   ├── README.md
    │   ├── gatsby-config.js
    │   ├── package.json
    │   ├── src
    │   │   ├── images
    │   │   │   └── icon.png
    │   │   └── pages
    │   │       ├── 404.js
    │   │       └── index.js
    │   └── yarn.lock
    └── webcomponents
        ├── LICENSE
        ├── package.json
        ├── readme.md
        ├── src
        │   ├── components
        │   │   └── my-component
        │   │       ├── my-component.css
        │   │       ├── my-component.e2e.ts
        │   │       ├── my-component.spec.ts
        │   │       ├── my-component.tsx
        │   │       └── readme.md
        │   ├── components.d.ts
        │   ├── index.html
        │   ├── index.ts
        │   └── utils
        │       ├── utils.spec.ts
        │       └── utils.ts
        ├── stencil.config.ts
        └── tsconfig.json

10 directories, 24 files

Enable SSR with Stencil

Once we have set up the fundamental project, let's make sure we have added the hydrate app functionality inside our Stencil project.

The hydrate app is a bundle of your same components but compiled so they can be hydrated on a NodeJS server, and generate HTML.

Stencil docs

In order to enable it, simply go to your stencil.config.ts file and add the following line inside the outputTargets-array.

packages/webcomponents/stencil.config.ts

{
  type: 'dist-hydrate-script';
}

This will generate a new folder called hydrate after running npm run build. We will need to use that folder later!

Don't forget to update your .gitignore-file to exclude the hydrate folder.

$ cd packages/webcomponents
$ echo "hydrate" >> .gitignore

As well as updating your package.json-file.

packages/webcomponents/package.json

- "name": "webcomponents",
+ "name": "@my-company/webcomponents",
  "files": [
    "dist/",
    "loader/",
+   "hydrate/"
  ],

As the last step, let's link our library so we can use it locally later.

$ npm link
# Go back to the project root folder
$ cd ../../

Use your Stencil components with GatsbyJS

With the previous step, we have enabled SSR with Stencil. Basically, we now have access to the hydrate folder which exposes the renderToString function. This function basically prerenders the web components into plain old HTML which will be hydrated once JavaScript is loaded.

In order to make use of this function, we have to add it into our gatsby-node.js.

$ cd packages/docs
$ touch gatsby-node.js
$ touch gatsby-browser.js

# We are going to use that package later
$ npm install --save glob

The code is inspired by https://github.com/jonearley/gatsby-plugin-stencil. Personally, I prefer the following enhanced version, since it allows you to add multiple Stencil packages, as well as provide better error handling. I have created a PR against the gatsby-plugin-stencil repository with the changes. So hopefully, you will be able to simply consume this as a Gatsby plugin soon https://github.com/jonearley/gatsby-plugin-stencil/pull/3 (posted @ 16. May 2021)

packages/docs/gatsby-node.js

const util = require('util');
const glob = util.promisify(require('glob'));
const fs = require('fs');

const readFile = util.promisify(fs.readFile);
const writeFile = util.promisify(fs.writeFile);

/*
  Server-side render Stencil web components
*/
exports.onPostBuild = async ({ reporter }) => {
  // Make sure to edit the following lines
  const pluginOptions = {
    module: ['@my-company/webcomponents'],
    renderToStringOptions: {},
  };

  let packages = pluginOptions.module;
  if (!Array.isArray(pluginOptions.module)) {
    packages = [pluginOptions.module];
  }

  const files = await glob('public/**/*.html', { nodir: true });

  const renderToStringOptions = pluginOptions.renderToStringOptions ? pluginOptions.renderToStringOptions : {};

  async function preRenderPage(file, hydrate, pkg) {
    try {
      const page = await readFile(file, 'utf-8');
      const { html, diagnostics = [] } = await hydrate.renderToString(page, renderToStringOptions);

      diagnostics.forEach(diagnostic =>
        reporter.error(`error pre-rendering file: ${file} with ${pkg}. ${JSON.stringify(diagnostic, null, '  ')}`),
      );

      await writeFile(file, html);
    } catch (e) {
      reporter.error(`error pre-rendering file: ${file} with ${pkg}. ${e.message}`);
    }
  }

  async function preRenderPackage(pkg) {
    const hydrate = require(`${pkg}/hydrate`);
    await Promise.all(files.map(file => preRenderPage(file, hydrate, pkg)));
    reporter.info(`pre-rendered ${pkg}`);
  }

  return Promise.all(packages.map(preRenderPackage));
};

In a nutshell, this script will be executed in "post build" (so after the HTML, CSS, and JS files have been generated). We simply go through every HTML file and execute Stencils renderToString function and save the contents.

Now we just need to add a few lines to our gatsby-browser.js.

packages/docs/gatsby-browser.js

const { defineCustomElements } = require('@my-company/webcomponents/loader');
defineCustomElements();

Now we can start using our web component inside our pages.

packages/docs/src/pages/index.js

const IndexPage = () => {
  return (
    <main style={pageStyles}>
      <title>Home Page</title>
      <h1 style={headingStyles}>
        Congratulations
+       <my-component
+         first="Albus"
+         middle="Percival Wulfric Brian"
+         last="Dumbledore"
+       />
        <br />

Done! 🎉
Let's link our Webcomponents library with the docs and build the site.

$ npm link @my-company/webcomponents
$ npm run build
# Start a simple HTTP server on port 8000 from the "public" folder
$ npx servor public index.html 8000

# Open up your site on http://localhost:8000

You should now see the following site. Note the "Hello, World! I'm Albus Percival Wulfric Brian Dumbledore" is being rendered by our Webcomponent!

Inspect the output

In order to double-check the SSR we can try disabling JavaScript and the website should render the same. In Chrome, Open up Dev Tools -> CMD + SHIFT + P or CTRL + SHIFT + P -> Disable JavaScript -> Reload the page.

You still see the "Hello World! I'm Albus..."? Great! The Webcomponent still renders with JavaScript disabled.

So what did Stencils renderToString actually do? Well let's have a look at the diff of the built index.html file we just generated from the npm run build.

As first stricking difference we see in the <head>-tag that Stencil has added the CSS of our web component:

   <head>
     <meta charset="utf-8" />
     <meta http-equiv="x-ua-compatible" content="ie=edge" />
@@ -8,6 +8,12 @@
       content="width=device-width, initial-scale=1, shrink-to-fit=no"
     />
     <meta name="generator" content="Gatsby 3.5.0" />
+    <style sty-id="sc-my-component">
+      /*!@:host*/
+      .sc-my-component-h {
+        display: block;
+      }
+    </style>

Also inside the HTML of our Webcomponent has been rendered with the correct text (removed comments and unnecessary attributes for readability).

<h1 style="margin-top: 0; margin-bottom: 64px; max-width: 320px">Congratulations
      <my-component
        first="Albus"
        middle="Percival Wulfric Brian"
        last="Dumbledore"
-      ></my-component>
+       class="sc-my-component-h hydrated">
+         <div class="sc-my-component">
+           Hello, World! I'm Albus Percival Wulfric Brian Dumbledore
+         </div>
+       </my-component>

So basically the renderToString function takes care of the first render - which allows us to use the WebComponents even without JavaScript.

Add TypeScript support within GatsbyJS

In case you are using GatsbyJS with Typescript, adding support to your Stencil Webcomponents is fairly straightforward.

Create a new folder called types inside the packages/docs/-folder

$ cd packages/docs
$ mkdir types && cd types
$ touch wc.d.ts

and add the following code inside the types/wc.d.ts file

packages/docs/types/wc.d.ts

// This is a workaround to include type-safe stencil web components
// with TSX https://github.com/ionic-team/stencil/issues/1636
import { JSX as LocalJSX } from '@my-company/webcomponents';
import { DetailedHTMLProps, HTMLAttributes } from 'react';

type StencilProps<T> = {
  [P in keyof T]?: Omit<T[P], 'ref'> | HTMLAttributes<T>;
};

type ReactProps<T> = {
  [P in keyof T]?: DetailedHTMLProps<HTMLAttributes<T[P]>, T[P]>;
};

type StencilToReact<T = LocalJSX.IntrinsicElements, U = HTMLElementTagNameMap> = StencilProps<T> & ReactProps<U>;

declare global {
  // eslint-disable-next-line @typescript-eslint/no-namespace
  export namespace JSX {
    interface IntrinsicElements extends StencilToReact {}
  }
}

Load the type definition file within your tsconfig.json

packages/docs/tsconfig.json

{
  "compilerOptions": {
+   "typeRoots": ["./types", "node_modules/@types"],
+   "paths": {
+     "*": ["types/*"]
+   }
  },
  "include": [
+   "./types/*"
  ]
}

Now we keep our types up to date. The wc.d.ts file import the types of your Webcomponents library (in our case @my-company/webcomponents) and converts them to "React compatible" JSX type definitions.

Use `@stencil/react-output-target` with GatsbyJS

In case you are using @stencil/react-output-target
to wrap your Webcomponents within React components in order to have a more "native" feel, follow this chapter.

Feel free to skip this chapter in case you are fine using the raw Webcomponents.
Beware though, React and Webcomponents comes with some limitations which are fixed by @stencil/react-output-target.
So personally, I can only recommend this plugin for your Stencil application.

Setup the React package

Skip this chapter in case you have already setup your React package.

Run the following commands in your shell of choice.

cd packages/

# Install the React output target
cd webcomponents
npm install --save-dev @stencil/react-output-target
cd ../

# Setup the React project
mkdir -p react/src
cd react
touch .gitignore
touch package.json
touch rollup.config.js

Inside your stencil.config.ts add the following lines to configure the
React output target.

packages/webcomponents/stencil.config.ts

  import { Config } from '@stencil/core';
+ import { reactOutputTarget } from '@stencil/react-output-target';

export const config: Config = {
  namespace: 'webcomponents',
  outputTargets: [
+   reactOutputTarget({
+     componentCorePackage: 'component-library',
+     proxiesFile: '../react/src/components.ts',
+   }),

Once we run the build command again within the Stencil project, we should now see
new files generated in the packages/react/-project.

$ cd packages/webcomponents
$ npm run build

Let's clean that up as well!

packages/react/.gitignore

# compiled output
/dist

# dependencies
/node_modules


# misc
npm-debug.log
yarn-error.log
testem.log
/typings

# System Files
.DS_Store
Thumbs.db

/src
!/src/typings.d.ts
dist-transpiled

Now we just need to setup our package.json.

packages/react/package.json

{
  "name": "@my-company/react",
  "version": "1.0.0",
  "description": "",
  "keywords": [],
  "author": "",
  "license": "ISC",
  "files": ["dist/"],
  "main": "dist/index.js",
  "module": "dist/index.js",
  "esmodule": "dist/index.js",
  "types": "dist/index.d.ts",
  "source": "src/index.ts",
  "scripts": {
    "build": "npm run clean && npm run compile",
    "clean": "rimraf dist && rimraf dist-transpiled",
    "compile": "npm run tsc && rollup -c",
    "tsc": "tsc -p ."
  },
  "peerDependencies": {
    "react": ">=16.8.6",
    "react-dom": ">=16.8.6"
  },
  "devDependencies": {
    "@types/node": "^12.12.38",
    "@types/react": "^16.9.27",
    "@types/react-dom": "^16.9.7",
    "@rollup/plugin-node-resolve": "^8.1.0",
    "react": "^16.13.1",
    "react-dom": "^16.13.1",
    "react-scripts": "^3.4.1",
    "rollup": "^2.26.4",
    "rollup-plugin-sourcemaps": "^0.6.2",
    "typescript": "^3.7.5",
    "rimraf": "^3.0.2"
  }
}

and install the dependencies with

$ npm link @my-company/webcomponents
$ npm install

Bundle your React package

Personally, I like to use Rollup for bundling my libraries. Though feel free to use
whatever tool you want to use. Make sure you produce a CommonJS output bundle
so that it works all fine with GatsbyJS

Inside your rollup.config.js add the following configuration

packages/react/rollup.config.js

import resolve from '@rollup/plugin-node-resolve';
import sourcemaps from 'rollup-plugin-sourcemaps';

export default {
  input: {
    index: 'dist-transpiled/index',
  },
  output: [
    {
      dir: 'dist/',
      entryFileNames: '[name].esm.js',
      chunkFileNames: '[name]-[hash].esm.js',
      format: 'es',
      sourcemap: true,
    },
    {
      dir: 'dist/',
      format: 'commonjs',
      preferConst: true,
      sourcemap: true,
    },
  ],
  external: id => !/^(\.|\/)/.test(id),
  plugins: [resolve(), sourcemaps()],
};

Also, add a tsconfig.json which transpiles our TypeScript files
before we bundle it with Rollup.

packages/react/tsconfig.json

{
  "compilerOptions": {
    "strict": true,
    "allowUnreachableCode": false,
    "allowSyntheticDefaultImports": true,
    "declaration": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "esModuleInterop": true,
    "lib": ["dom", "es2015"],
    "importHelpers": true,
    "module": "es2015",
    "moduleResolution": "node",
    "noImplicitAny": true,
    "noImplicitReturns": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "outDir": "dist-transpiled",
    "declarationDir": "dist/types",
    "removeComments": false,
    "inlineSources": true,
    "sourceMap": true,
    "jsx": "react",
    "target": "es2017"
  },
  "include": ["src/**/*.ts", "src/**/*.tsx"],
  "compileOnSave": false,
  "buildOnSave": false
}

By running the build command of the React package we are generating
a new dist-bundle

$ cd packages/react
$ npm run build

Voilà! We now successfully added a React integration!
Let's link that one up so we can use it within our Gatbsy application.

$ cd packages/react
$ npm link

Use the React package with Gatsby

First of all we need to make sure both libraries are linked.

npm link @my-company/webcomponents @my-company/react

As a next step, we can refactor our previously used Webcomponent inside the pages/index.js file

packages/docs/src/pages/index.js

+ import { MyComponent } from "@my-company/react";

 const IndexPage = () => {
  return (
    <main style={pageStyles}>
      <title>Home Page</title>
      <h1 style={headingStyles}>
        Congratulations
-       <my-component
+       <MyComponent
          first="Albus"
          middle="Percival Wulfric Brian"
          last="Dumbledore"
        />
        <br />

and that is it! We can now run and build the website as we
used to.

Conclusion

In this article, we examined why I personally love Stencil.
This framework is so much more than "just Webcomponents". For myself,
as a UI library maintainer it so rewarding to offer components which are framework
independent, yet can be integrated into frameworks such as React to have a more natural
developer experience.

Not only that - you can go above and beyond by enabling SSR. The TypeScript support
for users of a Stencil UI library is just phenomenal.

The cherry on top - which we, unfortunately, did not have a look at in this article - is
the automated markdown documentation of each component.
These Markdown files can now easily be integrated into your Gatsby documentation!

Check out the final repository here

Create your first module with Deno

Livio Brunner — Fri, 21 Feb 2020 21:54:01 +0000

In this article, we want to have a look at how to get started with your first module using Deno. We will focus on the general structure and patterns which have emerged from the Deno community thus far.

No time to read articles? Head right over the repository.

Deno is a secure runtime for JavaScript and TypeScript. It aims to provide a productive and secure scripting environment for the modern programmer. It is built on top of V8, Rust, and TypeScript. If you want to learn about Deno, I recommend you watch the latest Deno talk by Ryan Dahl and Kitson Kelly, or check out the official website.

Our desired outcome after this article should be:

Setup the development environment
Getting started with the file structure
- mod.ts
- deps.ts
- mod_test.ts, test.ts and test_deps.ts
Tooling
Continous integration
Publishing
Conclusion

Setup the development environment

First things first, let's install Deno. You can find the installation instructions on https://deno.land.

Check your installation by running the following command in your terminal.

deno -v

Once installed, I recommended installing the justjavac.vscode-deno extension for VSCode. At this moment you will most likely need some kind of plugin since the import statements of Deno are a little bit different than with Node.js.

The vscode-deno extension fixes these kinds of remote imports by caching the typings in a special directory.

Getting started with the file structure

To get started real quick, I have prepared a repository for you. Don't worry though, I will go over the files and directories in detail.

git clone https://github.com/BrunnerLivio/deno-lib-starter.git hello-deno
cd hello-deno

Before your muscle memory kicks in and you type npm install or yarn -- Let's check beforehand what we have in our folder.

├── deps.ts
├── .github
│   └── workflows
│       └── deno.yml
├── .gitignore
├── mod_test.ts
├── mod.ts
├── README.md
├── test_deps.ts
├── test.ts
└── tsconfig.json

mod.ts

The mod.ts file is usually the entry point of your module. The Node.js equivalent would be index.js. Here we expose everything of our public API. Depending on how large your project is, you wanna keep the mod.ts file clean by only using import and export-statements, rather than defining actual functionality.

In this starter module, I decided to not split it up, because from my point of view it is not necessary.

// mod.ts
import { bold } from "./deps.ts";

/** Returns `Hello World` in bold */
export function getHelloWorld(): string {
  return bold("Hello World");
}

deps.ts

Wait -- where is my package.json?

No worries, we don't need a package.json when using Deno. Most Deno modules centralize their dependencies using a deps.ts file.

Let's have a look at how we structure this file.

// deps.ts
// Add your dependencies in here
export { bold } from "https://deno.land/std@v0.32.0/fmt/colors.ts";

There a two major differences to Node.js:

Import statements can make use of URLs
Import statements must have a file ending

We are importing a module from the Deno standard library and exporting the bold function for our internal use. When importing from deno.land we can say

"Whatever, just give me the latest and greatest..."

https://deno.land/std/<PATH_TO_MODULE>.ts

or "I do not like bungee jumping, please give a specific version"

https://deno.land/std@{VERSION}/<PATH_TO_MODULE>.ts

In general, you should always import external modules using your deps.ts file. It is way easier to overview all your dependencies, rather than having to look in every single file.

mod_test.ts, test.ts and test_deps.ts

Deno comes with a testing framework out of the box. It is simple, yet pretty useful and so far all I needed. To import the testing functions, we use a test_deps.ts file.

// test_deps.ts
// Add your test dependencies in here
export { test, runTests } from "https://deno.land/std@v0.32.0/testing/mod.ts";
export { assertEquals } from "https://deno.land/std@v0.32.0/testing/asserts.ts";

Let's test our mod.ts then. Similarly to Node.js, where most projects use a <NAME>.spec.ts file for Unit Tests, we use <NAME>_test.ts.

Let's check whether our getHelloWorld() function from the mod.ts file returns a bold Hello World in a file called mod_test.ts.

// mod_test.ts
import { test, assertEquals, runTests } from "./test_deps.ts";
import { getHelloWorld } from "./mod.ts";

test(function test_get_hello_world() {
  assertEquals(getHelloWorld(), "\x1b[1mHello World\x1b[22m");
});

runTests();

If we execute deno ./mod_test.ts in our shell, we should see that our test passes!

running 1 tests
OK     test_get_hello_world (0.00ms)

test result: OK 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out (2.00ms)

Though, usually, you do not have a single test file in your repository (hopefully!!). That is why it is seen as best practice, to have a test.ts file in your repository, which simply imports all of your tests and runs them. While we are at it, let's move the runTests() function into the test.ts file.

// test.ts
import { runTests } from "./test_deps.ts";

import "./mod_test.ts";

runTests();

With deno test.ts we should get the same result as before. That is about it for our file structure. Check out Deno's official style guide in case you are ever lost on how to structure/name things!

Tooling

What I love about Deno are the out-of-the-box things you get. It does not stop there when it comes to tooling. Deno provides Prettier formatting directly from the CLI.

Simply run deno fmt **/*.ts and it will format your code. No headaches which format rules are "trendy" currently. No more hunting for the latest and greatest Formatter which has been adopted the most by the community. It is all just there... almost...
When it comes to linting, there is not a as convenient solution yet. Deno is planning to support that too. Check out this Github issue to stay up to date!

Continous integration

Since our tooling is already installed with Deno, our CI configuration is really simple. In this article, we are going to make use of Github Actions. On top of that - to make our lives easier - we use denolib/setup-deno action to install Deno.

In our .github/workflows/deno.yml the file we can find the following configuration.

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        deno: [0.32.0, 0.31.0, 0.30.0]
    name: Test with Deno ${{ matrix.deno }} 

    steps:
      - uses: actions/checkout@master

      - name: Setup Deno
        uses: denolib/setup-deno@master
        with:
          deno-version: ${{ matrix.deno }}

      - name: Setup Node
        uses: actions/setup-node@master
        with:
          node-version: 12

      - name: Print deno version
        run: deno --version

      - name: Check format
        run: deno fmt --check **/*.ts

      - name: Run tests
        run: deno test.ts

So basically we are using a range of the latest Deno versions (from 0.30.0 to 0.32.0), check the formatting and run the tests. Pretty straight forward, isn't it?

Publishing

In Deno, there is no such thing as publishing your module to a registry, owned by a company. As we learned before, we can simply import modules using URLs. Therefore any website (GitHub included) is our registry!
To make your module more visible, there is also a web interface on deno.land/x/, which is home to third party Deno libraries. To submit your library there, simply go to the websites repository and edit the database.json file.

Then add copy and paste the following JSON object into the file. Make sure you paste it in alphabetical order and don't use dashes - for module names. Use underscores _ for spaces instead.

"my_library_name": {
  "type": "github",
  "owner": "<MY_GITHUB_USERNAME>",
  "repo": "<MY_REPOSITORY_NAME",
  "desc": "<REPOSITORY_DESCRIPTION>"
},

Go to the bottom of the page, add a meaningful commit message and press the green Propose file change button.

Now we only need to create a Pull Request and wait for one of the maintainers' approval to merge.

Your code will still be hosted on GitHub and you won't need to re-submit any code updates to deno.land. Therefore Continous Delivery is already a "given" with Deno.

Conclusion

If I would need to pick only one thing I love the most about Deno, it is the tooling. Since Deno makes use of the TypeScript compiler, we do not have to transpile our code. Due to the integrated formatting and soon linter, we don't even have to care about downloading and configuring them.

I think Deno has a great future ahead. There are still a lot of things missing and I would not use it in production yet, but from what I have seen so far, Deno has done a lot of things right!

Create an icon web font for your design system

Livio Brunner — Fri, 03 Jan 2020 20:22:13 +0000

Icons are an essential part of Design Systems and Brand Identity. At Roche we are building a UI Kit components library that should provide icons out of the box. For convenience and performance reasons we want to offer icons not only as SVG graphics but also as an icon web font.

In this article, I want to go in-depth on the technical side of things how we, at Roche, were able to automate the conversion of SVG graphics to icon web fonts.

No time to read articles? Head over to the final repository directly.

Creating the Icon Font

Whilst there are many tools and websites to generate icon web fonts on the market, not many were sufficient enough. Our goal was to have a tool(-chain) that was able to run automatically inside a CI Pipeline of a Git repository, so the process would be automated. Manually generating the font by drag-and-dropping icon images into some arbitrary website was just not doing it for us.

That is why we were looking into CLI tools, which were as customizable as we needed it to be.

Prepare the repository

The icon font shall be deployed as an NPM package. Therefore we need to create a new repository with a standard NPM setup. Make sure you have NodeJS 10.x.x and Git installed.

# Create the repository directory
mkdir my-icon-font && cd my-icon-font

# Initialize Git and NPM
git init
npm init -y

cat > .gitignore <<EOF
node_modules
# Ignore the generated assets
font/*[.svg, .eot, .css, .ttf, .woff, .woff2, .html, .json]
EOF

touch .npmignore

# Create the directory for the icons
mkdir svg font

Let's copy over our SVG icons into the newly created my-icon-font/svg-directory.

For the sake of convenience, I am going to use icons from flaticon.com. Go to the page, click on an icon you would like and download it as SVG image.

... and copy it over.

mv /Path/To/Downloads/icon.svg svg/

Install icon-font-generator

Icon Font Generator is a CLI tool built with NodeJS and available through NPM.

Let's check whether we can run the tool.

npx icon-font-generator --help

Generate the icon font

Let's generate the icon font using icon-font-generator like so.

npx icon-font-generator svg/*.svg \
-o font/ \
--name "my-icon-font" \
--height 100

In your my-icon-font/font-directory you should now find the following files.

font
├── my-icon-font.css # CSS file which includes the icon fonts and generates classes
├── my-icon-font.eot # The icon font file in EOT format
├── my-icon-font.html # A preview website of the icon font
├── my-icon-font.json # Icon metadata in JSON
├── my-icon-font.svg # The icon font file in SVG format
├── my-icon-font.ttf # The icon font file in TTF format
├── my-icon-font.woff # The icon font file in WOFF format
└── my-icon-font.woff2 # The icon font file in WOFF2 format

Let's open up the font/my-icon-font.html file to see whether the icons look fine.

Awesome!

If we sneak peek into the CSS file font/my-icon-font.css, we will see how it all works.

These following lines define our custom font, called "my-icon-font". As you can see, it makes use of all the generated font files. Therefore if a browser does not support a font format (e.g. SVG), it will fall back to another one.

@font-face {
    font-family: "my-icon-font";
    src: url("./my-icon-font.eot?65e38a3078508e502b3cc8df63e55a16?#iefix") format("embedded-opentype"),
url("./my-icon-font.woff2?65e38a3078508e502b3cc8df63e55a16") format("woff2"),
url("./my-icon-font.woff?65e38a3078508e502b3cc8df63e55a16") format("woff"),
url("./my-icon-font.ttf?65e38a3078508e502b3cc8df63e55a16") format("truetype"),
url("./my-icon-font.svg?65e38a3078508e502b3cc8df63e55a16#my-icon-font") format("svg");
}

The next lines define the styling of the icon itself. Every i-HTML Element which begins with class icon-* will apply our icon font.

i[class^="icon-"]:before, i[class*="icon-"]:before {
    font-family: my-icon-font !important;
    font-style: normal;
    font-weight: normal !important;
    font-variant: normal;
    text-transform: none;
    line-height: 1;
    -webkit-font-smoothing: antialiased;
    -moz-osx-font-smoothing: grayscale;
}

For each specific icon, an additional class is being generated with a unique Unicode which represents our icon.

.icon-contact-list:before {
    content: "\f101";
}
.icon-groups:before {
    content: "\f102";
}

If we include this CSS file in an HTML document, we can access the icon like this.

<!-- Include the CSS file (only once) -->
<link rel="stylesheet" type="text/css" href="my-icon-font.css" />

<i class="icon-contact-list"></i>

Compress SVG and fix odd-looking icons

In our case, some of the icons had strange strokes or sometimes not circular, when they needed to be.

To fix this and also, in addition, compress the SVG images, we can use the SVGO CLI tool.
SVGO, in short, is a tool to optimize SVG graphics.

Lets set up the configuration we are going to need to fix the faulty icons.

cat > config.yml <<EOF
plugins:
  - convertPathData:
      noSpaceAfterFlags: false
  - mergePaths:
      noSpaceAfterFlags: false
EOF

... and execute it.

npx svgo svg/*.svg -o icons --config config.yml

Now the icons should look all fine!

So we do not forget the commands we have executed, let's add it to our package.json and install the tools locally.

npm i -D svgo icon-font-generator

package.json

{
  "scripts": {
    "build": "npm run icons:compress && npm run icons:font",
    "icons:compress": "svgo svg/*.svg -o svg --config config.yml",
    "icons:font": "icon-font-generator svg/*.svg -o font/ --name \"my-icon-font\" --height 100"
  }
}

Automate it using Github Actions

We want to re-generate the icon fonts on every commit using Github Actions.
In order to get set up, we need to create a configuration file, which defines the workflow of our pipeline.

mkdir -p .github/workflows

touch .github/workflows/nodejs.yml

We can keep the configuration file simple for now. We are just going to use NodeJS 10, install our dependencies and run npm run build.

.github/workflows/nodejs.yml

name: Node CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [10.x]

    steps:
    - uses: actions/checkout@v1
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v1
      with:
        node-version: ${{ matrix.node-version }}
    - name: npm install and build
      run: |
        npm ci
        npm run build
      env:
        CI: true

To see whether everything works, let's commit it to our remote repository.

git remote add origin <YOUR_GITHUB_URL>
git add -A .
git commit -m "Initial Commit"
git push origin master

Your repository should now tell you whether everything is set up correctly.

Continous Deployment using Semantic Release

The last step to fully automate this process is to publish an NPM package and ZIP file using Semantic Release to our end customer. We can use Semantic Release for that, which offers fully automated version management and package publishing.

First things first, let's reset our package.json-version.

package.json

{
  "version": "0.0.0-development"
  ...
}

Semantic Release will automatically increment our versioning from here on out.

The next thing we need to do is adding an NPM Access Token to Github Actions.

Head over to npmjs.org > Login > Click on Profile > Auth Tokens > Create new Token.

Once you have gathered your NPM token, head over to Github.
Goto Your Repository > Settings > Secrets > Add a new Secret.
Call it NPM_TOKEN and add the copied key.

Once added, we only need to update our .github/workflows/nodejs.yml file and we should be good to go.

    ...
    - name: Semantic Release
      run: npx semantic-release
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

Once a new SVG icon is now being added via a commit, it should now automatically publish the NPM package and create a Github release.
Make sure you start the commit message with feat(): <MESSAGE>.

Conclusion

This setup is definitely pretty advanced, but the benefits are huge. Automate this process using a pipeline backed by a version control system helps us to develop an icon pack for the long term.

A UI/UX designer could create Pull Request by themselves on Github using the Web interface. Since the icon fonts get generated using Github Actions, icon contributors do not need to download any tooling.

Resources

Showcase Github Repository

Found a Typo? Let me know!

Advanced NestJS: Dynamic Providers

Livio Brunner — Sat, 17 Aug 2019 00:00:00 +0000

Livio is a member of the NestJS core team and creator of the @nestjs/terminus integration

Intro

Dependency Injection (short DI) is a powerful technique to build a loosely coupled architecture in a testable manner. In NestJS an item which is part of the DI context is called provider. A provider consists of two main parts, a value, and a unique token. In NestJS you can request the value of a provider by its token. This is most apparent when using the following snippet.

import { NestFactory } from '@nestjs/core';
import { Module } from '@nestjs/common';

@Module({
  providers: [
    {
      provide: 'PORT',
      useValue: 3000,
    },
  ],
})
export class AppModule {}

async function bootstrap() {
  const app = await NestFactory.createApplicationContext(AppModule);

  const port = app.get('PORT');
  console.log(port); // Prints: 3000
}
bootstrap();

The AppModule consists of one provider with the token PORT.

We bootstrap our application by calling NestFactory.createApplicationContext (this method does the same as NestFactory.create but does not initiate an HTTP instance).
Later on, we request the value of our provider with app.get('PORT'). This will return 3000 as specified in our provider.

Fair enough. But what if you do not know what you will provide to the user? What if you need to compute the providers during runtime?

This article goes into a technique which we use often for various NestJS integrations. This technique will allow you to build highly dynamic NestJS applications and still make use of the advantages of DI.

What are we trying to achieve

To see use cases of dynamic providers we will use a simple but useful example. We want to have a parameter decorator called Logger which takes an optional prefix as string. This decorator will inject a LoggerService, which prepends the given prefix to every log message.

So the final implementation will look like this:

@Injectable()
export class AppService {
  constructor(@Logger('AppService') private logger: LoggerService) {}

  getHello() {
    this.logger.log('Hello World'); // Prints: '[AppService] Hello World'
    return 'Hello World';
  }
}

Setup a NestJS application

We will make use of the NestJS CLI to get started quickly. If you have not installed it, use the following command:

npm i -g @nestjs/cli

Now run the following command in your terminal of choice to bootstrap your Nest application.

nest new logger-app && cd logger-app

Logger service

Let's start off with our LoggerService. This service will get injected later when we use our @Logger() decorator. Our basic requirements for this service are:

A method which can log messages to stdout
A method which can set the prefix of each instance

Once again we will use the NestJS CLI to bootstrap our module and service.

nest generate module Logger
nest generate service Logger

To satisfy our requirements we build this minimal LoggerService.

// src/logger/logger.service.ts

import { Injectable, Scope } from '@nestjs/common';

@Injectable({
  scope: Scope.TRANSIENT,
})
export class LoggerService {
  private prefix?: string;

  log(message: string) {
    let formattedMessage = message;

    if (this.prefix) {
      formattedMessage = `[${this.prefix}] ${message}`;
    }

    console.log(formattedMessage);
  }

  setPrefix(prefix: string) {
    this.prefix = prefix;
  }
}

First of all, you may have realized that the @Injectable() decorator uses the scope option with Scope.TRANSIENT. This basically means every time the LoggerService gets injected in our application, it will create a new instance of the class. This is mandatory due to the prefix attribute. We do not want to have a single instance of the LoggerService and constantly override the prefix option.

Other than that, the LoggerService should be self-explanatory.

Now we only have to export our service in the LoggerModule, so we can use it in AppModule.

// src/logger/logger.module.ts

import { Module } from '@nestjs/common';
import { LoggerService } from './logger.service';

@Module({
  providers: [LoggerService],
  exports: [LoggerService],
})
export class LoggerModule {}

Let's see if it works in our AppService.

// src/app.service.ts

import { Injectable } from '@nestjs/common';
import { LoggerService } from './logger/logger.service';

@Injectable()
export class AppService {
  constructor(private readonly logger: LoggerService) {
    this.logger.setPrefix('AppService');
  }
  getHello(): string {
    this.logger.log('Hello World');
    return 'Hello World!';
  }
}

Seems fine - let's start the application with npm run start and request the website with curl http://localhost:3000/ or open up http://localhost:3000 in your browser of choice.

If everything is set up correctly we will receive the following log output.

[AppService] Hello World

That is cool. Though, we are lazy, aren't we? We do not want to explicitly write this.logger.setPrefix('AppService') in the constructor of our services? Something like @Logger('AppService') before our logger-parameter would be way less verbose and we would not have to define a constructor every time we want to use our logger.

Logger Decorator

For our example, we do not need to exactly know how decorators work in TypeScript. All you need to know is that functions can be handled as a decorator.

Lets quickly create our decorator manually.

touch src/logger/logger.decorator.ts

We are just going to reuse the @Inject() decorator from @nestjs/common.

// src/logger/logger.decorator.ts

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

export const prefixesForLoggers: string[] = new Array<string>();

export function Logger(prefix: string = '') {
  if (!prefixesForLoggers.includes(prefix)) {
    prefixesForLoggers.push(prefix);
  }
  return Inject(`LoggerService${prefix}`);
}

You can think of @Logger('AppService') as nothing more than an alias for @Inject('LoggerServiceAppService'). The only special thing we have added is the prefixesForLoggers array. We will make use of this array later. This array just stores all the prefixes we are going to need.

But wait, our Nest application does not know anything about a LoggerServiceAppService token. So let's create this token using dynamic providers and our newly created prefixesForLoggers array.

Dynamic providers

In this chapter, we want to have a look at dynamically generating providers.
We want to

create a provider for each prefix
- each of these providers must have a token like this 'LoggerService' + prefix
- each provider must call LoggerService.setPrefix(prefix) upon its instantiation

To implement these requirements we create a new file.

touch src/logger/logger.providers.ts

Copy & paste the following code into your editor.

// src/logger/logger.provider.ts

import { prefixesForLoggers } from './logger.decorator';
import { Provider } from '@nestjs/common';
import { LoggerService } from './logger.service';

function loggerFactory(logger: LoggerService, prefix: string) {
  if (prefix) {
    logger.setPrefix(prefix);
  }
  return logger;
}

function createLoggerProvider(prefix: string): Provider<LoggerService> {
  return {
    provide: `LoggerService${prefix}`,
    useFactory: logger => loggerFactory(logger, prefix),
    inject: [LoggerService],
  };
}

export function createLoggerProviders(): Array<Provider<LoggerService>> {
  return prefixesForLoggers.map(prefix => createLoggerProvider(prefix));
}

The createLoggerProviders-function creates an array of providers for each prefix set by the @Logger() decorator. Thanks to the useFactory functionality of NestJS we can run a the LoggerService.setPrefix() method before the provider gets created.

All we need to do now is to add these logger providers to our LoggerModule.

// src/logger/logger.module.ts

import { Module } from '@nestjs/common';
import { LoggerService } from './logger.service';
import { createLoggerProviders } from './logger.providers';

const loggerProviders = createLoggerProviders();

@Module({
  providers: [LoggerService, ...loggerProviders],
  exports: [LoggerService, ...loggerProviders],
})
export class LoggerModule {}

As simple as that. Wait no, that does not work? Because of JavaScript, man. Let me explain: createLoggerProviders will get called immediately once the file is loaded, right? At that point in time, the prefixesForLoggers array will be empty inside logger.decorator.ts, because the @Logger() decorator was not called.

So how do we bypass that? The holy words are Dynamic Module. Dynamic modules allow us to create the module settings (which are usually given as parameter of the @Module-decorator) via a method. This method will get called after the @Logger decorator calls and therefore prefixForLoggers array will contain all the values.

If you want to learn more about why this works, you may wanna check out this video about the JavaScript event loop

Therefore we have to rewrite the LoggerModule to a Dynamic Module.

// src/logger/logger.module.ts

import { DynamicModule } from '@nestjs/common';
import { LoggerService } from './logger.service';
import { createLoggerProviders } from './logger.providers';

export class LoggerModule {
  static forRoot(): DynamicModule {
    const prefixedLoggerProviders = createLoggerProviders();
    return {
      module: LoggerModule,
      providers: [LoggerService, ...prefixedLoggerProviders],
      exports: [LoggerService, ...prefixedLoggerProviders],
    };
  }
}

Do not forget to update the import array in app.module.ts

// src/logger/app.module.ts

@Module({
  controllers: [AppController],
  providers: [AppService],
  imports: [LoggerModule.forRoot()],
})
export class AppModule {}

...and that's it! Let's see if it works when we update the app.service.ts

// src/app.service.ts

@Injectable()
export class AppService {
  constructor(@Logger('AppService') private logger: LoggerService) {}

  getHello() {
    this.logger.log('Hello World'); // Prints: '[AppService] Hello World'
    return 'Hello World';
  }
}

Calling http://localhost:3000 will give us the following log

[AppService] Hello World

Yey, we did it!

Conclusion

We have touched on numerous advanced parts of NestJS. We have seen how we can create simple decorators, dynamic modules and dynamic providers. You can do impressive stuff with it in a clean and testable way.

As mentioned we have used the exact same patterns for the internals of @nestjs/typeorm and @nestjs/mongoose. In the Mongoose integration, for example, we used a very similar approach for generating injectable providers for each model.

You can find the code in this Github repostiory. I have also refactored smaller functionalities and added unit tests, so you can use this code in production. Happy hacking :)

DEV Community: Livio Brunner

Screenbean - Pimp your screenshots 💅

💡 Motivation

📝 Technical Decisions

👨‍💻 Tech Stack

Why we chose WebComponents for our Design System

Context

What the heck are Web Components?

Why Web Components

Shadow DOM and Custom Properties

Framework Agnosticity

Downsides of Web Components and how to workaround it

Stencil

Compiler

TypeScript

Framework Bindings

Conclusion

Further Readings

Use Stencil with GatsbyJS

Setup the Project

Enable SSR with Stencil

Use your Stencil components with GatsbyJS

Inspect the output

Add TypeScript support within GatsbyJS

Use @stencil/react-output-target with GatsbyJS

Setup the React package

Bundle your React package

Use the React package with Gatsby

Conclusion

Create your first module with Deno

Setup the development environment

Getting started with the file structure

mod.ts

deps.ts

mod_test.ts, test.ts and test_deps.ts

Tooling

Continous integration

Publishing

Conclusion

Create an icon web font for your design system

Creating the Icon Font

Prepare the repository

Install icon-font-generator

Generate the icon font

Compress SVG and fix odd-looking icons

Automate it using Github Actions

Continous Deployment using Semantic Release

Conclusion

Resources

Advanced NestJS: Dynamic Providers

Intro

What are we trying to achieve

Setup a NestJS application

Logger service

Logger Decorator

Dynamic providers

Conclusion

Use `@stencil/react-output-target` with GatsbyJS