DEV Community: Konstantinos Zagoris

Lazy-load a component in Angular without routing

Konstantinos Zagoris — Sun, 28 Nov 2021 14:10:36 +0000

One of the most desirable features in Angular is to lazy load a component the time you need it. This approach provides many benefits to the loading speed of the application as it downloads only the required components when you need them. Furthermore, it is a very straightforward procedure through routing that is documented in the Angular docs. However, what if you do not want to use the router, or you want to lazy load a component programmatically through your code?

Scaffolding a Sample Form App

To highlight that scenario, let's create a minimal angular web app without routing with a button that shows a form when we click it. We will use, also the Angular Material to have a simple and beautiful design.

The application comprises two different components: the AppComponent and the LazyFormComponent.
The AppComponent shows the main app, which contains a button that shows the LazyFormComponent when pressed.

@Component({
  selector: "app-root",
  template: `
    <div style="text-align:center;margin-top: 100px;" class="content">
      <h1>Welcome to lazy loading a Component</h1>
      <button mat-raised-button color="primary" (click)="showForm = true">
        Load component form!
      </button>
      <app-lazy-form *ngIf="showForm"></app-lazy-form>
    </div>
  `,
  styles: [],
})
export class AppComponent {
  public showForm = false;
}

The LazyFormComponent defines a simple reactive form with two inputs, a name and email, and a submit button:

@Component({
  selector: "app-lazy-form",
  template: `
    <form
      [formGroup]="simpleForm"
      style="margin:50px;"
      fxLayout="column"
      fxLayoutGap="20px"
      fxLayoutAlign="space-between center"
      (submit)="submitForm()"
    >
      <mat-form-field appearance="fill">
        <mat-label>Enter your Name</mat-label>
        <input matInput placeholder="John" formControlName="name" required />
        <mat-error *ngIf="name?.invalid">{{ getNameErrorMessage() }}</mat-error>
      </mat-form-field>
      <mat-form-field appearance="fill">
        <mat-label>Enter your email</mat-label>
        <input
          matInput
          placeholder="john@example.com"
          formControlName="email"
          required
        />
        <mat-error *ngIf="email?.invalid">{{
          getEmailErrorMessage()
        }}</mat-error>
      </mat-form-field>
      <button type="submit" mat-raised-button color="accent">Submit</button>
    </form>
  `,
  styles: [],
})
export class LazyFormComponent implements OnInit {
  simpleForm = new FormGroup({
    email: new FormControl("", [Validators.required, Validators.email]),
    name: new FormControl("", [Validators.required]),
  });

  get name() {
    return this.simpleForm.get("name");
  }

  get email() {
    return this.simpleForm.get("email");
  }

  constructor() {}

  ngOnInit(): void {}

  getNameErrorMessage() {
    if (this.name?.hasError("required")) {
      return "You must enter a value";
    }

    return this.email?.hasError("email") ? "Not a valid email" : "";
  }

  getEmailErrorMessage() {
    if (this.email?.hasError("required")) {
      return "You must enter a value";
    }

    return this.email?.hasError("email") ? "Not a valid email" : "";
  }

  submitForm() {
    if (this.email?.invalid || this.name?.invalid) return;
    alert("Form submitted successfully");
  }
}

Finally, the AppModule glue everything together and imports the corresponding modules mainly for the Angular Material:

@NgModule({
  declarations: [AppComponent, LazyFormComponent],
  imports: [
    BrowserModule,
    MatButtonModule,
    BrowserAnimationsModule,
    ReactiveFormsModule,
    MatFormFieldModule,
    MatInputModule,
    FlexLayoutModule,
  ],
  providers: [],
  bootstrap: [AppComponent],
})
export class AppModule {}

The final result is:

Lazy Loading a Simple Component

What if we want to load the LazyFormComponent and their related material modules when we press the button and not the whole app?

We cannot use the route syntax to lazy load our component. Moreover, if we try to remove the LazyFormComponent from AppModule, the app fails because the Ivy compiler cannot find the required Angular Material modules needed for the form. This error leads to one of the critical aspects of Angular: The NgModule is the smallest reusable unit in the Angular architecture and not the Component, and it defines the component's dependencies.

There is a proposal to move many of these configurations to the component itself, making the use of NgModule optional. A very welcoming change that will simplify the mental model which programmers have on each angular application. But until that time, we need to create a new module for our LazyFormComponent, which defines its dependencies.

For a NgModule with one component, defining it in the same file with the component for simplicity is preferable.

So, the steps to display our lazy component is:

define where we want to load our component in the template with the ng-template tag,
define its view query through ViewChild decorator, which gives us access to the DOM and defines the container to which the component will be added,
finally, dynamic import the component and add it to the container

The AppComponent has transformed now as:

import {
  Component,
  ComponentFactoryResolver,
  ViewChild,
  ViewContainerRef,
} from "@angular/core";

@Component({
  selector: "app-root",
  template: `
    <div style="text-align:center;margin-top: 100px;" class="content">
      <h1>Welcome to lazy loading a Component</h1>
      <button mat-raised-button color="primary" (click)="loadForm()">
        Load component form!
      </button>
      <ng-template #formComponent></ng-template>
    </div>
  `,
  styles: [],
})
export class AppComponent {
  @ViewChild("formComponent", { read: ViewContainerRef })
  formComponent!: ViewContainerRef;

  constructor(private componentFactoryResolver: ComponentFactoryResolver) {}

  async loadForm() {
    const { LazyFormComponent } = await import("./lazy-form.component");
    const componentFactory =
      this.componentFactoryResolver.resolveComponentFactory(LazyFormComponent);
    this.formComponent.clear();
    this.formComponent.createComponent(componentFactory);
  }
}

For Angular 13

In Angular 13, a new API exists that nullifies the need for ComponentFactoryResolver. Instead, Ivy creates the component in ViewContainerRef without creating an associated factory. Therefore the code in loadForm() is simplified to:

export class AppComponent {
  @ViewChild("formComponent", { read: ViewContainerRef })
  formComponent!: ViewContainerRef;

  constructor() {}

  async loadForm() {
    const { LazyFormComponent } = await import("./lazy-form.component");
    this.formComponent.clear();
    this.formComponent.createComponent(LazyFormComponent);
  }
}

Finally, we added the LazyFormModule class:

@NgModule({
  declarations: [LazyFormComponent],
  imports: [
    ReactiveFormsModule,
    MatFormFieldModule,
    MatInputModule,
    BrowserAnimationsModule,
    FlexLayoutModule,
    MatButtonModule,
  ],
  providers: [],
  bootstrap: [LazyFormComponent],
})
export class LazyFormModule {}

Everything seems to work fine:

Lazy loading a complex component

The above approach works for the simplest components, which do not depend on other services or components. But, If the component has a dependency, for example, a service, then the above approach will fail on runtime.

Let's say that we have a BackendService for our form submission form:

import { Injectable } from '@angular/core';

@Injectable()
export class BackendService {

    constructor() { }

    submitForm() {
        console.log("Form Submitted")
    }
}

Moreover, this service needs to be injected in the LazyFormComponent:

constructor(private backendService: BackendService) {}

  submitForm() {
    if (this.email?.invalid || this.name?.invalid) return;
    this.backendService.submitForm();
    alert("Form submitted successfully");
  }

But, when we try to lazy load the above component during runtime, it fails spectacularly:

Therefore, to make angular understand the need to load BackendService, the new steps are:

lazy load the module,
compile it to notify Angular about its dependencies,
finally, through the compiled module, we access the component and then add it to the container.

To access the component through the compiled module, we implement a helper function in the NgModule:

export class LazyFormModule {
  constructor(private componentFactoryResolver: ComponentFactoryResolver) {}

  getComponent() {
    return this.componentFactoryResolver.resolveComponentFactory(
      LazyFormComponent
    );
  }
}

Therefore the code for lazy loading the LazyFormComponent on loadForm() function transforms to:

constructor(private compiler: Compiler, private injector: Injector) {}

  async loadForm() {
    const { LazyFormModule } = await import("./lazy-form.component");
    const moduleFactory = await this.compiler.compileModuleAsync(
      LazyFormModule
    );
    const moduleRef = moduleFactory.create(this.injector);
    const componentFactory = moduleRef.instance.getComponent();
    this.formComponent.clear();
    this.formComponent.createComponent(componentFactory, {ngModuleRef: moduleRef});
  }

For Angular 13

Again, Angular 13 has simplified the above API. So now, the NgModule for the LazyFormComponent does not require injecting ComponentFactoryResolver. Therefore we only return the component:

export class LazyFormModule {
  constructor(private componentFactoryResolver: ComponentFactoryResolver) {}

  getComponent() {
    return LazyFormComponent
  }
}

Furthermore, we do not need to inject the Compiler service because the compilation occurs implicitly with Ivy. So, instead of compiling the module, we only get the reference to it with the createNgModuleRef function:

constructor(private injector: Injector) {}

  async loadForm() {
    const { LazyFormModule } = await import("./lazy-form.component");
    const moduleRef = createNgModuleRef(LazyFormModule, this.injector)
    const lazyFormComponent = moduleRef.instance.getComponent();
    this.formComponent.clear();
    this.formComponent.createComponent(lazyFormComponent, {ngModuleRef: moduleRef});
  }

Passing values and listening events

What if we want to pass some values or listen to some events from our lazy loading component? We cannot use the familiar syntax for a defined component in a template. Instead of that, we can access them programmatically.

For example, we want to change the text of the submit button on LazyFormComponent, and we want to be informed when the form is submitted. We add the required attributes, an Input() attribute for the prop buttonTitle and an Output() for the formSubmitted event:

export class LazyFormComponent implements OnInit {
  @Input()
  buttonTitle: string = "Submit";

  @Output() formSubmitted = new EventEmitter();

  submitForm() {
    if (this.email?.invalid || this.name?.invalid) return;
    this.backendService.submitForm();
    this.formSubmitted.emit();
    alert("Form submitted successfully");
  }
}

The createComponent function returns an instance of the component which we can set the props and listen to the events through their observables:

formSubmittedSubscription = new Subscription();

 async loadForm() {
    const { LazyFormModule } = await import("./lazy-form.component");
    const moduleFactory = await this.compiler.compileModuleAsync(
      LazyFormModule
    );
    const moduleRef = moduleFactory.create(this.injector);
    const componentFactory = moduleRef.instance.getComponent();
    this.formComponent.clear();
    const { instance } = this.formComponent.createComponent(componentFactory, {ngModuleRef: moduleRef});
    instance.buttonTitle = "Contact Us";
    this.formSubmittedSubscription = instance.formSubmitted.subscribe(() =>
      console.log("The Form Submit Event is captured!")
    );
  }

    ngOnDestroy(): void {
        this.formSubmittedSubscription.unsubscribe();
    }

You can check the complete sample solution in the GitHub repository here:

wittyprogramming / lazy-load-component-angular

Lazy load a component in Angular 12 without a router

Lazy-load a component in Angular without routing

One of the most seeking features in Angular is to lazy load a component when you need it. It is a very straightforward procedure through routing that is well documented. But, what if you do not want to use the router or you want to lazy load a component programmatically through your code?

Code for the following article: https://www.wittyprogramming.dev/articles/lazy-load-component-angular-without-routing/

View on GitHub

Or the Angular 13 version:

wittyprogramming / lazy-load-component-angular13

Lazy load a component in Angular 13 without a router

Lazy-load a component in Angular 13 without routing

One of the most seeking features in Angular 13 is to lazy load a component when you need it. It is a very straightforward procedure through routing that is well documented. But, what if you do not want to use the router or you want to lazy load a component programmatically through your code?

Code for the following article: https://www.wittyprogramming.dev/articles/lazy-load-component-angular-without-routing/

View on GitHub

Code-splitting and lazy-load components have their uses in modern web development, and I think with the changes in Angular 13, it has been simplified a lot.

Cross-component Communication Patterns in AlpineJs

Konstantinos Zagoris — Tue, 23 Mar 2021 19:44:24 +0000

One of the most frequent requirements when writing AlpineJs components is the communication between them. There are various strategies for how to tackle this problem. This article describes the four most common patterns that help pass information between different Alpinejs components.

As a simple example of the presenting patterns, we will create a snackbar component from the material design guidelines. Snackbars are concise, informative messages about some event or the output of a process.

Let's create the snackbar HTML structure and a button that initiates the message.

<body>
    <h1>Material Snackbar Example using Alpine.Js</h1>
    <button class="button">Show Snackbar</button>
    <h2>Click on the above button to see snackbar message</h2>
    <div class="alpine-snackbar-wrapper">
        <div class="alpine-snackbar-content">Sample Text</div>
    </div>
</body>

Next, we add the styles to mimic the material designs.

 body {
        font-family: 'Roboto', sans-serif;
}

.alpine-snackbar-wrapper {
    min-width: 344px;
    max-width: 672px;
    min-height: 48px;
    background-color: #2196F3;
    color: #fff;
    text-align: center;
    margin: auto 8px;
    display: flex;
    align-items: center;
    padding: 0;
    border-radius: 4px;
    position: fixed;
    right: 1%;
    z-index: 1;
    bottom: 30px;
    box-shadow: 0 3px 5px -1px rgba(0, 0, 0, .2), 0 6px 10px 0 rgba(0, 0, 0, .14), 0 1px 18px 0 rgba(0, 0, 0, .12);
}

.alpine-snackbar-content {
    flex-grow: 1;
    font-size: 0.875em;
    font-weight: 400;
    padding: 14px 16px;
}

.button {
    border: none;
    padding: 14px 16px;
    border-radius: 4px;
    font-size: 1em;
    background-color: #2196F3;
    color: white;
    cursor: pointer;
}

The end result is:

The main goal is to click the button and display the snackbar for a specific time with a custom message. Let's start describing the strategies to achieve it using the AlpineJs framework.

Custom Javascript Event

One apparent approach is to use the javascript standard of dispatching and consuming javascript events on the window object.

This approach's main advantage is the framework-agnostic aspect that may communicate with your AlpineJs components from everywhere in your app. Following the custom events documentation, when the button is clicked, a CustomEvent is created and then dispatched carrying the custom message.

You may check out the source and the result:

The HTML button code is:

<button onclick="showAlpineSnackbar()" class="button">Show Snackbar</button>

Then, we write the showAlpineSnackbar() javascript function in which the CustomEvent is created and dispatched:

function showAlpineSnackbar() {
    let event = new CustomEvent("alpine-snackbar-showMessage", {
        detail: {
            message: "Hello from outside of the component"
        }
    });
    window.dispatchEvent(event);
}

We created a CustomEvent object that defined the event name that we want to dispatch (alpine-snackbar-showMessage) and the information that the event carries (custom message).

The next step involves the creation of the AlpineJs snackbar component.

function alpineSnackbar() {
    return {
        show: false,
        message: null,
        init() {
            window.addEventListener("alpine-snackbar-showMessage", (event) => {
                this.showMessage(event.detail.message);
            });
        },
        showMessage(msg) {
            this.message = msg;
            this.show = true;
            window.setTimeout(() => {
                this.show = false;
                this.message = null;
            }, 2000);
        }
    }
}

We defined a component scope with two reactive variables:

show that sets the snackbar visibility and
message that defines the displaying custom message

and two functions:

init() and
showMessage(msg)

In the init() function executed during the component initialization stage, we create the listener for the custom event. When the event fires, we call the showMessage function with the custom message as an argument, taken from the detail object.

The showMessage function initially sets the custom message and displays the snackbar by setting the show variable as true. Then, we place a timeout function that runs after two seconds and resets the snackbar's state and hides it.

We chose to extract data and behavior into a function, which gives us breathing room for coding. The final step involves wiring up our component to the HTML:

<div x-data="alpineSnackbar()" x-init="init()" x-show.transition="show" class="alpine-snackbar-wrapper">
        <div class="alpine-snackbar-content" x-text="message"></div>
    </div>

The `dispatch` magic attribute

Another similar approach to custom events is by using the AlpineJs native $dispatch magic attribute. A magic attribute in AlpineJs is a user-defined attribute that implements a helpful operation. There many magic helpers native in AlpineJs or by importing additional packages. One of the native magic attributes is the $dispatch, a shortcut for creating a javascript custom event internally and fire up with a dispatchEvent.

The full snackbar example using the $dispatch magic helper is:

Therefore, by using the $dispatch magic attribute, we drop the function that creates the CustomEvent:

<button x-data @click="$dispatch('alpine-snackbar-show-message', {
        message: 'Hello from outside of the component'
    })" class="button">Show Snackbar</button>

Please note that we utilized the x-data to create an Alpinejs component to use the magic attribute. The $dispatch syntax is straightforward. The first argument corresponds to the CustomEvent name, and the second is the payload that attaches to the event.

The snackbar AlpineJs component that consumes the $dispatch event is transformed:

 <div x-data="alpineSnackbar()" @alpine-snackbar-show-message.window="showMessage($event.detail.message)"
    x-show.transition="show" class="alpine-snackbar-wrapper">
    <div class="alpine-snackbar-content" x-text="message"></div>
</div>

The previously written init() function, executed during the initialization of the AlpineJs component on x-init attribute, is replaced with the equivalent x-on attribute (or its shorthand syntax @). This syntax attaches an event listener to the element it is declared. Therefore, we used the CustomEvent name to catch the event and execute the showMessage(msg) function with the corresponding custom message accessed by the $event object.

You should consider the way that event propagates when you are using the $dispatch. If you need to capture events from elements not under the same node, you need to use the .window modifier. This modifier installs the listener on the global window object instead of the DOM node on which it is declared.

The `component` magic helper

Another approach to cross-component communication is using the $component from AlpineJs Magic Helpers, a collection of magic properties and helper functions. The installation is simple enough, add the following script tag before the AlpineJs tag.

<script src="https://cdn.jsdelivr.net/gh/alpine-collective/alpine-magic-helpers@0.5.x/dist/component.min.js"></script>
<script src="https://cdn.jsdelivr.net/gh/alpinejs/alpine@v2.x.x/dist/alpine.min.js"></script>

The $component gives access to other AlpineJs components. To achieve this, you provide a unique id for the component you want to access using the x-id attribute.

<div x-id="alpine-snack-bar"
     x-data="{ show : false, message: null }"
     x-show="show"
     class="alpine-snackbar-wrapper">
<div class="alpine-snackbar-content"
     x-text="message"></div>
</div>

Initially, we gave our snackbar component an id (alpine-snack-bar) and defined the two variables that we need. The show and message in x-data control the snackbar component's visibility and content, respectively.

Then, in the button we write a function inside the buttonShowSnackbar component that display the snackbar with the appropriate message and hides after two seconds. The HTML code is:

<button x-data="buttonShowSnackbar()"
        @click="showAlpineSnackbar('alpine-snack-bar')"
        class="button">Show
        Snackbar</button>

The buttonShowSnackbar component:

function buttonShowSnackbar() {
    return {
        showAlpineSnackbar(id) {
            this.$component(id).message = "Hello from another component using the $component";
            this.$component(id).show = true;
            setTimeout(() => {
                this.$component(id).show = false;
                this.$component(id).message = null;
            }, 2000)
        }
    }
}

We need to define the showAlpineSnackbar function inside an AlpineJs component to access the $component magic helper.

You can check the full example:

Having a global state by using the `spruce` library

Finally, another cross-communication pattern between AlpineJs components is by using a global state. For AlpineJs, there is spruce, an excellent global state management library from Ryan Chandler.

The installation is more or less the same. Add the spruce library script tag before the AlpineJs tag.

<script src="https://cdn.jsdelivr.net/npm/@ryangjchandler/spruce@2.x.x/dist/spruce.umd.js"
        defer></script>
<script src="https://cdn.jsdelivr.net/gh/alpinejs/alpine@v2.x.x/dist/alpine.min.js"
        defer></script>

The approach is very similar to the $component pattern. The only difference is that we manipulate the global state instead of a specific component state. Initially, we initialize our global state:

Spruce.store("snackbar", {
    message: null,
    show: false
});

We create a store called snackbar with two state variables, the message to be shown and the show that controls the snackbar visibility.

The HTML part of the buttonShowAlpineSnackbar() component is exactly the same as before:

<button x-data="buttonShowAlpineSnackbar()" @click="showMessage('A message from spruce')" class="button">Show Snackbar</button>

The difference is that the showMessage(msg) function manipulates the snackbar store state:

function buttonShowAlpineSnackbar() {
    return {
        showMessage(msg) {
            this.$store.snackbar.message = msg;
            this.$store.snackbar.show = true;
            window.setTimeout(() => {
                this.$store.snackbar.show = false;
                this.$store.snackbar.message = null;
            }, 2000);
        }
    }
}

The snackbar component is similar to the previous example, except that the snackbar store state controls the global state's visibility and message content.

<div x-data x-show.transition="$store.snackbar.show" class="alpine-snackbar-wrapper">
  <div class="alpine-snackbar-content" x-text="$store.snackbar.message"></div>
</div>

You can check the full example:

Conclusions

I presented four different approaches for cross-component communication. Although you can achieve the same outcome with every one of the above patterns, I think each one is better under a specific requirement. For example, the custom event javascript pattern is best suited for passing information between AlpineJs components and vanilla javascript code (or maybe another framework). Otherwise, the $dispatch magic attribute is more appropriate as it reduces the CustomEvent's boilerplate code. When you want to manipulate a specific component, the $component magic helper is most suitable as it gives you direct access to it. Finally, the spruce library is better suitable for apps that need global state.

Developing AlpineJs Apps Similar to Vue's Composition API

Konstantinos Zagoris — Sun, 14 Mar 2021 07:27:00 +0000

Vue's primary motivation behind Composition API's introduction was a cost-free mechanism for reusing logic between multiple components or apps. This idea is based on Functional Composition for programming, and its simplest form is about to produce a function by combining multiple other functions.

This technique is effortless to apply in AlpineJs using a combination of x-data and x-init attributes. First of all, if you never heard of this framework before, check out my introduction AlpineJs article:

Introducing AlpineJs. The Ideal jQuery Replacement

Konstantinos Zagoris ・ Feb 8 ・ 5 min read

#javascript #html #webdev #beginners

Architecture

Let's have as a base example the Netlify Contact Form described in the previous article:

Developing a Netlify Contact Form using Alpine.js

Konstantinos Zagoris ・ Mar 7 ・ 5 min read

#javascript #html #webdev #netlify

We will reshape the code to separate logic into different modules. The following figure depicts the new architecture:

We separate the code into three modules. One module will validate the form input utilizing another module that contains input validators, and an additional module will take care of the form backend submission.

Validators Module

Let's briefly explain the depicted modules. The most simple module is the validators. It contains functions that validate if input value follows a corresponding rule. It includes four self-explanatory validators (isEmail, isRequired, hasMinLength and hasMaxLength) and the code is:

export function isEmail(value) {
  return new RegExp("^\\S+@\\S+[\\.][0-9a-z]+$").test(
    String(value).toLowerCase()
  );
}

export function isRequired(value) {
    return value !== null && value !== undefined && value.length > 0;
}

export function hasMinLength(value, length) {
  return String(value).length >= length;
}

export function hasMaxLength(value, length) {
  return String(value).length <= length;
}

netlifySubmission Module

The netlifySubmission module handles the backend submission to the netlify service. It exposes a function named submitToNetlify that takes one argument, the form element intended to submit.

The code is taken from the previous article, modified for our module:

export function netlifySubmission() {
  return {
    submitToNetlify(formElement) {
      let body = new URLSearchParams(new FormData(formElement)).toString();
      return fetch("/", {
        method: "POST",
        headers: {
          "Content-Type": "application/x-www-form-urlencoded",
        },
        body: body,
      })
        .then((response) => {
          if (response.ok) {
            formElement.reset();
            alert("Thank you for your message!");
          } else {
            throw new Error(`Something went wrong: ${response.statusText}`);
          }
        })
        .catch((error) => console.error(error));
    },
  };
}

formValidator Module

The formValidator module carries out the main work. It has six responsive data attributes that correspond to name, email, and comment input components that compose the submit form. The dirty boolean variables are needed to determine when a user has lost focus from the corresponding input component. It is used to prevent the error messages to appear before the user attempts to enter a value. It is used in the HTML like this:

<p>
        <label
          >Full Name: <input x-model="name" x-on:blur="nameDirty = true" type="text" name="name"
        /></label>
      </p>
      <p x-show.transition="!isNameValid() && nameDirty" style="color: red" x-cloak>
        Please fill out your full name.
      </p>

And it produces the following behavior:

The full code for the formValidator module is:

import {
  isEmail,
  hasMaxLength,
  hasMinLength,
  isRequired,
} from "./validators.mjs";

export function formValidator() {
  let submitBackend;
  return {
    name: null,
    nameDirty: false,
    email: null,
    emailDirty: false,
    comments: null,
    commentsDirty: false,
    isNameValid(maxLength) {
      return (
        this.nameDirty &&
        isRequired(this.name) &&
        (maxLength ? hasMaxLength(this.name, maxLength) : true)
      );
    },
    isEmailValid() {
      return this.emailDirty && isEmail(this.email);
    },
    isCommentsValid(minLength) {
      return (
        this.commentsDirty &&
        isRequired(this.comments) &&
        (minLength ? hasMinLength(this.comments, minLength) : true)
      );
    },
    isFormValid() {
      return (
        this.isNameValid() && this.isEmailValid() && this.isCommentsValid()
      );
    },
    submitForm() {
      this.nameDirty = true;
      this.emailDirty = true;
      this.commentsDirty = true;
      if (!this.isFormValid()) return;
      submitBackend(this.$el);
    },
    formValidator_init(backend) {
      submitBackend = backend;
      this.$watch("name", (value) =>
        console.log(`The name change to ${value}`)
      );
    },
  };
}

Worth noticing is the formValidator_init function, which is executed during the x-init lifecycle, and define the backend submission function.

The above architecture provides a lot of flexibility with the code. For example, to change the backend, only the netlifySubmission module will need to be replaced without any other code modification. Or maybe use the validators to other form inputs in the app.

This design can be implemented in Alpine.js by combing the javascript's object destructuring ability for compositing the object that the x-data attribute expects and the browser's native module support.

Function Composition

Therefore, the final step is to create the AlpineJs component by using the previous modules. The Alpine.js expects a data object in its x-data attribute, which also declares the component scope; accordingly, a function may compose this data object by combining the modules' exported functions and variables.

If it helps, you may think of this function as the setup property of a Vue component, although you cannot use the full capabilities that Vue's setup function provides, for example, an effect or watch feature. For that, the x-init attribute and the $watch magic attribute may be of help. We write inside the HTML file that the form lies the following code:

 <script type="module" defer>
      import { formValidator } from "./form-validator.mjs"
      import { netlifySubmission } from "./netlify.mjs"

      window.contactForm = function() {
         return {
           ...netlifySubmission(),
           ...formValidator(),
          init() {
             this.formValidator_init(this.submitToNetlify);
             this.$watch("email", (value) =>
               console.log(`the value of the email is ${this.email}`)
             );
           }
         }
       }
    </script>

First, we defined a script tag as a module and imported our other modules. In our example, we used the .mjs extension, although the standard .js extension will work as well. I recommend using the .mjs extension as it makes it easier to distinguish modules from regular javascript files. If you want to know more about the module support, check the Mozilla MDN guide.

We must then explicitly assign our function in the window global scope to be accessible from the x-data attribute because we use the module approach. Finally, we compose the final data object from the module's exports using the javascript's spread operator and initialize our formValidator module in the init() function.

The init() function is used in x-init attribute and is executed after the initialization of AlpineJs component. It mimics the mounted() or ngOnInit() hooks from Vue or Angular, respectively. In this function, we may initialize our modules as we do with the formValidator or include some side effects using $watch magic attribute.

Overall, I find this approach very scalable if you want to grow your AlpineJs to something more complicated or reduce some code repetition to your web app.

You may find a complete working version in the following codesandbox:

Developing a Netlify Contact Form using Alpine.js

Konstantinos Zagoris — Sun, 07 Mar 2021 18:09:23 +0000

The most common request to a simple landing or a simple company web page is to provide a simple contact form. A simple feature to add, isn't it? Well, not so much. For a simple static web deployment, you need to provide a backend infrastructure with email support. Fortunately, there is an easy solution for it.

What is the Netlify?

Netlify is a service platform that provides static deployment to your website with many features such as custom domains, https, git deployment, serverless functions, and for us, a form service.

How does it work?

For a simple HTML form, append the netlify attribute to its form tag:

<form name="contact" netlify>
....

</form>

Then, every time a user submits the form, it will be intercepted from Netlify, the form info will appear in your site dashboard, and the user will be directed to a success page. Furthermore, it may be configured to notify yourself of the submissions using email or any webhook and add three-level spam filtering.

Spam Prevention

The spam prevention systems consist of:

a spam detection system,
an optional honeypot field, which is a hidden form field that lures bot users into completing a field that human users can't see, and
an optional reCAPTCHA spam prevention.

If you do not want to use any javascript, the following HTML code will be working when it will be deployed:

The first takeout from the above code is how to compose the <form> tag:

<form name="contact" method="POST" data-netlify="true"
        netlify-honeypot="bot-field" data-netlify-recaptcha="true">

We named the form (name="contact"), we defined it as netlify form with the data-netlify="true" attribute and add two optional spam-prevention layers: the honeypot (netlify-honeypot="bot-field") and the Google reCAPTCHA 2 (data-netlify-recaptcha="true").

The netlify-honeypot attribute is working by adding a hidden input form element, which will be submitted as empty:

<p hidden><label>ignore: <input name="bot-field" /></label></p>

The idea behind this spam-prevention schema is that a bot will see the input element, and it will fill it. Therefore, if the form is submitted with a non-empty value, then it will be rejected. Take note that the name of the honeypot bot-field can be anything; just defined it in the <form> tag.

The Google reCAPTCHA 2 will be showing up by adding the following inside the <form> tag:

<div data-netlify-recaptcha="true"></div>

The above code will work on any HTML page that is deploying in the netlify server. In fact, by using the html5 form validation attributes, it can provide client-based form validation, too.

However, if the client-based form validation is desired to be done using javascript, how the submission is working? And, especially, using the Alpine.js?

Alpine.js

Alpine.js is a reactive framework, very similar to Vue, with two very distinct differences. The first is the lower cost, as it does not need a bundler. Just adding a script tag (~8KB gzip and minified) is sufficient. The second one involves ignoring the famous virtual DOM strategy and adopts for sprinkling the code directly on your HTML. In that respect, it is very similar to Tailwind but for javascript instead of styling.

The installation is simple enough just add a script to the end of your <head> section:


<script src="https://cdn.jsdelivr.net/gh/alpinejs/alpine@v2.x.x/dist/alpine.min.js" defer></script>

These distinct characteristics make it more suitable for jQuery replacement for smaller tasks than Vue.

For more information, you may check the introductory article about Alpine.js:

Introducing AlpineJs. The Ideal jQuery Replacement

Konstantinos Zagoris ・ Feb 8 ・ 5 min read

#javascript #html #webdev #beginners

Initially, we recreate the HTML-only form code and hide it. The hidden form acts as a stand-in for the Alpine.js form component, so the netlify bot understands what to expect to receive from the fetch submission.

 <form
      hidden
      name="contact"
      method="POST"
      data-netlify="true"
      netlify-honeypot="bot-field"
      data-netlify-recaptcha="true"
    >
      <label><input type="text" name="name" /></label>
      <label> <input type="email" name="email" /></label>
      <label><textarea name="message"></textarea></label>
</form>

Next, we initialize our component using x-data with the required data object for form validation.
The x-data attribute plays the same role as the data Vue component property. The data object properties, as in Vue, are reactive.

<form
      x-data="{
                name : '',
                nameDirty: false,
                message: '',
                messageDirty: false,
                email: '',
                emailDirty: false,
               }"
      x-on:submit.prevent="
                  nameDirty = true;
                  emailDirty = true;
                  messageDirty = true;
                  submitMessage(name, email, message);"
      id="contact"
    >

The x-on attaches an event listener to the form submit event.

Next, to validate and check the value of an input form element component, the following code is used:

<p><label>Full Name: <input x-model="name" x-on:blur="nameDirty = true" type="text" name="name"/></label></p>
<p x-show.transition="nameDirty && name.length == 0" style="color: red" x-cloak>
        Please fill out your full name.
</p>

The x-model attribute adds a "two-way data binding" to the input element. Consequently, the input element's value will be in sync with the name variable in the data object. When the input lost focus, the nameDirty variable is updated as true.

If nameDirty is true and the name variable is empty, a warning message is shown using the x-show attribute. The x-show attribute toggles the display: none; style attribute on the element depending on the expression output.

The transition directive is a convenience API offered by Alpine.js, which applies CSS transitions to the element. From the documentation, the transition directive is a simultaneous fade and scale: opacity, scale: 0.95, timing-function: cubic-bezier(0.4, 0.0, 0.2, 1), duration-in: 150ms, duration-out: 75ms

Form Submission

The function submitMessage takes as input the contents of name, email and message variables, validate them, and if it is correct, it submits the form contents using the fetch API.

Note that the AJAX request's content must be URL-encoded, as the Netlify forms do not support JSON form data currently. The URL-encoded form can be easily created by using the URLSearchParams utility method:

let formElement = document.getElementById("contact");
let body = new URLSearchParams(new FormData(formElement)).toString();

The final complete submitMessage function is:

function submitMessage(name, email, message) {
    if (!name || name.length == 0 || !email || !isEmail || !message || message.length == 0) {
      return;
    }
    let formElement = document.getElementById("contact");
    let body = new URLSearchParams(new FormData(formElement)).toString();
    return fetch("/", {
      method: "POST",
      headers: {
        "Content-Type": "application/x-www-form-urlencoded",
      },
      body: body,
    })
      .then((response) => {
        if (response.ok) {
          formElement.reset();
          alert("Thank you for your message!");
        } else {
          throw new Error(`Something went wrong: ${response.statusText}`);
        }
      })
      .catch((error) => console.error(error));
  }

The final code using Alpine.js for client-based form input validation and sending the form to netlify using the Fetch API is:

Altogether, I think the Netlify form simplifies the usage of form in your web page. Of course, under the assumption to host your web app in their hosting service.

Yori Shell. The better CMD replacement

Konstantinos Zagoris — Sun, 28 Feb 2021 07:15:06 +0000

A recurring theme of many articles about Windows 10 is the lack of alternative native shells and terminals. This perpetual statement is not true as there are many shells and terminals for various user needs and windows versions. This article is the first section of a series that will present Windows's solutions about shells, terminals, and command-line installers similar to apt or brew.

First of all, a lot of confusion is caused by the shell and the terminal's role. A "shell" is a program or a layer that interacts with the operating system's services through a set of commands, while the "terminal" is an application that runs and hosts the shells. A lot of frustration about CMD's use was caused by the old and barebone terminal window that hosted it and not so much of the shell itself.

The CMD is a relic from the days of DOS (COMMAND.COM replacement) that has survived in our days. There are plenty of reasons for that. The initial windows users were DOS users; therefore, there was an element of familiarity. Moreover, the CMD is more manageable than UNIX shells' complexity for most developers' simple everyday needs.

Microsoft started to push PowerShell as the CMD replacement. The PowerShell was a fully object-oriented framework built upon the .NET Framework best suited for the Windows machines administration. Although powerful, it was a complete departure from the CMD simplicity.

Other options for Linux lovers are the bash shell emulation with the easier distribution through git for windows. Of course, for the most modern and compatible approach for Windows 10, there is the Windows Subsystem for Linux.

Installation

Yori shell fills the niche between something more straightforward or familiar than the object-oriented PowerShell approach and more modern than the decades-old CMD.

It is open-sourced, and there is a very detailed guide if you want to dive into more details. The installation is pretty straightforward. Just download the latest installation file and run it.

As the following installation image shows, there are three different install types: install only the Yori Shell and its equivalent to CMD commands or include some additional useful tools in addition to the above core installation type.

Yori Native Tools

As you have already figured out, Yori Shell not only comes with CMD command replacements but with a set of new tools that you can make your life easier. Some notables tools are :

cpuinfo for displaying processor topology
env for launching a process with a custom environment
err for translating Windows error codes to text
mem for displaying memory usage
procinfo for displaying counters of process utilization
ps for enumerating executing processes
shutdn for shutting down or rebooting a system
sponge for buffering and replaying output to eliminate temporary files
timethis for measuring process execution time
various tools for VHDs and ISOs files
df for displaying a volume free space
du for calculating disk usage of directories

and my favourites (check image below)

a better dir command for display the contents of the directory
a new edit text editor for editing text files in the terminal

Modern Shell Features

The Yori Shell has many similarities with the CMD and adds specific features that any respectable modern shell must include. Two such features are command history and tab completion.

The Up and Down arrow keys are used to traverse the previously executed commands. The Ctrl+Up uses the typed characters to search and match a previous command, and the Ctrl+Del deletes the command from history.

For preserving the history command during different sessions, you may provide a file for storing the commands. The file path is configured in the startup Yori script by setting the variable YORICOMPLETEPATH.

The Yori Shell from Malcolm Smith provides configurable behaviour for tab completion. The default mimics the CMD tab completion by completing the executable first and then tries to match folders or files. The above action can be changed by setting the YORICOMPLETELISTALL variable to 1 to provide a list of available matches like the bash. Similarly, setting the YORICOMPLETEWITHTRAILINGSLASH variable to 1 adds a trailing slash like the PowerShell.

Another helpful feature is the ability to jump to special directories in your machine quickly. For example, the command cd ~ takes you to your home directory or the cd ~Appdata to the User's AppData\Roaming directory. As you will expect, the list of these special directories is comprehensive:

~ expands to Home directory, as set in %HOMEDRIVE%%HOMEPATH%
~Appdata expands to User's AppData\Roaming directory
~Appdir expands to Directory containing the Yori executable
~Commonappdata expands to The system application data directory
~Commondesktop expands to The system desktop, shared across all users
~Commondocuments expands to System documents, shared across all users
~Commonprograms expands to System's Start Menu\Programs directory
~Commonstart expands to System's Start Menu directory
~Desktop expands to User's desktop
~Documents expands to User's documents directory
~Downloads expands to User's downloads directory
~LocalAppData expands to User's AppData\Local directory
~Programs expands to User's Start Menu\Programs directory
~Programfiles expands to System's Program Files directory
~Programfiles32 expands to System's Program Files (x86) directory or Program Files in 32-bit environments
~Start expands to User's Start Menu directory
~Startup expands to User's Start Menu\Programs\Startup directory
~System expands to System's Windows\System32 directory
~Windows expands to System's Windows directory

Scripting

The scripting story is where it shines. It does not try to provide total compatibility for CMD scripts but instead executes them by CMD. Then, every change to the environment and aliases by the script is applied to the Yori process.

Moreover, it has a native script file extension that is .ys1, which provides extra commands that lessen the CMD scripting shortcomings. It provides a comprehensive outline of the Yori commands by running the ys /? command.

Configuration

The configuration of Yori Shell is done, as with most of the shells, by executing initialization scripts during the startup. It seeks the following locations:

Scripts under the ~AppDir\YoriInit.d directory or any script named ~AppDir\YoriInit* for system-wide configuration.
Scripts under the ~\YoriInit.d directory or any script name ~\YoriInit* for per-user configuration.

Updating

Another final feature which I am sure many will find useful is the ability to update by using the provide Yori Package Manager via the following command:

ypm -u

The Yori Shell satisfies my simple dev-based terminal needs; it is simple and fast! Hopefully, you will find the Yori Shell as intrigued as I am.

Landing Starter Template based on TailwindCSS, AlpineJs and build on esbuild and PostCSS

Konstantinos Zagoris — Sun, 14 Feb 2021 10:27:56 +0000

One of the constant requests I have as a freelancer programmer is constructing a landing page for a project/company/research project. Therefore, it is better to have an already starter template adopted as a base to iterate upon it quickly.

My starter, is an opinionated template that has the following features:

Tailwind CSS for styling
Alpine.js for template/dynamic logic
a simple build system that may help me scale up if the needs arise (for example, add scss for styles or Typescript)

Tailwind CSS is a highly customizable, low-level CSS framework gaining popularity lately. It is not opinionated as it gives you the building blocks for styling your components.

Unfortunately, tailwind requires a build system to take advantage of all its features. Furthermore, during deployment, the unused CSS must be removed because the style file becomes very large (>2Mb). The PostCSS and its plugins come to the rescue.

Alpine.js is very similar to tailwind but for the javascript. It provides the features of Vue.js with a much lower cost and - I think - a most suitable replacement for jQuery than other frameworks. If the code requirements are very light, then a build system is not required. Just add the Alpine.js package in a script tag and sprinkle your login in the HTML DOM file.

I must say that Alpine.js, which does not use a virtual DOM, has some tricked spots regarding the scope of nested components and their communication or the way nested loops are constructed, but for most cases - e.g., landing pages - is adequate. For more information, check out out my post introducing Alpine.js:

Introducing AlpineJs. The Ideal jQuery Replacement

Konstantinos Zagoris ・ Feb 8 ・ 5 min read

#javascript #html #webdev #beginners

My preference is to use Typescript (I love the IntelliSense capabilities that provide); therefore, I use the Evan Wallace's esbuild, a fast Javascript/Typescript bundler, and a minifier.

Finally, we will use the gorgeous, simple, and versatile landing page design from the Creative Tim's Tailwind Starter Kit for our starter template's design. It way better for our productivity to have a well-formed, responsive design as a base.

Template initialization

Let's initialize our starter:

md tailwindcss-alpinejs-starter
cd tailwindcss-alpinejs-starter
npm init

The structure of the template is straightforward:

src/css/ folder contains our template's source styles with the file main.css as the entry point.
src/ts/ folder contains our typescript code with the file main.ts as the entry point.

The assets/ folder contains the static assets - img, files to downloads, etc. Here, the output files from the CSS (CSS and web fonts) and js (js file) build system will be created.

Let's begin by getting the landing.html and the Landing Page starter kit's assets folder. We don't need the vendor directory (contains fontawesome icons) as we will self-hosted it ourselves.

Then, install the required packages:

npm install alpinejs tailwindcss @fortawesome/fontawesome-free

PostCSS configuration

It is time to create a build system for the styles based on PostCSS, a modern plugin-based CSS parser. The src/css/ folder contains our source CSS, which builds a minified clean version in the file assets/style.css.

Next, install the dev dependencies:

postcss packages,
its cli version,
and the plugins:
- postcss-import for using the import function in CSS,
- @fullhuman/postcss-purgecss for the purgings of the unused CSS styles,
- postcss-copy for copying assets referenced as web fonts , and, of course,
- the cssnano package for the minification.

npm install postcss postcss-cli postcss-import cssnano @fullhuman/postcss-purgecss  --save-dev

Our postcss.config.js is:

const purgecss = require("@fullhuman/postcss-purgecss")({
  // Specify the paths to all of the template files in your project
  content: ["./index.html"],
  // This is the function used to extract class names from your templates
  defaultExtractor: (content) => {
    // Capture as liberally as possible, including things like `h-(screen-1.5)`
    const broadMatches = content.match(/[^<>"'`\s]*[^<>"'`\s:]/g) || [];

    // Capture classes within other delimiters like .block(class="w-1/2") in Pug
    const innerMatches = content.match(/[^<>"'`\s.()]*[^<>"'`\s.():]/g) || [];

    return broadMatches.concat(innerMatches);
  },
});

module.exports = {
  plugins: [
    require("postcss-import")(),
    require("tailwindcss")(),
    require("autoprefixer")(),
    require("postcss-copy")({
      dest: "assets/webfonts",
    }),
    ...(process.env.ENV_BUILD === "prod" ? [purgecss] : []),
    ...(process.env.ENV_BUILD === "prod" ? [require("cssnano")()] : []),
  ],
};

The postcss.config.js format is straightforward. We define our plugins, and when we initiate the deployment build by using an environmental variable, we use the purge CSS and minification plugins.

The package.json build scripts are:

"watch-css": "postcss src/css/main.css -o assets/css/style.css -w",
"build-css": "cross-env ENV_BUILD=prod postcss src/css/main.css -o assets/css/style.css"

The cross-env is an npm package that sets environment variables in a cross-platform away.

esbuild configuration

Next step, the esbuild is added. After version v0.8.38, the esbuild added a -watch and after the v0.8.45, the esbuild added the --servedir= flag, allowing running a built-in web development server.

I like to use Typescript, as the IntelliSense that provides is impressive and very helpful. I understand that Typescript is not everyone's favourite, and it may complicate some things unnecessary. Hence, the following step is not required, but to acquire the Typescript's Intellisense superpower, install the typescript packages and initialize a tsconfig.js in the src/ts folder.

npm install --save-dev typescript

And in the src/ts folder run the following command to initialize the tsconfig.js file.

tsc --init

In main.ts, import the alpine.js.

The package scripts are very straightforward:

"watch-js": "esbuild src/ts/main.ts --bundle --sourcemap=inline --target=es2016 --outfile=assets/js/main.js --watch",
"debug-js": "esbuild src/ts/main.ts --bundle --sourcemap=inline --target=es2016 --outfile=assets/js/main.js --servedir=./",
"build-js": "esbuild src/ts/main.ts --bundle --minify --target=es2016 --outfile=assets/js/main.js",

The watch-js command watches for any changes and creates a debug build of our code with a source map. The debug-js command is the same as the watch-js command, but it runs the esbuild built-in web development server. The build-js command executes our deployment pipeline and outputs the minified code.

To run both commands, will use the concurrently npm package:

npm install concurrently  --save-dev

and add the stript:

"start": "concurrently \"npm:watch-css\" \"npm:watch-js\"",
"dev": "concurrently \"npm:watch-css\" \"npm:debug-js\""

Finally, the deployment command runs the build-js and build-css commands and copy the index.html and assets\ folder to a dist folder using the copyfiles package. This dist folder is the deployment folder.

npm install copyfiles  --save-dev

Therefore, during the development (for the watch mode) use:

npm start

If you want a web development server alongside use :

npm run dev

For deployment, run:

npm run deploy

Starter Github Repository

You can use the provided starter template freely at https://github.com/wittyprogramming/tailwindcss-alpinejs-starter

Introducing AlpineJs. The Ideal jQuery Replacement

Konstantinos Zagoris — Mon, 08 Feb 2021 07:06:34 +0000

Most uncomplicated today web sites, like blogs or landing pages, do not need extensive javascript frameworks with complicated build steps.

Let's take, for example, the Virtual-DOM concept that is so popular today. Do you need this abstraction to use it in a form or add some simple user interactions for most web sites?

JQuery took this role in the websites, and it is one of the reasons that it is still one of the most popular libraries. Unfortunately, jQuery is a child of an old era and does not consider modern concepts such as the reactive state. Furthermore, most jQuery features, such as selectors or simplified AJAX calls, are replaced by modern javascript.

The question to jQuery replacement for most web sites' simple logic tasks can answer the Alpine.js framework. It substitutes the jQuery query-based (imperative) approach with the tailwindcss-inspired declarative approach on the DOM using a familiar Vue-like syntax.

Installation

The installation is simple enough; add a script to the end of your <head> section:

<script src="https://cdn.jsdelivr.net/gh/alpinejs/alpine@v2.x.x/dist/alpine.min.js" defer></script>

The cost of the library itself is low. The comparison with the other frameworks shows that:

Alpine.js Example

Let's introduce ourselves to this framework by using, as an example, a simple login form. The user provides the username and password, and if the supplied password is equal to pass, then a welcome message is displayed tailored to the given username. Otherwise, an error message is displayed.

The whole code is displayed here:

<div x-data="{ username:'', password: '', login : false, error: false }">
    <form x-show="!login" x-on:submit.prevent="error=false;
        if (password === 'pass') 
        login = true; 
        else error = true;" method="post">
        <div>
            <label for="username"><b>Username:</b></label>
            <input x-model="username" type="text" placeholder="Enter Username" name="username" required />
        </div>
        <div>
            <label for="password"><b>Password: </b></label>
            <input x-model="password" type="password" placeholder="Enter Password" name="password" required />
        </div>
        <div>
            <button type="submit">Login</button>
        </div>
        <div>
            <label>
                <input type="checkbox" checked="checked" name="remember" /> Remember
                me
            </label>
        </div>
    </form>
    <div x-show="login" x-text="`welcome ${username}`"></div>
    <div x-show="!login && error" style="color: red;">Login failed!</div>
</div>

Component Initialization

Take note of the following code:

<div x-data="{ username:'', password: '', login : false, error: false }">

In the above line, we initialize a component with the corresponding data object. Specifically, we initialize an empty username and password string and set the login and error as false.

The x-data attribute plays a similar role to a Vue's component data property. Accordingly, these variables are reactive, as you will expect from the Vue.js experience.

Take note that if you seek something like the mounted() in VueJS or the ngOnInit() in Angular hooks, the x-init attribute is more appropriate.

Binding

The next step involves the approaches to the variable binding. The following code binds the variable username to the input element's value using the x-model attribute.

<input x-model="username" type="text" placeholder="Enter Username" name="username" required />

The x-model attribute, as you probably guessed, is similar to Vue.js's v-model attribute and implements a two-way binding between the variable and the value of the element.

For one way binding, the x-bind attribute is used and similar to Vue.js there is the shorter syntax of :attr. The following two example are equivalent:

<a x-bind:href="homeUrl">Home</a>
<a :href="homeUrl">Home</a>

Two other one-way bindings similar to the x-bind attribute are the x-text and the x-html attributes. The first one will update the element's innerText and the second the element's innerHTML values. At our login form example, we used the x-text attribute to display a welcome login message based on user's username:

<div x-show="login" x-text="`welcome ${username}`"></div>

Toggle Display

The x-show attribute in Alpine.js toggles the display:none element's style depending on the expression's outcome. The above example will show the welcome message when the login is set to be true.

Another similar attribute is the x-if, which completely removes the element from the DOM but has two significant constraints. Because the Alpine uses the real DOM and not a virtual, the first constraint is that the x-if attribute must be applied on a <template></template> tag. Consequently, the second constraint is that the <template></template> must have a single element root. The equivalent of the above x-show example using the x-if attribute is:

<template x-if="login">
    <div x-text="`welcome ${username}`"></div>
</template>

Loops

The same limitations are applied for the x-for attribute, which creates new DOM nodes based on an array similar
to the Vue's v-for.:

<template x-for="item in items" :key="item">
    <div x-text="item"></div>
</template>

For inner loops the same considerations is applied:

<template x-for="item in items">
    <div>
        <template x-for="subItem in item.subItems">
            <div x-text="subItem"></div>
        </template>
    </div>
</template>

The limitation which the template tag enforces must be under constant consideration when you want to use loops or the x-if attribute.

Events

For listening and responding to events, the x-on:event or the alternative syntax @:event is used. Similar to Vue, the x-on attaches an event listener to the corresponding element's event. When that event is emitted, the specified expression is executed. In our example, when the form is submitted, we check if the password is correct and then setting the corresponding variable.

 <form x-show="!login" x-on:submit.prevent="error=false;
         if (password === 'pass') 
            login = true; 
         else error = true;" method="post">

The final result looks like this:

Conclusion

The Alpine.js advantages present during simple DOM manipulation based on user interactions; therefore, it is most suitable for:

showing, hiding, or removing DOM nodes under certain conditions
two-way or one-way binding of attributes
watching and responding to user/UI events

In the next articles in the Alpine.js series, I will write some more advantage tools like:

reusable functions for minimizing javascript code in DOM and allowing code reuse
the spruce library as a global state for simplifying the inter-component communication
several magic helpers will help facilitate some common patterns like ajax interactions or parent component access.

The above tools help us to use Alpine.js for more advanced implementations.

In the end, if you seek a suitable and easy replacement for jQuery, I think you will find Alpine.js most suitable.

DEV Community: Konstantinos Zagoris

Lazy-load a component in Angular without routing

Scaffolding a Sample Form App

Lazy Loading a Simple Component

For Angular 13

Lazy loading a complex component

For Angular 13

Passing values and listening events

wittyprogramming / lazy-load-component-angular

Lazy load a component in Angular 12 without a router

Lazy-load a component in Angular without routing

wittyprogramming / lazy-load-component-angular13

Lazy load a component in Angular 13 without a router

Lazy-load a component in Angular 13 without routing

Cross-component Communication Patterns in AlpineJs

Custom Javascript Event

The dispatch magic attribute

The component magic helper

Having a global state by using the spruce library

Conclusions

Developing AlpineJs Apps Similar to Vue's Composition API

Introducing AlpineJs. The Ideal jQuery Replacement

Konstantinos Zagoris ・ Feb 8 ・ 5 min read

Architecture

Developing a Netlify Contact Form using Alpine.js

Konstantinos Zagoris ・ Mar 7 ・ 5 min read

Validators Module

netlifySubmission Module

formValidator Module

Function Composition

Developing a Netlify Contact Form using Alpine.js

What is the Netlify?

Spam Prevention

Alpine.js

Introducing AlpineJs. The Ideal jQuery Replacement

Konstantinos Zagoris ・ Feb 8 ・ 5 min read

Form Submission

Yori Shell. The better CMD replacement

Installation

Yori Native Tools

Modern Shell Features

Scripting

Configuration

Updating

Landing Starter Template based on TailwindCSS, AlpineJs and build on esbuild and PostCSS

Introducing AlpineJs. The Ideal jQuery Replacement

Konstantinos Zagoris ・ Feb 8 ・ 5 min read

Template initialization

PostCSS configuration

esbuild configuration

Starter Github Repository

Introducing AlpineJs. The Ideal jQuery Replacement

Installation

Alpine.js Example

Component Initialization

Binding

Toggle Display

Loops

Events

Conclusion

The `dispatch` magic attribute

The `component` magic helper

Having a global state by using the `spruce` library