DEV Community: Christian Kotzbauer

Announcing the Simple-Tree-Component!

Christian Kotzbauer — Sat, 19 Jun 2021 14:44:30 +0000

Introduction

Over a year ago, a colleague of mine and me were searching for a javascript-component capable for tree-rendering. There were a few must-have aspects we were looking for:

Zero runtime-dependencies (especially no JQuery)
Actively maintained
Framework-agnostic
Good integration with modern bundlers

These requirements did already reduce the number of possible libraries to a considerable degree. In addition, we had to consider the requirements of our product as well:

Text-search through tree-nodes
Mode where the tree is rendered in a container
Dropdown-mode for single-selection
Dropdown-mode for multi-selection

Neither did any component meet our requirements, nor did using two libraries for the different use-cases turn out to be sufficient. So we started considering the effort of developing and maintaining our own component with some extras, as TypeScript support. The "Simple-Tree-Component" was born. The first lockdown-phase of the Covid-pandemic in summer 2020 gave us time to implement the basics.

Let's have a look at the different features and concepts.

Three modes

As mentioned above, we had to implement different modes for multiple use-cases and ui-scenarios. The simplest mode simply renders the tree in a container:

It's possible to enable multi-selection with Checkboxes if needed. Furthermore, it can be configured whether child-nodes are automatically selected or deselected when a parent-node changes its selection-state.

The second variant we had to get covered, was a single-select dropdown:

When the dropdown-flyout is closed, only the box itself is displayed in the same way as of native <select> HTML-elements. A function can be defined which is called on each node-selection to customize the text displayed in closed-state. With the Emphasize-feature it is possible to add a custom css-class to the component-box. This, for example, makes it possible to add a icon as "eye-catcher" for the current selection.

Last but not least, the component can handle multi-selections with a dropdown, too. All selected nodes are rendered as pillboxes and can be deselected individually or all at once.

Most of the features mentioned for the "single-selection" mode can be used for "multi-selection" as well.

Search and Highlighting

In all mode-variants it is possible to enable the text-search-feature to filter tree-nodes. The chain from a matching child-node to its root-node is always displayed. By default non-matching childs are not displayed when a parent-node matches the search-text but this behaviour can be changed individually. In addition to searching in general, the search-results can be highlighted as well.

Styling

All styles are implemented with SASS to ensure good adaptability. The sass-files are also part of the NPM package.

Data-driven

The main concept for data-handling was using a completely data-driven approach. The reason for it was the necessity of removing and modifying existing tree-nodes and adding new ones when the tree is already rendered. Even though it would be possible to use a DOM-driven approach here, extracting the data-states from the UI and still making it work with any framework at the same time would turn out more difficult.

Type-safety

The whole code is developed in TypeScript with a very strong typing, especially for the public API. This makes development for library-contributors and for developers easier and more efficient.

Browser compatibility

The code is compiled to ES2015 at the moment. This should ensure compability to most modern browsers. However - also due to the lack of cross-browser tests - there is no explicit list of supported browsers or versions. The only thing we can be sure about is, that there will never be support for any Internet Explorer version. :)

Documentation

All features, other aspects and a "Getting started" are also documented. At the Github-Repo you can find a demo-integration with the SPA-Framework "Aurelia".

Contributions

As every open-source project, this component is also open for issues, discussions and feature-requests. Do not hesistate to reach out to us. We're looking forward to your feedback.

Conclusion

There are some new features in development as well as improvements for increasing the stability even more. At the end of this post I want to say "Thank you!" to my colleague Thomas who helped me a lot in creating this library from the first day on. Many thanks!

Managing K8s Authorization like charm

Christian Kotzbauer — Sat, 13 Jun 2020 10:27:23 +0000

Managing K8s Authorization like charm

Administrating complex authorization scenarios with fine-grained permissions is often difficult. In the Kubernetes ecosystem, the "Role-based-Access-Control" (RBAC) pattern is often used to do authorization for different users and groups in your cluster. RBAC is very powerful, but gets complex if you want to grant permissions on a namespace-basis.

At work I faced this challange and wanted to simplify the definiton, creation and removal of those rules. The result of this simplification is the "access-manager", a Kubernetes-Operator I built to manage RoleBinding and ClusterRoleBindings. These two objects are used to assign permissions defined in Roles and ClusterRoles to accounts (Users, Groups, ServiceAccounts). And this assignment is often the complex part.

Example

Let's start with an example, to make it more descriptive:

Given you have the following namespaces in Kubernetes:

ci-service
product-a
product-b
monitoring

And you have the following individuals or groups in your cluster:

Jane
John
Support (a group of user)
The ci-service solution

Jane is an administrator and needs access to all namespaces. John needs write-access to product-a and product-b. The support-group has to view (read-only) the two products and the monitoring namespace. As last requirement, the ServiceAccount of ci-service should be able to deploy new versions of the two products. For simplicity the Roles and ClusterRoles are already defined and the John and the CI should use the same role.

This scenario would end up in

one ClusterRoleBinding, where Jane is assigned to the cluster-admin role,
one RoleBinding in the two product namespaces, which assignes the User John and the ci-service ServiceAccount to manage the products,
one RoleBinding in the two product namespaces and the monitoring namespace for the support-group.

So six (Cluster-)RoleBindings are needed to achieve this. And the setup has to grow, if there would be a product-c namespace some day.

Let's get the operator into play and define the above:

apiVersion: access-manager.io/v1beta1
kind: RbacDefinition
metadata:
  name: my-definition
spec:
  namespaced:
    - namespaceSelector:
        matchLabels:
          management: 'true'
      bindings:
        - roleName: product-write-permission
          kind: ClusterRole
          subjects:
            - name: ci-service
              kind: ServiceAccount
            - name: john
              kind: User
    - namespaceSelector:
        matchLabels:
          support: 'true'
      bindings:
        - roleName: support-permission
          kind: ClusterRole
          subjects:
            - name: support
              kind: Group
  cluster:
    - name: jane-admin
      clusterRoleName: cluster-admin
      subjects:
        - name: jane
          kind: User

I introduced two different labels on namespaces: All namespaces labeled with management: true are eligible to be managed from John and through the ci-service. All namespaced which should be viewed from the support-group are labeled with support: true. If there would be a namespace-c some day, all you have to do is, to add the needed labels. The operator will do the rest for you. Changes to namespaces or these RbacDefinitions are automatically detected and the desired state is applied.

For more detailed informations for the definition and other features, please read the api-docs.

Conclusion

Role-based authorization in Kubernetes becomes more complex as the cluster grows and more different accounts getting access. With the "access-manager" it is possible to just define the Roles needed and the the assignment-rules to accounts. The creation, modification and removal of the concrete Bindings is fully managed and nothing you have to care about.

Found a typo?

If you've found a typo, a sentence that could be improved or anything else that should be updated on this blog post, you can access it through a git repository and make a pull request. Instead of posting a comment, please go directly to https://github.com/ckotzbauer/dev.to-posts and open a new pull request with your changes.

Cache-Reset with Webpack

Christian Kotzbauer — Sun, 03 May 2020 07:59:56 +0000

Originally published on January 22, 2017

There are several strategies to implement a caching mechanism. The common way with Webpack is, to change the file
name and add a content-based hash. The advantage of this is, that the file only needs to be reloaded if its content
changed. But the disadvantage is (e.g. for images) that all references in your source-code have to be modified in
order to match the different file names, but this seems to be solvable. But what happens, if you start generating some paths
through variables at runtime? So I considered to use a fairly old mechanism: Cache-Busting with a Query-Parameter.
To append this parameter to all the code references, I wrote a custom webpack-loader.

Usage

First, install the loader through npm:



npm install cache-bust-loader

Assuming, that the list of loaders in your webpack.config.js looks similar to this:



[
  { test: /\.css$/, loader: ExtractTextPlugin.extract({ loader: 'css-loader' }) },
  { test: /\.html$/, loader: 'raw-loader' },
  { test: /\.ts$/, loader: 'awesome-typescript-loader' },
];

Now, simply add the cache-bust-loader to each file-type where you reference other files which you want to be cache-busted:



const cacheBustLoader = `cache-bust-loader?name=bust&value=${bustValue}`;

[
  { test: /\.css$/, loader: ExtractTextPlugin.extract({ loader: `${cacheBustLoader}!css-loader` }) },
  { test: /\.html$/, loader: `${cacheBustLoader}!raw-loader` },
  { test: /\.ts$/, loader: `${cacheBustLoader}!awesome-typescript-loader` },
];

The loader has three parameters:

Parameter	Mandatory	Data type	Default value
name	True	String
value	False	String
types	False	String	eot;woff;woff2;svg;ttf;otf;jpg;jpeg;png;ico;gif;json

The name describes the name of the query parameter, the value the string which should change every build.
If the value is empty, no parameters are applied (e.g. in development mode). The types are file-types
which you want to be cache-busted. Split them with a semicolon.

To generate a short unique string for each build you can fill bustValue like this:



bustValue = require('randomstring').generate(5);

Result

Open your browser-network-tab:

Conclusion

This webpack-loader makes it easy to implement a basic cache-reset mechanism. All files matching the file-type have the query-parameter appended
and are reloaded if a new version of your frontend-project is deployed.

Found a typo?

Migrating from Durandal to Aurelia

Christian Kotzbauer — Sat, 02 May 2020 11:41:01 +0000

Originally published on June 15, 2016

If you have an existing Durandal application you maybe want to migrate this app to Aurelia. Typically you used
Knockout for data-binding. Because Aurelia brings its own data-binding language the usage of Knockout
is not necessary anymore. But probably especially this part of the migration requires the greatest effort,
because you have to modify much of your code or partially rewrite it. So let's split this effort as much as possible:

Here's a way how you can use Aurelia side-by-side with the Knockout technology and then migrate each view and
view-model step-by-step. You can use your old Knockout views and their backed JavaScript code with its observables
and subscriptions, as if you were still using Durandal.

First Steps

First, install the Aurelia plugin

jspm install aurelia-knockout

and register it during the startup of your app:

export function configure(aurelia) => {
    aurelia.use
        .standardConfiguration()
        .developmentLogging()
        .plugin("aurelia-knockout");

    aurelia.start().then(() => aurelia.setRoot());
}

The next step will be, to add the knockout custom attribute to each view which uses Knockout syntax:

<template>
  <div knockout>
    <button data-bind="click: changeVisibility">Change Visibility</button>
    <div data-bind="if: isVisible">
      <span data-bind="text: firstName"></span>
      <br />
      <span data-bind="text: lastName"></span>
    </div>
  </div>
</template>

Note: The element with the custom attribute has to wrap all code with Knockout syntax.

This attribute binds the HTML to the current BindingContext of Aurelia.

And that's it! With these small modifications you can use all Knockout bindings which are available.

Using Compositions

Durandal also provided a binding to compose views. Because this binding was implemented from Durandal and not
from Knockout you can not use this feature natively. But the aurelia-knockout plugin supports the composition
with all possible variants listed in the official Durandal docs:

<div data-bind="compose: 'path/to/view.html'"></div>
<div data-bind="compose: 'path/to/module'"></div>
<div data-bind="compose: { view: 'path/to/view.html' }"></div>
<div data-bind="compose: { model: 'path/to/module' }"></div>
<div data-bind="compose: { model: moduleInstance }"></div>
<div data-bind="compose: { view: 'path/to/view.html' model: 'path/to/module' }"></div>
<div data-bind="compose: { view: 'path/to/view.html' model: moduleInstance }"></div>
<div data-bind="compose: moduleInstance"></div>
<div data-bind="compose: moduleConstructorFunction"></div>

Set @bindable properties

To enhance the flexibility of your migration process, this plugin also supports the ability to set @bindable
variables in rewritten subordinated Aurelia views through the activationData. This offers the possibility to rewrite
single views in lower hierarchies without the need to do the same with their parent views.

Parent Knockout based view

Supposed that there is a parent view using Knockout technology which composes a child view like this:

<template>
  <div data-bind="compose: { model: 'path/to/submodule', activationData: data }"></div>
</template>

The appropriate data object would looks like this:

{
  price: ko.observable(5),
  productName: "Apples"
}

Child Aurelia based view

The child view and view-model uses Aurelia:

<template>
  Product:
  <span>${productName}</span>
  <br />
  Price:
  <span>${price}</span>
</template>

import { bindable } from 'aurelia-framework';
import { inject } from 'aurelia-dependency-injection';
import { KnockoutBindable } from 'aurelia-knockout';

@inject(KnockoutBindable)
export class ProductView {
  @bindable
  price;
  productName;

  knockoutBindable;

  constructor(knockoutBindable) {
    this.knockoutBindable = knockoutBindable;
  }

  activate(activationData) {
    this.knockoutBindable.applyBindableValues(activationData, this);
  }
}

This will set the value from activationData.price to this.price. this.productName however, is not
updated because it has no @bindable decorator and the variable from activationData is no Knockout
observable. To process non Knockout observables anyway you have to pass false as third parameter to the
applyBindableValues function. If the outer value changed (and is an observable) the corresponding inner
variable is updated too.

Subscriptions for Knockout observables which are created from this plugin internally will be disposed automatically
if the child view is unbound.

Conclusion

The migration to a new framework is often a big task depending on your application. But that does not mean that you have to implement it all at once. This plugin offers you a possibility to ship preliminary results during the transition phase of your application.