DEV Community: Mateo Tibaquirá

Migrating from Stylus/Pug to SASS

Mateo Tibaquirá — Fri, 02 Sep 2022 18:13:03 +0000

Hi Angular folks! here a late announcement of some packages released by Mynd that will help some projects in the transition to Angular 13+ due to the deprecation of Stylus.

@myndpm/stylus2scss

This CLI utility convert styl files to scss and also updates their related Angular Components metadata. It allows to spread the conversion in different GIT commits to keep track of the history of the converted files.

It also includes the sass-migration tool to complete the process without additional steps, and some other customizable options that can be checked in the README file: https://www.npmjs.com/package/@myndpm/stylus2scss

The conversion would be as simple as running this in your repo:

npx @myndpm/stylus2scss --git

@myndpm/pug2html

At Mynd we were using Pug since it was a fancy template engine that was quite aligned with Stylus, but after some years their tooling and support got quite behind and it was time to move to the default HTML templates.

This CLI utility convert pug content to html and also updates the Angular components metadata. It also possible to keep the GIT history or execute the process step by step with the provided --options documented in its README file: https://www.npmjs.com/package/@myndpm/pug2html

Also, running this utility would be as simple as:

npx @myndpm/pug2html --git

Feedback

Enjoy! and please report any issue at our GitHub repo: https://github.com/myndpm/open-source

Conditional Tasks in Dynamic Forms

Mateo Tibaquirá — Fri, 07 May 2021 14:11:09 +0000

TL;DR
We have support for conditional behaviors in @myndpm/dyn-forms documented at mynd.dev and we are able to provide them easily like the Controls, Validators, AsyncValidators, etc.

In complex forms use-cases, some controls directly depend on the value or status of some other form control. Then we implement custom behaviors, like hiding a field when another control has some value, or disabling it depending on a complex condition, etc.

To support this, we've added Matchers and Conditions, which can be provided just like the Validators and AsyncValidators as we saw in the previous chapter of this series. If you want to get an initial idea from the code, you can check this source file and this real use-case demo.

DynTreeNode

Each dynamic control has a composed Node service instance which holds the data of this point in the form hierarchy. It provides the API and the data to manipulate the form in a customized way when needed.

The node has the control Form Instance, the params object, some utility methods to query or select parent and child controls, manipulate the visibility, etc. We will use this node inside the Conditions, Matchers and any other custom Handlers.

Conditions

To match a special requirement, we need to define one or more conditions, so when all (AND) or one (OR) of them are fulfilled we run a particular task. The Condition Function type consists of:

interface DynControlConditionFn {
  (node: DynTreeNode): Observable<any>;
}

it streams a truthy value whenever the condition is fulfilled or not, for example, we could check if a specific control has the expected value:

(node: DynTreeNode) => {
  return node.query('specific.control').valueChanges.pipe(
    map(controlValue => controlValue === 'xValue'),
  );
}

we can join these conditions with the required operator (AND | OR) for our use-case, and then evaluate the action to execute in the specific Matcher.

Matchers

We define our requirement with the Matchers that we want to run when all or a single condition is satisfied:

match: [{
  matchers: ['DISABLE'], // one or more matchers
  when: [{
    // the library provides a DEFAULT condition handler
    // to process path, value and negation
    path: 'other.field',
    value: 'expectedValue'
  }]
}]

the DISABLE matcher is included in the library with ENABLE, SHOW, HIDE (display: none) and INVISIBLE (visibility: hidden).

One matcher consists of a function which performs a task in the form hierarchy; to do so, it receives the DynTreeNode instance:

interface DynControlMatcherFn {
  (args: {
    node: DynTreeNode;
    hasMatch: boolean;
    firstTime: boolean;
    results: any[];
  }): void;
}

So, for example the DISABLE matcher operates into the form control when the specified conditions are fulfilled (has match):

{
  id: 'DISABLE',
  fn: (): DynControlMatcherFn => {
    return ({ node , hasMatch }) => {
      hasMatch ? node.control.disable() : node.control.enable();
    }
  }
},

Advanced Stuff

This conditional processing enables us to do some additional logical operations, llike negate the result of one or all the conditions, so we are able to play with conditions upside down and have the simplest specification of our requirements.

Matcher Example

For example, if we want to run a Matcher for all the options of a SELECT except a few of them, OR without another condition, we can define that requirement with the few known values instead listing all the other values (which can be a long list), and negate the matcher input:

match: {
  matchers: ['MyMatcherID'],
  operator: 'OR', // the operator is AND by default
  when: [
    {
      path: 'selectorName',
      value: ['A', 'B', 'C'] // this will check if selectorName.value is IN this array
    },
    {
      path: 'other.control',
      value: 'anotherValue'
    },
  ],
  negate: true
}

the Matcher will receive hasMatch: true when the selector has a value NOT in the provided list.

Also note that you can provide your Matcher factories with a custom id like 'MyMatcherID' just like we will do with conditions in the following section.

Condition Factory

We can register Factories with an id and a fn as we do with Validators, and parametrize them in the Config Object:

export interface DynControlCondition {
  id: string;
  fn: (...args: any[]) => DynControlConditionFn;
}

Remember that DynControlConditionFn returns an Observable<boolean> so you can implement and provide your custom conditions like:

const conditions = [{
  id: 'MyConditionId',
  fn: (...args: any[]) => { // Factory
    return (node: DynTreeNode) => { // Condition
      return node.control.valueChanges.pipe(map(...));
    }
  }
}];

@NgModule({
  imports: [
    DynFormsModule.forFeature({ conditions });

Conditions Config

You can use your custom conditions in these ways:

// inline function
when: [
  (node: DynTreeNode) => {
    // manipulate the form via DynTreeNode
  }
]

// factory ID without arguments
when: [
  'MyConditionId',
]

// parametrized factory
when: [
  ['MyConditionId', args],
]

// or declarative inline config
when: [
  {
    condition: 'MyConditionId',
    path: 'other.control', // path is the only mandatory field in this format,
    param1: 'anyValue', // the whole object will be passed to your DynControlConditionFn
  },
]

in the last notation the whole config object is passed to the Factory, that's how the DEFAULT condition handler receives the path, value and negate config values.

Note: If no value is configured, the DEFAULT handler emits true everytime the configured path control value changes:

id: 'DEFAULT',
fn: ({ path, value, negate }): DynControlConditionFn => {
  return (node: DynTreeNode): Observable<boolean> => {
    if (value === undefined) {
      return node.query(path).valueChanges.pipe(mapTo(true));
    }
    ...
  }
}

Conclusion

We have covered most of the details of Matchers and Conditions, and how one or many conditions can be configured so when one or all of them are fulfilled, they trigger a matcher which can modify the state of the form hierarchy via the DynTreeNode API.

If you have an idea after this reading, or after using this library in an Angular App, please share it with us! :)

You can request features and join our discussions.

// PS. We are hiring!

Conditional Tasks in Dynamic Forms

Mateo Tibaquirá — Thu, 06 May 2021 17:32:27 +0000

TL;DR
We have support for conditional behaviors in @myndpm/dyn-forms documented at mynd.dev and we are able to provide them easily like the Controls, Validators, AsyncValidators, etc.

DynTreeNode

Conditions

To match a special requirement, we need to define one or more conditions, so when all (AND) or one (OR) of them are fulfilled we perform a particular action. The Condition Function type consists of:

interface DynControlConditionFn {
  (node: DynTreeNode): Observable<any>;
}

it streams a truthy value whenever the condition is fulfilled or not, for example, we could check if a specific control has the expected value:

(node: DynTreeNode) => {
  return node.query('specific.control').valueChanges.pipe(
    map(controlValue => controlValue === 'xValue'),
  );
}

we can join these conditions with the required operator (AND | OR) for our use-case, and then evaluate the action to execute in the specific Matcher.

Matchers

We define our requirement with the Matchers that we want to run when all or a single condition is satisfied:

match: [{
  matchers: ['DISABLE'], // one or more matchers
  when: [{
    // the library provides a DEFAULT condition handler
    // to process path, value and negation
    path: 'other.field',
    value: 'expectedValue'
  }]
}]

the DISABLE matcher is included in the library with ENABLE, SHOW, HIDE (display: none) and INVISIBLE (visibility: hidden).

One matcher consists of a function which performs a task in the form hierarchy; to do so, it receives the DynTreeNode instance:

interface DynControlMatcherFn {
  (args: {
    node: DynTreeNode;
    hasMatch: boolean;
    firstTime: boolean;
    results: any[];
  }): void;
}

So, for example the DISABLE matcher operates into the form control when the specified conditions are fulfilled (has match):

{
  id: 'DISABLE',
  fn: (): DynControlMatcherFn => {
    return ({ node , hasMatch }) => {
      hasMatch ? node.control.disable() : node.control.enable();
    }
  }
},

Advanced Stuff

This conditional processing enables us to do some additional logical operations, like negate the result of one or all the conditions, so we are able to play with conditions upside down and have the simplest specification of our requirements.

Matcher Example

match: {
  matchers: ['MyMatcherID'],
  operator: 'OR', // the operator is AND by default
  when: [
    {
      path: 'selectorName',
      value: ['A', 'B', 'C'] // this will check if selectorName.value is IN this array
    },
    {
      path: 'other.control',
      value: 'anotherValue'
    },
  ],
  negate: true
}

the Matcher will receive hasMatch: true when the selector has a value NOT in the provided list.

Also note that you can provide your Matcher factories with a custom id like 'MyMatcherID' just like we will do with conditions in the following section.

Condition Factory

We can register Factories with an id and a fn as we do with Validators, and parametrize them in the Config Object:

export interface DynControlCondition {
  id: string;
  fn: (...args: any[]) => DynControlConditionFn;
}

Remember that DynControlConditionFn returns an Observable<any> so you can implement and provide your custom conditions like:

const conditions = [{
  id: 'MyConditionId',
  fn: (...args: any[]) => { // Factory
    return (node: DynTreeNode) => { // Condition
      return node.control.valueChanges.pipe(map(...));
    }
  }
}];

@NgModule({
  imports: [
    DynFormsModule.forFeature({ conditions });

Conditions Config

You can use your custom conditions in these ways:

// inline function
when: [
  (node: DynTreeNode) => {
    // manipulate the form via DynTreeNode
  }
]

// factory ID without arguments
when: [
  'MyConditionId',
]

// parametrized factory
when: [
  ['MyConditionId', args],
]

// or declarative inline config
when: [
  {
    condition: 'MyConditionId',
    path: 'other.control', // path is the only mandatory field in this format,
    param1: 'anyValue', // the whole object will be passed to your DynControlConditionFn
  },
]

in the last notation the whole config object is passed to the Factory, that's how the DEFAULT condition handler receives the path, value and negate config values.

Note: If no value is configured, the DEFAULT handler emits true everytime the configured path control value changes:

id: 'DEFAULT',
fn: ({ path, value, negate }): DynControlConditionFn => {
  return (node: DynTreeNode): Observable<boolean> => {
    if (value === undefined) {
      return node.query(path).valueChanges.pipe(mapTo(true));
    }
    ...
  }
}

Conclusion

If you have an idea after this reading, or after using this library in an Angular App, please share it with us! :)

You can request features and join our discussions.

// PS. We are hiring!

Parametrized Validators in Dynamic Forms

Mateo Tibaquirá — Wed, 05 May 2021 13:41:01 +0000

TL;DR
We are building the documentation of @myndpm/dyn-forms at mynd.dev and we've added support for a variety of custom functions like Validators, AsyncValidators, Matchers, Conditions and more.

The next crucial part of any form is validation, aka Validators and AsyncValidators, and we took some time to study a nice way to implement them and we picked the most declarative one:

createMatConfig('INPUT', {
  name: 'quantity',
  validators: ['required', ['min', 1] ],
  asyncValidators: ['myAsyncValidator'],

Angular Validators

Angular provides default Validators that we're used to consume programatically in our Reactive Forms, some of them are Validator Functions (ValidatorFn) like Validators.required, and some others are Validator Factories ((args) => ValidatorFn) which builds a Validator based on a required parameter like Validators.minLength(4).

The definition of a Validator Function is:

(control: AbstractControl) => ValidationErrors | null

it receives the control to be validated, and returns null if its value is valid, or an error object of the form { [error: string]: any }

Validator Factories are high-order functions that builds a Validator Function according some input parameters:

function minLength(minLength: number): ValidatorFn {
  return (control: AbstractControl) => {
    return (control.value && control.value.length < minLength)
      ? { minLength: true } // invalid
      : null; // valid
  }
}

as you can see, this is a very nice way to parametrize our Functions, so we defined the provisioning of Validators (and all the other handlers) with an id and a factory fn:

export interface DynControlValidator {
  id: string;
  fn: (...args: any[]) => ValidatorFn;
}

The id will be the string that we will use in our Configuration Object. By default, @myndpm/dyn-forms provide the default Angular Validators with the same name as we know them: required, requiredTrue, email, pattern, minLength, maxLength, min and max.

The notation to use them in the Config Object is as follows:

// without parameters
validators: ['required'],

// with parameters as array
validators: ['required', ['min', 1] ],

// with parameters as object
validators: { required: null, minLength: 4 },

// with an inline ValidatorFn or ValidatorFn factory
validators: [myValidatorFn, myValidatorFactory(args)],

supporting these different notations is unexpensive and can be useful for different kind of systems or developer tastes.

Custom Validators

As mentioned, all we need is to provide our ValidatorFn Factory with an id and a fn. So we can easily provide them in our module with a code like this:

import { AbstractControl, ValidatorFn } from '@angular/forms';
import { DynFormsModule } from '@myndpm/dyn-forms';
import { DynControlValidator } from '@myndpm/dyn-forms/core';

const validators: DynControlValidator[] = [
  {
    id: 'email',
    fn: (): ValidatorFn => {
      return (control: AbstractControl) => {
        // implement my validator
        // to return { email: true } | null;
      }
    }
  }
];

@NgModule({
  imports: [
    DynFormsModule.forFeature({ validators, priority: 100 });

note the priority parameter to override the default validators (which weight is 0); we will play with priorities in a further article.

AsyncValidators

Providing async validators works in the same way. You provide your fn with an id and use them in the Config Object:

createMatConfig('INPUT', {
  name: 'quantity',
  validators: ['required'],
  asyncValidators: ['myAsyncValidatorId'],

and if you need to provide arguments to your AsyncValidator factory, you can use:

// single argument which can be an object
asyncValidators: [['myAsyncValidatorId', args]],
// your factory will receive fn(args)

// multiple arguments in array to be destructured
asyncValidators: [['myAsyncValidatorId', [arg1, arg2]]],
// your factory will receive fn(arg1, arg2)

Custom Handlers

With this notation we added support for multiple kinds of functions that we require in the Dynamic Forms: Validators and AsyncValidators as we just saw, Matchers and Conditions to manipulate the controls under some special requirements, and also ParamFns to inject functions to the parameters of the DynControls too.

We will be digging into the conditional executions in the next chapter.
In the meantime, what do you think of this notation?

// PS. We are hiring!

Parametrized Validators in Dynamic Forms

Mateo Tibaquirá — Mon, 03 May 2021 15:16:04 +0000

TL;DR
We are building the documentation of @myndpm/dyn-forms at mynd.dev and we've added support for a variety of custom functions like Validators, AsyncValidators, Matchers, Conditions and more.

The next crucial part of any form is validation, aka Validators and AsyncValidators, and we took some time to study a nice way to implement them and we picked the most declarative one:

createMatConfig('INPUT', {
  name: 'quantity',
  validators: ['required', ['min', 1] ],
  asyncValidators: ['myAsyncValidator'],

Angular Validators

The definition of a Validator Function is:

(control: AbstractControl) => ValidationErrors | null

it receives the control to be validated, and returns null if its value is valid, or an error object of the form { [error: string]: any }

Validator Factories are high-order functions that builds a Validator Function according some input parameters:

function minLength(minLength: number): ValidatorFn {
  return (control: AbstractControl) => {
    return (control.value && control.value.length < minLength)
      ? { minLength: true } // invalid
      : null; // valid
  }
}

as you can see, this is a very nice way to parametrize our Functions, so we defined the provisioning of Validators (and all the other handlers) with an id and a factory fn:

export interface DynControlValidator {
  id: string;
  fn: (...args: any[]) => ValidatorFn;
}

The notation to use them in the Config Object is as follows:

// without parameters
validators: ['required'],

// with parameters as array
validators: ['required', ['min', 1] ],

// with parameters as object
validators: { required: null, minLength: 4 },

// with an inline ValidatorFn or ValidatorFn factory
validators: [myValidatorFn, myValidatorFactory(args)],

supporting these different notations is unexpensive and can be useful for different kind of systems or developer tastes.

Custom Validators

You can provide inline functions to build a fast prototype, but to store a plain config somewhere, you need to provide your ValidatorFn Factory with an id and a fn in the respective module with a code like this:

import { AbstractControl, ValidatorFn } from '@angular/forms';
import { DynFormsModule } from '@myndpm/dyn-forms';
import { DynControlValidator } from '@myndpm/dyn-forms/core';

const validators: DynControlValidator[] = [
  {
    id: 'email',
    fn: (): ValidatorFn => {
      return (control: AbstractControl) => {
        // implement my validator
        // to return { email: true } | null;
      }
    }
  }
];

@NgModule({
  imports: [
    DynFormsModule.forFeature({ validators, priority: 100 });

note the priority parameter to override the default validators (which weight is 0); we will play with priorities in a further article.

AsyncValidators

Providing async validators works in the same way. You provide your fn with an id and use them in the Config Object:

createMatConfig('INPUT', {
  name: 'quantity',
  validators: ['required'],
  asyncValidators: ['myAsyncValidatorId'],

and if you need to provide arguments to your AsyncValidator factory, you can use:

// single argument which can be an object
asyncValidators: [['myAsyncValidatorId', args]],
// your factory will receive fn(args)

// multiple arguments in array to be destructured
asyncValidators: [['myAsyncValidatorId', [arg1, arg2]]],
// your factory will receive fn(arg1, arg2)

Custom Handlers

We will be digging into the conditional executions in the next chapter.
In the meantime, what do you think of this notation?

// PS. We are hiring!

A new approach to have Dynamic Forms in Angular

Mateo Tibaquirá — Thu, 15 Apr 2021 14:03:00 +0000

TL;DR
Go to Stackblitz and witness the power of @myndpm/dyn-forms, check its synthetic source code and join the GitHub Discussions to design the upcoming features based on our experiences with Angular Forms.

As in most companies, at Mynd we build forms, filters, tables and display views for different purposes. We handle a ton of entities and we have custom components in our Design System to satisfy our needs. In this complex scenario, avoid boilerplate is a must, and to speed up the development process and facilitate the implementation and maintenance of these views, we built some base libraries to abstract the requirements into configuration objects that enable us to easily modify a form, a filter, a table, without touching a view template (most of the times).

So the question is: can we implement a standard, flexible enough layer to do this job and be shared with the Angular Community?

A bit of History

This challenge has been addressed by many developers and companies in many ways, we even have an official documentation guide on this topic; some approaches ends up with a template processing different types of fields with a ngSwitch, others vary on the entrypoint component depending on the desired UI framework, or their config objects are not standardized and uses different field names for the same task on different controls. They are not completely generic, typed and/or extensible.

The ideal scenario is to have a strictly typed and serializable configuration object, so we are able store it in the state or the database without problems, as well as the ability to share some recipes with the community for common use-cases without complex functions involved, just a JSON object; there are a lot of good ideas out there, and we're in the process of discussing the best possible solutions for each topic.

Technically speaking, the challenge is to translate a Config Object (JSON) into a functional Form (FormGroup) being able to build any required nested structure, composing Control (inputs, selects, etc) into Containers to group them and customize the layout (cards, panels, etc).

What's New?

@myndpm/dyn-forms is not just a "dynamic" forms library providing you a finite set of controls, or limiting your creativity and possibilities in any way. This library aims to be a quite generic and lightweight layer on the top of Angular's Form Framework, allowing us to build, extend and maintain our forms from their metadata, giving us more time to focus our attention on the business-logic requirements, custom validations, etc.

Moreover, we keep the control of our model and the Angular Form, manipulating the supported methods of FormGroup, FormArray and FormControl, giving the responsibility of building the form hierarchy and its presentation to the library, but patching and listening any valueChange as we are used to.

Creating a DynForm

All we need is to import DynFormsModule to our NgModule and also provide the DynControls that we need in our form. As a demostrative implementation, we mocked DynFormsMaterialModule at @myndpm/dyn-forms/ui-material to enable you right now to see how it works with some basic components:

import {
  DynFormsMaterialModule
} from '@myndpm/dyn-forms/ui-material';

@NgModule({
  imports: [
    DynFormsMaterialModule.forFeature()

This package also provides a typed createMatConfig Factory Method that (hopefully) will facilitate the development experience while creating configuration objects, by supporting type-checks (with overloads for the different controls):

import { createMatConfig } from '@myndpm/dyn-forms/ui-material';

@Component(...) {
form = new FormGroup({});
mode = 'edit';
config = {
  controls: [
    createMatConfig('CARD', {
      name: 'billing',
      params: { title: 'Billing Address' },
      controls: [
        createMatConfig('INPUT', {
          name: 'firstName',
          validators: ['required'],
          params: { label: 'First Name' },
        }),
        createMatConfig('INPUT', {
          name: 'lastName',
          validators: ['required'],
          params: { label: 'Last Name' },
        }),
        createMatConfig('DIVIDER', {
          params: { invisible: true },
        }),
        ...

now you're ready to invoke the Dynamic Form in your template

<form [formGroup]="form">
  <dyn-form
    [config]="config"
    [form]="form"
    [mode]="mode"
  ></dyn-form>

  <button type="button" (click)="mode = 'display'">
    Switch to Display Mode
  </button>
</div>

and voilá!

Where the magic happens

The main feature is the ability to plug-in new Dynamic Form Controls, provide customized ones for some particular requirements, or integrate third-party components into our forms, with ease!

For this matter, Angular's InjectionTokens are the way to apply the Dependency Inversion Principle, so we do not rely on the controls provided by a single library anymore, but any NgModule (like DynFormsMaterialModule) can provide new controls via the DYN_CONTROL_TOKEN by registering the component to be loaded dynamically (DynControl) with an "ID" (INPUT, RADIO, SELECT, etc).

From there the Dynamic Form Registry can let the Factory know what component it should load for a given "ID"

@Injectable()
export class DynFormRegistry {
  constructor(
    @Inject(DYN_CONTROLS_TOKEN) controls: ControlProvider[]
  )

it's super hard to name these kind of "id" and "type" fields, so trying to keep the context clear, the ControlProvider interface consists of:

export interface InjectedControl {
  control: DynControlType;
  instance: DynInstanceType;
  component: Type<AbstractDynControl>;
}

the control identificator is the 'string' to reference the dynamic control from the Config Object
the instance is the type of AbstractControl that it will create in the form hierarchy (FormGroup, FormArray or FormControl), and
the component which should extend any of the Dynamic Control classes (DynFormGroup, DynFormArray, DynFormControl or DynFormContainer) implementing the simple contract explained here.

Configuration Object Typing

You can define your Form with an array of controls which can have some subcontrols; with this nested structure you can build any hierarchy to satisfy your needs (like in the example). This configuration unit is specified by the DynBaseConfig interface which follows a simple Tree structure:

export interface DynBaseConfig<TMode, TParams> {
  name?: string;
  controls?: DynBaseConfig<TMode>[];
  modes?: DynControlModes<TMode>;
}

The form also supports different "modes". Modes are partial overrides that we can apply to the main Control Configuration depending on a particular situation. In the simple-form demo we show an example of this: a display mode where we define a readonly: true parameter to be passed to all the dynamic controls, and they react changing their layout or styles. These "modes" are just a custom string, so the configuration is open to any kind of mode that you'd like to define.

In the DynFormConfig you can specify the global override for each mode:

const config: DynFormConfig<'edit'|'display'> = {
  modes: {
    display: {
      params: { readonly: true }

and you can also override the configuration of a single control for a given a mode, like this RADIO button being changed to an INPUT control when we switch the form to display mode:

createMatConfig('RADIO', {
  name: 'account',
  params: { label: 'Create Account', color: 'primary' },
  modes: {
    display: {
      control: 'INPUT',
      params: { color: 'accent' },

In this case, the control will be overriden but the params will be merged and we will have the original label in the display mode.

Feedback WANTED

With this brief introduction to this powerful library, we hope that you join its design/development efforts by sharing your experience/ideas/point of view in the GitHub Discussions opened for the upcoming features, creating Pull Request extending or adding new Material/TaigaUI/any controls, or reporting Issues that you find.

There are some challenges to be addressed, like a standard way to handle the Validations and show the respective Error message; handle the visibility of a control depending on some conditions; these topics have opened discussions to collect ideas and figure out a solution.

We might write more articles explaining the internals to analyze and improve the chosen architecture.

Without further ado, enjoy it!

// PS. We are hiring!

A new approach to have Dynamic Forms in Angular

Mateo Tibaquirá — Mon, 05 Apr 2021 19:11:00 +0000

TL;DR
Go to Stackblitz and witness the power of @myndpm/dyn-forms, check its synthetic source code and join the GitHub Discussions to design the upcoming features based on our experiences with Angular Forms.

So the question is: can we implement a standard, flexible enough layer to do this job and be shared with the Angular Community?

A bit of History

What's New?

Creating a DynForm



import {
  DynFormsMaterialModule
} from '@myndpm/dyn-forms/ui-material';

@NgModule({
  imports: [
    DynFormsMaterialModule.forFeature()



import { createMatConfig } from '@myndpm/dyn-forms/ui-material';

@Component(...) {
form = new FormGroup({});
mode = 'edit';
config = {
  controls: [
    createMatConfig('CARD', {
      name: 'billing',
      params: { title: 'Billing Address' },
      controls: [
        createMatConfig('INPUT', {
          name: 'firstName',
          validators: ['required'],
          params: { label: 'First Name' },
        }),
        createMatConfig('INPUT', {
          name: 'lastName',
          validators: ['required'],
          params: { label: 'Last Name' },
        }),
        createMatConfig('DIVIDER', {
          params: { invisible: true },
        }),
        ...

now you're ready to invoke the Dynamic Form in your template



<form [formGroup]="form">
  <dyn-form
    [config]="config"
    [form]="form"
    [mode]="mode"
  ></dyn-form>

  <button type="button" (click)="mode = 'display'">
    Switch to Display Mode
  </button>
</div>

and voilá!

Where the magic happens

The main feature is the ability to plug-in new Dynamic Form Controls, provide customized ones for some particular requirements, or integrate third-party components into our forms, with ease!

From there the Dynamic Form Registry can let the Factory know what component it should load for a given "ID"



@Injectable()
export class DynFormRegistry {
  constructor(
    @Inject(DYN_CONTROLS_TOKEN) controls: ControlProvider[]
  )

it's super hard to name these kind of "id" and "type" fields, so trying to keep the context clear, the ControlProvider interface consists of:



export interface InjectedControl {
  control: DynControlType;
  instance: DynInstanceType;
  component: Type<AbstractDynControl>;
}

the control identificator is the 'string' to reference the dynamic control from the Config Object
the instance is the type of AbstractControl that it will create in the form hierarchy (FormGroup, FormArray or FormControl), and
the component which should extend any of the Dynamic Control classes (DynFormGroup, DynFormArray, DynFormControl or DynFormContainer) implementing the simple contract explained here.

Configuration Object Typing



export interface DynBaseConfig<TMode, TParams> {
  name?: string;
  controls?: DynBaseConfig<TMode>[];
  modes?: DynControlModes<TMode>;
}

In the DynFormConfig you can specify the global override for each mode:



const config: DynFormConfig<'edit'|'display'> = {
  modes: {
    display: {
      params: { readonly: true }

and you can also override the configuration of a single control for a given a mode, like this RADIO button being changed to an INPUT control when we switch the form to display mode:



createMatConfig('RADIO', {
  name: 'account',
  params: { label: 'Create Account', color: 'primary' },
  modes: {
    display: {
      control: 'INPUT',
      params: { color: 'accent' },

In this case, the control will be overriden but the params will be merged and we will have the original label in the display mode.

Feedback WANTED

We might write more articles explaining the internals to analyze and improve the chosen architecture.

Without further ado, enjoy it!

// PS. We are hiring!

A word of npx-advice

Mateo Tibaquirá — Sun, 07 Mar 2021 00:19:36 +0000

Node.js dependency managers like NPM and YARN does support the easy execution of starter-kit-packages to bootstrap or create the boilerplate of many kinds of projects, like create-npm which bootstraps a package by running:

npm create npm github-user/my-pkg

yarn create npm github-user/my-pkg

These packages starts with create-* and the create command forwards any <args> to the binary, so

yarn create nx-plugin my-workspace --pluginName my-plugin

is equivalent to

yarn global add create-nx-plugin
create-nx-plugin my-workspace --pluginName my-plugin

I do usually use create-nx-workspace and recently I wanted to re-take my experiments with Nx so I created a new workspace with npx create-nx-workspace --preset angular and I got an outdated setup.

I was wondering if the package was not being maintained properly (which was very unlikely) but then I realized that I installed it globally many months ago for some reason, and I didn't update it since then...

Best Practice

Try to not install packages globally which gets easily outdated, and please never install a starter package globally. Just run the latest version with npm create or yarn create or npx.

We have to get used to run the local dependencies via npm run command or yarn command instead having global dependencies that can give us headaches after some time.