Angular

Plugin Architecture for Angular Libraries using Dependency Injection

Published Mar 31, 2021

Updated Feb 14, 2023

8 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

The plugin architecture is a well-known software design pattern used for its flexibility, extensibility, and isolation. It consists of a core system and several separate plugin modules.

We will cover how to create a plugin-based architecture in Angular using its Dependency Injection system and why this is an excellent tool to have in our Engineers belt.

Plugin Architecture

The Plugin Architecture concept is simple: the Core System manages the essential functionalities and orchestrates the Plugins, but it is agnostic of its behavior. The Plugins implement the use-case-specific functionalities, and they are agnostic of other plugins and the system behavior.

The Core System is responsible for defining the contract used by itself and the Plugins to communicate.

Plugins aren't necessarily designed for a particular Core System, but in those cases, an adapter is required to make the Plugins follow the contract.

The main principles related to this kind of Architecture are the Inversion of Control (IoC) Principle and the Dependency Inversion Principle (DIP, the D from the SOLID principles)

While the Plugins follow the IoC by extracting behavior and control from the main flow or Core System, the DIP is necessary for avoiding coupling and establishing the contract.

Dependency Injection is not the only design pattern that allows building a Plugin Architecture or follow the IoC Principle; callbacks, schedulers, event loops, and message queues are also valid options.

If you are interested in learning more about Plugin Architecture, check the following links

Plugin-based Angular Libraries

The Angular community is big and healthy, every day, new packages get published, and our favorite tools get renewed.

In this constellation, not all libraries are built using a Plugin Architecture, and with a good reason. This pattern is NOT a silver bullet, and you should not try to design all your libraries using Plugins.

But there are some scenarios where the Plugin Architecture provides outstanding flexibility and relief maintainers from creating all possible features for a given domain. For example, in Components libraries, using content projection is a great way to achieve IoC. From there, it is pretty easy to build plugins that extend your core Component functionality or customize the UI.

In this article, we will focus on another of the design patterns implemented in Angular, the Dependency Injection (DI) pattern.

Implementing a Plugin Architecture with Dependency Injection

As described previously, the Plugin Architecture has two components. The Core System and the Plugins.

The Plugins depend on the Core System, but not the other way around. Therefore, we should start designing the Core System first.

The minimum elements we are going to need are

PluginContract, this is the contract that our Plugins will implement and that the Core System uses for communication.
PluginInjectionToken, in some technologies, the
PluginContract would be used as the injection token. Still, since interfaces are not genuine artifacts in typescript and they disappear at build time, we have to define an additional token. It is good to notice that this splitting also contributes to the separation of concerns.
OrchestrationService will gather all the plugins, orchestrate their behavior, and provide error resolution.

We will also have some configuration elements, optional for small and straightforward systems but instrumental in building flexible libraries.

PluginConfiguration contains information about the integration of the Plugin with the Core system. The OrchestrationService uses it to identify if it should execute a Plugin and how. The Plugin can extend it to configure internal Plugin behavior. The core system can provide a default configuration for the Plugins.
PluginConfigurationToken, injection token for the PluginConfiguration
CoreConfiguration provides configuration at a Core level, makes the overall system execute in a certain way.
CoreConfigurationToken, injection token for the CoreConfiguration

The dependency flow would look like Fig.2.

The Angular code

Now that we have a big picture of our architectural design let's jump into the details and learn how to implement our library following this pattern.

The core system

The first thing we need is the contract that our plugins need to implement to communicate with the core system.

import { PluginConfig } from './plugin.config';

export interface SystemPlugin {
  config: PluginConfig; // 👈

  operationA(...args: unknown[]): unknown;
  operationB(...args: unknown[]): unknown;
  operationZ(...args: unknown[]): unknown;
}

This contract could have any signature; it is up to the library that you are building. The only remarkable element is the config. We are forcing the Plugin to have it since the Core System needs it to handle the Plugin correctly.

The config itself is very basic and generic for our demonstrational purpose. Still, the idea is to define in the PluginConfig everything that we want to make adjustable in our Plugin behavior. This config can serve both the Plugin and the Core System.

export interface PluginConfig {
  optionA: unknown;
  optionB: unknown;
  optionZ: unknown;
}

Of course, we need some injectors here since we cannot use the interfaces with Angular Dependency Injection. Let's add those.

import { InjectionToken } from '@angular/core';
import { SystemPlugin } from './plugin';

export const pluginToken: InjectionToken<SystemPlugin> = new InjectionToken(
  '__PLUGIN_TOKEN__'
);

and

import { InjectionToken } from '@angular/core';
import { PluginConfig } from './plugin.config';

export const pluginConfigToken: InjectionToken<PluginConfig> = new InjectionToken(
  '__PLUGIN_CONFIG_TOKEN__'
);

The next thing we are going to implement is our Core System configuration.

export interface CoreConfig {
  coreOptionsA: unknown;
  coreOptionsB: unknown;
  coreOptionsZ: unknown;
}

The CoreConfig, like all other elements of this example, should be implemented accordingly with your library. For simplicity, let's imagine it represents all the different configurable tweaks we can make to our Core System. Occasionally, part of the configuration options of the CoreConfig are used as global defaults for not required configuration options in the PluginConfig.

As before, we will also create the coreConfigToken to inject the CoreConfig.

import { InjectionToken } from '@angular/core';
import { CoreConfig } from './core.config';

export const coreConfigToken: InjectionToken<CoreConfig> = new InjectionToken(
  '__CORE_CONFIG_TOKEN__'
);

Next, let's take a look at our OrchestratorService, the heart of our library. In our example, the OrchestratorService will also be the entry point to our library, but this is not required. The library entry points can vary from a directive to a secondary service that uses the orchestrator service to any other communication form between the client code and our library.

import { Inject, Injectable, Optional } from '@angular/core';
import { coreConfigToken } from './core-config.token';
import { CoreConfig } from './core.config';
import { SystemPlugin } from './plugin';
import { pluginToken } from './plugin.token';

@Injectable({ providedIn: 'root' })
export class OrchestratorService {
  private readonly plugins: SystemPlugin[];

  constructor(
    @Optional()
    @Inject(pluginToken)
    plugins: SystemPlugin[],
    @Inject(coreConfigToken) private config: CoreConfig
  ) {
    plugins = plugins || [];
    this.plugins = Array.isArray(plugins) ? plugins : [plugins];
  }

  coreOperationA(...args: any[]): unknown {
    // just a demonstration of what can be done
    return this.plugins
      .filter((plugin) => this.canPluginExecute(plugin))
      .reduce<unknown>((acc, plugin) => plugin.operationA(acc), null);
  }

  private canPluginExecute(plugin: SystemPlugin): boolean {
    // implement any validation to determine whether the plugin should be executed or not

    // use the  core config and/or the driver config

    // just a demonstration of what can be done
    return (
      (this.config.coreOptionsA as boolean) &&
      (plugin.config.optionA as boolean)
    );
  }
}

Wow, a lot is going on in there. Since this service is larger than the other files, let's split it to understand what is going on.

constructor(
    @Optional()
    @Inject(pluginToken)
    plugins: SystemPlugin[],
    @Inject(coreConfigToken) private config: CoreConfig
  ) {
    plugins = plugins || [];
    this.plugins = Array.isArray(plugins) ? plugins : [plugins];
  }

The first thing we need to do is inject what we are going to need.

The key elements are the Plugins, and I want to emphasize the plural, Plugins. We are receiving an Array of Plugins. However, it is possible that we only received a single Plugin or none plugin at all. In such cases, we need to transform the data to a suitable form, to an Array.

But, how is it possible to receive multiple instances of the same Injection token? That's one of the critical ingredients when using Angular's Dependency Injection as the Plugin Architecture mechanism. We will go over this feature when we provide our Plugins, but the key is in the multi options of Angular's StaticProvider.

 coreOperationA(...args: any[]): unknown {
    // just a demonstration of what can be done
    return this.plugins
      .filter((plugin) => this.canPluginExecute(plugin))
      .reduce<unknown>((acc, plugin) => plugin.operationA(acc), null);
  }

The coreOperationA is an example of how the client code could use our library and how the OrchestratorService handles our plugins.

The example implementation shows how we can filter which plugins are configured to execute at a given moment and how to compose the different plugins to build a response. Real-world implementations could differ significantly, but the point is that we can access all the configured plugins and make decisions about them in our orchestrator.

Finally, we use our canPluginExecute method to determine if a Plugin should be used or not based on both the CoreConfig and the PluginConfig.

 private canPluginExecute(plugin: SystemPlugin): boolean {
    // implement any validation to determine whether the plugin should be executed or not

    // use the  core config and/or the driver config

    // just a demonstration of what can be done
    return (
      (this.config.coreOptionsA as boolean) &&
      (plugin.config.optionA as boolean)
    );
  }

And that's it. That is our Core System, well almost, we still need a module to configure everything. Let's see how we can do that.

import { ModuleWithProviders, NgModule } from '@angular/core';

import { CoreConfig } from './core.config';
import { coreConfigToken } from './core-config.token';

@NgModule()
export class CoreSystemModule {
  static forRoot(config: CoreConfig): ModuleWithProviders<CoreSystemModule> {
    return {
      ngModule: CoreSystemModule,
      providers: [{ provide: coreConfigToken, useValue: config }],
    };
  }
}

We are using the static method forRoot to received the CoreConfig configuration from the client code and then provided it to the DI system. Otherwise, we might not need to have a module, but this is a well-known pattern.

The Plugins

The Core System exports everything we need, and possibly it could execute independently, but a Plugin Architecture makes little sense without plugins.

Let's start by implementing our SystemPlugin contract; that's where our unique Plugin logic will leave after all.

import { Inject, Injectable } from '@angular/core';
import {
  PluginConfig,
  pluginConfigToken,
  SystemPlugin,
} from 'projects/core-system/src/public-api';

@Injectable()
export class ExamplePlugin implements SystemPlugin {
  constructor(@Inject(pluginConfigToken) readonly config: PluginConfig) {}
  operationA(...args: unknown[]): unknown {
    throw new Error('Method not implemented.');
  }
  operationB(...args: unknown[]): unknown {
    throw new Error('Method not implemented.');
  }
  operationZ(...args: unknown[]): unknown {
    throw new Error('Method not implemented.');
  }
}

We need to inject our PluginConfig and implement the interface; the particular implementation is unique to every Plugin. This example shows non-implemented methods, but the idea is there.

The final piece and essential part is the Plugin configuration.

import { ModuleWithProviders, NgModule } from '@angular/core';
import {
  PluginConfig,
  pluginConfigToken,
  pluginToken,
} from 'projects/core-system/src/public-api';
import { ExamplePlugin } from './example.plugin';
export function examplePluginFactory(config: PluginConfig): ExamplePlugin {
  return new ExamplePlugin(config);
}
@NgModule()
export class ExamplePluginModule {
  static forRoot(
    config: PluginConfig
  ): ModuleWithProviders<ExamplePluginModule> {
    return {
      ngModule: ExamplePluginModule,
      providers: [
        { provide: pluginConfigToken, useValue: config },
        {
          provide: pluginToken,
          useFactory: examplePluginFactory,
          deps: [pluginConfigToken],
          multi: true,
        },
      ],
    };
  }
}

Firstly, we are receiving the PluginConfig from the client code and providing it to the Dependency Injection system. Then it is time to provide our Plugin.

Since our Plugin depends on the provided PluginConfig we need to use a factory function combined with the deps property.

The critical part is the multi options. If missed, that single configuration can make the whole system fail because it can overwrite all other plugins and only provide the one without multi. When set to true, it enables the power of importing multiple artifacts using a single injection token, in this case, our Plugins.

And that's all we need! Now we can start using our Plugin-based library.

Usage

Like with any other Angular library, we have to import it and configure its module.

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { CoreSystemModule } from 'projects/core-system/src/public-api';

import { AppComponent } from './app.component';

@NgModule({
  declarations: [AppComponent],
  imports: [
    BrowserModule,
    CoreSystemModule.forRoot({
      coreOptionsA: '_A_',
      coreOptionsB: '_B_',
      coreOptionsZ: '_Z_',
    }),
  ],
  bootstrap: [AppComponent],
})
export class AppModule {}

Now we can start using our OrchestratorService or any other communication form we have in place in our library.

However, we will not go far if we don't have any Plugins; let's add the one we already implemented.

import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { CoreSystemModule } from 'projects/core-system/src/public-api';
import { ExamplePluginModule } from 'projects/example-plugin/src/public-api';

import { AppComponent } from './app.component';

@NgModule({
  declarations: [AppComponent],
  imports: [
    BrowserModule,
    CoreSystemModule.forRoot({
      coreOptionsA: '_A_',
      coreOptionsB: '_B_',
      coreOptionsZ: '_Z_',
    }),
    ExamplePluginModule.forRoot({
      optionA: '-A-',
      optionB: '-B-',
      optionZ: '-Z-',
    }),
  ],
  bootstrap: [AppComponent],
})
export class AppModule {}

And as simple as that, without letting the CoreSystemModule know anything about our Plugin, we have our system configured.

I hope you can appreciate the simplicity of the configuration of our Plugin Architecture. Exactly as we imported our ExamplePluginModule, we can import as many Plugins as we want, following the same structure. The Core System will access all the imported Plugins and manage its usage for us.

Now we are set up, let's start using our library.

import { Component } from '@angular/core';
import { OrchestratorService } from 'projects/core-system/src/public-api';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss'],
})
export class AppComponent {
  title = 'plugins-architecture-demo';

  constructor(private orchestrator: OrchestratorService) {
    this.orchestrator.coreOperationA();
  }
}

The client application or library now only has to inject our library entry point. In our example, it is the OrchestrationService. Then, it can start interacting with the library. Plugins are only a concern of the library. The client code is agnostic to the Plugins' existence except for the configuration part.

Conclusion

The Plugin Architecture pattern is a great pattern to create extensible systems using the Inversion of Control Principle and lifting the focused functionalities of our system to the Plugins.

We have learned how to implement a custom Angular library following a Plugin Architecture using Angular Dependency Injection, while briefly introducing the Angular Dependency Injection elements that allow us to make our Plugins decoupled from our Core System.

You can find the final solution at this repo

And if you want to see a real-world usage of this pattern you can visit Lumberjack

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Nacho Vazquez
Front-end architect, tech writer, meetup speaker, scuba diving lover. Passionate about Software architecture and sharing knowledge.
@nacho_vazquez14 @NachoVazquez

Angular 18 Announced: Zoneless Change Detection and More

Angular 18 Announced: Zoneless Change Detection and More Angular 18 has officially landed, and yet again, the Angular team has proven that they are listening to the community and are committed to continuing the framework's renaissance. The release polishes existing features, addresses common developer requests, and introduces experimental zoneless change detection. Let's examine the major updates and enhancements that Angular 18 offers. 1. Zoneless Angular One of the most exciting features of Angular 18 is the introduction of experimental support for zoneless change detection. Historically, Zone.js has been responsible for triggering Angular's change detection. However, this approach has downsides, especially regarding performance and debugging complexity. The Angular team has been working towards making Zone.js optional, and Angular 18 marks a significant milestone in this journey. Key Features of Zoneless Angular 1. Hybrid Change Detection: In Angular 18, a new hybrid change detection mode is enabled by default. This mode allows Angular to listen to changes from signals and other notifications regarding changes that occur either inside an Angular zone or not. That effectively means you can write (library) code that works regardless of whether Zone.js is being used, paving the way to fully zoneless apps without compromising backward compatibility. For new applications, Angular enables zone coalescing by default, which removes the number of change detection cycles and improves performance. For existing applications, you can enable zone coalescing by configuring your NgZone provider in bootstrapApplication: ` 2. Experimental API for Zoneless Mode: Angular 18 introduces an experimental API to disable Zone.js entirely. This API allows developers to run applications in a fully zoneless mode, paving the way for improved performance and simpler debugging. The zoneless change detection requires an entirely new scheduler which relies on notifications from the Angular core APIs, such as ChangeDetectorRef.markForCheck (called automatically by the AsyncPipe), ComponentRef.setInput, signal updates, host listener updates, or attaching a view that was marked dirty. 3. Improved Composability and Interoperability: Zoneless change detection enhances composability for micro-frontends and interoperability with other frameworks. It also offers faster initial render and runtime, smaller bundle sizes, more readable stack traces, and simpler debugging. How to Try Zoneless Angular To experiment with zoneless change detection, you can add the provideExperimentalZonelessChangeDetection provider to your application bootstrap: ` After adding the provider, remove Zone.js from your polyfills in angular.json. You can read more about the experimental zoneless change detection in the official documentation. By the way, angular.dev is now considered the official home for Angular developers! 2. Server-side Rendering and Hydration Enhancements A feature I'm particularly excited about is the improvements to Angular's server-side rendering (SSR) and hydration in terms of developer experience and debugging: 1. Enhanced DevTools Support: Angular DevTools now includes overlays and detailed error breakdowns to help visualize and debug hydration issues directly in the browser. This refreshing focus on developer experience shows that the Angular team wants to make the framework more approachable and user-friendly. 2. Hydration Support for Angular Material: All Angular Material components now support client hydration and are no longer skipped, which enhances performance and user experience. 3. Event Replay: Available in developer preview, event replay captures user interactions during SSR and replays them once the application is hydrated, ensuring a seamless user experience before complete hydration. It is powered by the same library as Google Search. 4. i18n Hydration Support: Up to v17, Angular skipped hydration for components with i18n blocks. From v18, hydration support for i18n blocks is in developer preview, allowing developers to use client hydration in internationalized applications. 3. Stable Material Design 3 After introducing experimental support for Material Design 3 in Angular 17, Angular 18 now includes stable support. The key features of Material Design 3 in Angular 18 include: 1. Simplified Theme Styles: Based on CSS variables, the new theming styles offer more granular customization and a flexible API for applying color variants to components. 2. Theming Generation Schematics: Using the Ng CLI, you can generate Material 3 themes. 3. Sass APIs: New Sass APIs allow developers to read colors, typography, and other properties from the Material 3 theme, making it easier to create custom components. How to use Material Design 3 in Angular 18 To use Material Design 3 in Angular 18, you can define a theme in your application's styles.scss file using the mat.defineTheme function: ` Or generate a Material 3 theme using the Ng CLI: ` You can then apply the theme to your application using the mat.theme mixin: ` Head to the official guide for a more detailed guide. You'll also notice they have refreshed the docs with the new themes and further documentation. 4. Signal-Based APIs The path to fully signal-based components includes new signal inputs, model inputs, and signal query APIs. We already wrote about them as they were in developer-preview in v17, but they have been further refined in v18. These APIs offer a type-safe, reactive way to manage state changes and interactions within components: 1. Signal Input API: Signal inputs allow values to be bound from parent to child components. Those values are exposed using a signal and can change during the component's life cycle. 2. Model Input API: Model inputs are a special input type that enables a component to propagate new values back to the parent component. That allows developers to keep the parent component in sync with the child component with two-way binding. 3. Signal Query API: This was a particularly requested feature from the community. The signal query APIs work the same way as ViewChild and ContentChild under the hood, but they return signals, providing more predictable timing and type safety. 5. Fallback Content For ng-content A very requested feature from the community, Angular 18 introduces a new ng-content directive that allows developers to define fallback content when no content is projected into a component. This feature is particularly useful for creating reusable components with default content. Here's an example of using the new ng-content directive. Using the following component ` like this ` will render Howdy World. 6. Other Improvements In addition to the major updates mentioned above, Angular 18 also includes several other improvements and updates: 1. TypeScript 5.4: Angular 18 now supports TypeScript 5.4, which lets you take advantage of new features such as preserved narrowing in closures following last assignments. 2. Global Observable in Angular Forms: Angular 18 introduces a global events observable in Angular forms, which allows you to track all changes around any abstract control and its children, including the touched or dirty in a single observable. Here's an example of how you can use the global observable: ` 3. Stable Deferrable views: Deferrable views are now stable in Angular 18. 4. Stable Control Flow: The built-in control flow is now stable in Angular 18! It is more performant than its predecessor. It also received improved type checking, including guardrails for certain performance-related anti-patterns. 5. Route Redirects as Functions: For added flexibility in managing redirects, Angular v18 now lets you use a function for redirectTo that returns a string, which allows you to create more sophisticated redirection logic based on runtime conditions. For example: ` Conclusion Angular 18 is a significant release that brings many new features, enhancements, and experimental APIs to the Angular ecosystem. The introduction of zoneless change detection, improvements to server-side rendering and hydration, stable Material Design 3 support, signal-based APIs, and fallback content for ng-content are just a few of the highlights of this release. The Angular team has again demonstrated its commitment to improving the framework's developer experience, performance, and flexibility. It also demonstrated a clear vision for Angular's future. If you're curious about what's next, you can check out the Angular roadmap....

May 29, 2024

3 mins

AngularJavaScript

Overview of the New Signal APIs in Angular

Overview of the New Signal APIs in Angular Google's Minko Gechev and Jeremy Elbourn announced many exciting things at NG Conf 2024. Among them is the addition of several new signal-based APIs. They are already in developer preview, so we can play around with them. Let's dig into it, starting with signal-based inputs and the new matching outputs API. Signal Based Inputs Discussions about signal-based inputs have been taking place in the Angular community for some time now, and they are finally here. Until now, you used the @Input() decorator to define inputs. This is what you'd have to write in your component to declare an optional and a required input: ` With the new signal-based inputs, you can write much less boilerplate code. Here is how you can define the same inputs using the new syntax: ` It's not only less boilerplate, but because the values are signals, you can also use them directly in computed signals and effects. That, effectively, means you get to avoid computing combined values in ngOnChanges or using setters for your inputs to be able to compute derived values. In addition, input signals are read-only. The New Output I intentionally avoid calling them signal-based outputs because they are not. They still work the same way as the old outputs. The Angular team has just introduced a new output API that is more consistent with the latest inputs API and allows you to write less boilerplate, similar to the new input API. Here is how you would define an output until now: ` Here is how you can define the same output using the new syntax: ` The thing I like about the new output API is that sometimes it happens to me that I forget to instantiate the EventEmitter because I do this instead: ` You won't forget to instantiate the output with the new syntax because the output function does it for you. Signal Queries I am sure most readers know the @ViewChild, @ViewChildren, @ContentChild, and @ContentChildren decorators very well and have experienced the pain of triggering the infamous ExpressionChangedAfterItHasBeenCheckedError or having the values unavailable when needed. Here is a refresher on how you would use these decorators until now: ` With the new signal queries, similar to the new input API, the values are signals, and you can use them directly in computed signals and effects. You can define the same queries using the new syntax: ` Jeremy Elbourn mentioned that the new signal queries have better type inference and are more consistent with the new input and output APIs. He also showcased a brand new feature not available with the old queries. You can now define a query as required, and the Angular compiler will throw an error if the query has no result, guaranteeing that the value won't be undefined. Here is how you can define a required query: ` Model Inputs Jeremy and Minko announced the last new feature is the model inputs. The name is vague, but the feature is cool—it simplifies the definition of two-way bindings. Until now, to achieve two-way binding, you would have to define an input and an output following a given naming convention. @Input and @Output had to be defined with the same name (followed by "Change" in the case of the output). Then, you could use the template's [()] syntax. ` ` That way, you could keep the value in sync between the parent and the child component. With the new model inputs, you can define a two-way binding with a single line of code. Here is how you can define the same two-way binding using the new syntax: ` The html template stays the same: ` The model function returns a writable signal that can be updated directly. The value will be propagated back to any two-way bindings. Conclusion The new signal-based APIs are a great addition to Angular. They allow you to write less boilerplate code and make your components more reactive. The new APIs are already in developer preview, so you can start playing around with them today. I look forward to seeing how the community will adopt these new features and what other exciting things the Angular team has in store for us, such as zoneless apps by default....

Apr 3, 2024

3 mins

AngularJavaScript

VSCode Keyboard Proficiency

Introduction The tools used in the programming craft are varied and the ones developers use depend on the kind of work they are doing. However, two of these tools are omnipresent: the keyboard and the text editor. As such, learning how to use these tools effectively is crucial. This blog is an introductory guide on using and configuring VSCode (one of the most popular IDEs among programmers) to maximize your productivity and proficiency with the keyboard. Here are some notes about what you should expect from it: - We will be using a fresh installation of VSCode for this guide. - We will be configuring the keybindings for the Mac keyboard. It is up to you to set it up to your liking in your OS of choice. - This guide is not a comprehensive guide to VSCode, but an introduction to maximizing keyboard usage in VSCode. That being said, let's get started! The Keyboard Shortcuts Editor The first command we will learn is the command to open the keyboard shortcuts editor. The command's name is workbench.action.openGlobalKeybindings, and it is bound to Cmd+K Cmd+S by default. Let's try it. Press Cmd+K Cmd+S, and you should see the keyboard shortcuts editor open up. This is where you can modify the default keybindings of VSCode. This command opens the keyboard shortcuts editor, which is a JSON file that contains all of the keybindings that are currently in effect. The keybinding is the key combination that triggers the command. The command is the name of the action performed when the keybinding is pressed. The When column contains the conditions that must be met for the keybinding to be active. Finally, the Source column contains the extension's name that defines the keybinding. If an extension includes the keybinding, the source will be the extension's name. If VSCode determines the keybinding, the source will be Default. Movements Cursor movements are the most common actions we perform when reading or writing code. The cursor movement could be done in a single file between multiple files, between consecutive lines, or from one line to another located 100 lines away. This is the skill you will use the most and, therefore, where we will lose the most time if we use the mouse. The following are the most common ways to move the cursor around the text. Single unit cursor movement -- Arrow Keys The beginning of this journey starts with the arrow keys. We are most tempted to use this all the time since it is the most intuitive of the movements with nearly zero mental overload. However, the arrow keys are not the actual name of this movement. We are actually referring to four movements: cursorLeft, cursorRight, cursorUp, and cursorDown. These are the commands that are bound to the arrow keys by default. Horizontal Movement. Word cursor movement Although moving the cursor one character at a time was not a big deal for that contrived example, let's see what happens if we try to hit the 🎯 on a long line. Please give me the mouse! Just kidding, we are not going to use the mouse. We are locked with the keyboard, but even I was tempted. Then, how do we get faster? We can use the word cursor movements to improve our efficiency. The main two cursor word movements are the cursorWordLeft and cursorWordEndRight; they will allow us to move one word at a time. By default, movements are bound to Option+Left and Option+Right, respectively, but again feel free to customize everything to your liking. As we can see on the Word Cursor Movements Configs image, we can use many more word movements. Feel free to explore them and see what they do. Ok, no more talk, let's show our new movements. That's better. Our speed of moving around in a line has improved significantly. There are, however, some observations to make. Firstly, we move nearly to the end of the "visible" line one word at a time. If we started from the end of the line, we would have to make fewer movements. Secondly, we have no idea where the line ends because it overflows out of the editor's viewport. To fix the line overflow, we need to change a configuration setting. The setting is editor.wordWrap, which is set to off by default. Much better. Now we can actually tell where the cursor is at any moment. Horizontal Movement. Line start/end cursor movement Now that we can visualize where the cursor can be placed at any moment in the line, we can optimize our previous movement by moving the cursor to the end of the line before reaching the 🎯. We will use the cursorEnd and cursorHome commands. By default they are bound to Cmd+Right and Cmd+Left respectively. Yes, that was a lot better. We can now move the cursor to the end of the line and then move one word at a time to the 🎯. However, we know that's not really the end of the line. That's the end of the editor viewport. We have some movements if we really need to move to the end or start of the line. The cursorLineEnd and cursorLineStart commands do exactly that. They are bound to Ctrl+A and Ctrl+E, respectively. Let's see it in action. I don't use these movements very often because I spend most of my time editing code which is usually formatted to fit the editor viewport width. For that reason, I have overridden one of these commands with something more valuable to me that I'll show you later. Horizontal Movement. Bonus and Sneak Peek We have covered so far the most common horizontal movements. However, there is another helpful movement that I'll cover next, but I guess I can tell you something about it now. The workbench.action.gotoLine lets you move the cursor to a specific line, and a particular character or column. Alright, that covers up the horizontal movements. Now practice them until you can do them without thinking. Vertical Movement. Lines cursor movement Horizontal movements are great, but after wrapping your lines and formatting the code, the text will fit the editor's viewport making vertical movements the most common type. The most basic form of vertical movement is the cursorUp and cursorDown commands using the arrow keys, as shown in the first movement section. But as we have seen before, this is very inefficient. Don't believe me? I'll show you. Let's take this example to the ThisDot Open Source repository. Ugly! And that's just a few lines. Imagine if we had to move the cursor 100 lines up or down. We would be here all day. Luckily for us, there are some more efficient ways to move the cursor up and down. Vertical Movement. Top and Bottom of the file As with the line start/end movements, we can move the cursor to the top or bottom of the file. The commands are cursorTop and cursorBottom and by default they are bound to Cmd+UpArrow and Cmd+DownArrow respectively. These are primarily useful when you know that the line you are looking for is near the top or bottom of the file. But in long files, this is not always the case. Vertical Movement. Go to Line Until now, we still don't have an efficient way to move across lines. Lucky for us, we can move the cursor to any line in the file with the global goto line movement. The command is workbench.action.gotoLine, and is bound to Ctrl+G by default. With this movement, we can move the cursor to any line in the file in just a few keystrokes. We can also move the cursor to a specific character or column on that line. And we can further optimize. The workbench.action.gotoLine command requires us to type the global line number. For long files with hundreds or thousands of lines, the number of digits to type increases along with the frequency of typos. Additionally, we must look carefully at the line number before moving the cursor to the line. Vertical Movement. Go to relative line Relative line numbers and a relative goto movement would solve these problems. However, the relative goto feature is not available out of the box in VS Code, but we can add it with the Relative Goto extension. This extension does a few things for us: It turns on the relative numbers setting. And it adds a keybinding called relative-goto.goto, bound to Cmd+G by default. But first, we need to change the default keybinding. The reason is that the Cmd+G keybinding is already used by the editor.action.nextMatchFindAction command. I like to use Cmd+L for this command because it is an excellent mnemonic for Line. Before anything, yes, I used the mouse to change the keybinding. I know I'm a terrible person. With that out of the way, let's see how it works. Yes, much better! We have reduced the overhead of moving the cursor to a global line. And if you notice, we can move to a previous line using negative numbers. Hydration Pause -- Selection Let's take a break from our keyboard mastery path and use this pause to cover something intrinsically related to cursor movement: text selection. All the movements that we have covered so far have a selection counterpart. For example, the cursorLeftSelect command selects the character to the left of the cursor. The cursorWordEndRightSelect command selects the word to the right of the cursor. And so on. The relative goto movement also has its selection counterpart. It is the relative-goto.select command. The command is bound to Cmd+S, an apparent mistake because it collides with the save keybinding. In my case, I have changed it to Cmd+Option+L. Why not Cmd+Shift+L? This is because I use that keybinding for the expandLineSelection command. Let's see them all in action to make clear what I mean. There are many more selection movements, but that clip exemplifies what's possible. Vertical Movement. Scrolling Editor Often, we need to go to a line outside our current page. We could try to find a word (Cmd+f) that we know is in that line. Or we could try to go directly to a symbol near that line if we know the symbol's name (Cmd+Shift+O). But we likely won't know where the line is, and will scroll to find it. USING THE MOUSE. Well, not anymore. Scrolling is also possible using the keyboard! We can use one line scroll commands by using scrollLineUp and scrollLineDown bound to Ctrl+PageUp and Ctrl+PageDown by default. Additionally, we can use one page scroll commands by using scrollPageUp and scrollPageDown bound to Cmd+PageUp and Cmd+PageDown by default. Fantastic, with these movements, we are now mouse free when scrolling through the file. However, when scrolling large files, the relative line goto will have the same problems the global line number goto had. A tool to solve this issue is the Scroll with Stationary Cursor extension. This extension adds two new keybindings that keep the cursor static to the editor viewport while scrolling. The commands are extension.scrollWithCursorUp and extension.scrollWithCursorDown bound to Ctrl+Option+Cmd+UpArrow and Ctrl+Option+Cmd+DownArrow by default. Since it is my primary way of scrolling the editor, I have changed the keybinding to Ctrl+PageUp and Ctrl+PageDown, replacing the regular line scroll commands. The last scrolling trick is the Scroll to Cursor extension. This extension adds a new command called scrollToCursor bound to Ctrl+L by default. This command will scroll the editor, so the cursor is near the top of the viewport. That's all for scrolling; make sure that you explore all the other extensions and keybindings that VS Code provides for scrolling. There are many more that I didn't cover here. Multiple Groups Movement So far, all the examples we have seen use a single group or panel. To maximize my efficiency, I usually work with two or three VSCode groups side by side. The next set of movements will focus on interacting with VSCode groups. For simplicity, we will focus on two vertical groups, but the same concepts and techniques will apply to having several vertical or horizontal groups. The easiest and quickest way to create a new group is by using the workbench.action.splitEditor command. This command is bound to Cmd+\ by default, and it will split the current group in two, creating the new one to the right of the current group and moving the focus and the cursor to the newly created group. This technique is beneficial when we want to work over two different sections of the same file. But what if we want to work on a different file? For that, we can use the workbench.action.focusSecondEditorGroup command. This command is bound to Cmd+2 by default, and it will create a new group if there is only one and move the focus to the newly created group. If there are already two groups or more, it will move the focus to the second one from left to right. It removes the overhead of needing a command for the creation and another for focus. Now let's learn how to move between groups. For that, we can use the workbench.action.focusRightGroup and workbench.action.focusLeftGroup commands. These commands are bound to Cmd+K Cmd+Right and Cmd+K Cmd+Left by default, but since I don't use the next and previous editor commands I have changed it to Cmd+Option+Right and Cmd+Option+Left. There is one detail. These commands are not circular, which means that if you are in the last group to the right, Cmd+Option+Right will not move the focus to the first group. Just keep that in mind. Fantastic! But what if we want to move a file from one group to another? VSCode has you covered, with the workbench.action.moveEditorToNextGroup and workbench.action.moveEditorToPreviousGroup commands. These commands are bound to Ctrl+Cmd+Right and Ctrl+Cmd+Left by default. Additionally, if we don't have a second group, these commands will create one and move the file. Code Interactions Everything we have covered until this point has been navigating our files and groups. It is time to learn new keyboard shortcuts to improve how we interact with our code. Quick Fix The editor.action.quickFix command is one of the essentials of VSCode. This command is bound to Cmd+. by default and will show the current word, line, or symbol's quick fix suggestions. It is helpful for compilation or linting errors and typos or missing imports. It replaces the need to use the mouse to click on the light bulb that appears in the gutter. Hover and Peek As the "quick" in "quick fix" implies, sometimes VSCode is not intelligent enough to understand how a given problem could be fixed. Or sometimes, the solutions can be ambiguous without knowing what the problem is, and its context. In these cases, our first instinct is to hover over the error and see what the problem is. But what if I tell you that you can do that without moving your hands from the keyboard? For that, the editor.action.showHover command exists. This command is bound to Cmd+K Cmd+I by default, and it will show the hover information for the current line. I simplified its keybinding, and made something more memorable for me; I changed it to Ctrl+H and removed the other conflicting keybindings. This command is not only beneficial for errors, but also for inspecting any piece of code. But if we want to focus on an error, we have another command. The editor.action.marker.nextInFiles will walk us around the current file's errors, warnings, and other markers in sequential order. The command is bound to F8 by default, but I hooked it to Ctrl+E to make it easier for me. If we want to move to the previous marker, we can use the editor.action.marker.prevInFiles command bound to Shift+F8 by default, and again I modified it to Ctrl+Shift+E. Context Menu Adding to the list of things you would never imagine doing without the mouse, I bring you the editor.action.showContextMenu command. This command is bound to Shift+F10 by default, and will show the current line's contextual menu. Like with the hover command, I tried to assign a more memorable keybinding. I changed it to Ctrl+M. Refactor I already gave you a sneak peek of the following command. The refactor command allows us to... well, refactor our code. It is bound to Ctrl+Shift+R by default, and will show the current line's refactor menu. It might not be as powerful as WebStorm refactoring capabilities, but I hardly ever need more than VSCode offers. Go to Definition One of the most common actions when interacting with code is visiting the definition of a given symbol. With the editor.action.revealDefinition command, we can explore an element's declaration, type, implementation, and documentation and learn more about it. This command is bound to F12 and includes a hidden trick few people know. If executed over the definition of the symbol, it will show us its references instead. Since I use this command very often, I have to change the keybindings to Cmd+Enter. That way, we don't have to move our fingers from the center of the keyboard. Go Back and Go Forward With all the commands learned so far, we will be jumping through code all the time, reading, and editing. What happens if we want to return to a previously visited point? Fortunately, the editor keeps track of the current cursor positions allowing us to navigate forward and backward the cursor history. This ability is attached to two commands, workbench.action.navigateBack and workbench.action.navigateForward. These commands are bound to Ctrl+- and Ctrl+Shift+- by default, but I changed such useful commands to something I would remember. I use Ctrl+[ and Ctrl+] respectively. Folding regions Sometimes we want to focus on substantial parts of the file or the function we are working on, avoiding the cognitive burden of everything that might happen in a file. VSCode will help identify foldable blocks out of the box based on the syntax used. Then the fold and unfold commands can collapse and expand these regions allowing us to focus. These commands are editor.fold and editor.unfold, respectively, and are bound to Cmd+Option+[ and Cmd+Option+] by default. The result is what we wanted, but to get there, we had to move a lot across the code and execute the command several times. A better way is to use the editor.foldAll and editor.unfoldAll commands, bounded to Cmd+K Cmd+0 and Cmd+K Cmd+J by default. That was a bit better but still not ideal. Why can't we fold everything but the block we are standing on? Well, we can; there is a command for that. It is called editor.foldAllExcept and is bound to Cmd+K Cmd+- by default. To have even more control, VSCode added the possibility to create custom fold regions. Consider it homework to learn how to do it. Deleting Code I have a serious question: Is there anything more fun than deleting code? Ok, I know that is not a serious question, but I am serious about the answer. Deleting code is the best! And VSCode makes it even better with the editor.action.deleteLines command. This command is bound to Cmd+Shift+K by default and will delete the line under the cursor. Yes, we can do the same with Cmd+X, but the difference is that Cmd+X will copy the deleted line into the clipboard, and Cmd+Shift+K will not. If you want to see the line disappear and prefer your clipboard clean, Cmd+Shift+K is the way to go. > There is another difference. See where the cursor is after executing both commands. The entire line is too much? Instead, we can remove everything to the left or right of the cursor. The editor.action.deleteAllLeft and the editor.action.deleteAllRight commands will do exactly that. These commands are bound to Cmd+Backspace and Cmd+Delete by default. What else can we delete? Words! We can delete words. The deleteInsideWord command will delete the word below the cursor. This command has no keybindings by default, but I like to assign it to Ctrl+Backspace. But that's not all, the editor.action.deleteWordLeft command will delete the word to the left of the cursor, and the editor.action.deleteWordRight command will delete the word to the right of the cursor. If the cursor is in the middle of a word, it will partially delete it. These commands are bound to Option+Backspace and Option+Delete by default. Moving and Cloning lines Maybe mayhem is not your thing; maybe you feel more joy when moving things around like a house decorator or a creative Minecraft player. VSCode has you covered with the editor.action.moveLinesUpAction and editor.action.moveLinesDownAction commands. These commands are bound to Alt+UpArrow and Alt+DownArrow by default and will make you happy. Are you more of the scientific type? What about cloning some lines? The commands editor.action.copyLinesUpAction and editor.action.copyLinesDownAction will do just that. These commands are bound to Shift+Alt+UpArrow and Shift+Alt+DownArrow by default. Multiple Cursors This section covers one of my favorite features of VSCode, the multiple cursors. This feature is not unique to VSCode and was implemented successfully in other editors like Sublime Text and Atom. However, VSCode has nailed it, and it's something I feel I couldn't live without. Insert cursor on next line There are some instances where you have similar lines of code next to each other, and you want to make a change in all of them. For example, if you have a list of private properties that you want to make protected, you could find and replace all of them, but that would be a bit tedious, especially if the file has other properties that you don't want to modify. Or maybe you have several objects with a similar signature and want to add a new property to all of them. You can use the editor.action.insertCursorBelow command in these cases. This command is bound to Cmd+Option+DownArrow by default. I hope you appreciate the power of this command. There is a caveat, though. We saw in a previous chapter that VSCode has two representations for what a line of code is. The first is the actual line of code represented by the lack of a line break in a set of text, and the second is the artificial line created by VSCode when the wrap text setting is on. The editor.action.insertCursorBelow command will only work on the first type of line. To insert a cursor below in an artificial line, you can use the cursorColumnSelectDown command. This command is bound to Cmd+Option+Shift+DownArrow by default. The following example shows the differences between the two commands and, in this case, using the editor.action.insertCursorAbove and cursorColumnSelectUp variants. Selecting next occurrence Returning to our first example of changing the visibility of a property, there are a couple of things that we can do better. For example, with the editor.action.insertCursorBelow, we are dependent that the lines we want to edit are one below to other. Additionally, we had to create the cursor and select the visibility keyword. We can do better. The editor.action.addSelectionToNextFindMatch command will select the next occurrence of the word under the cursor. This command is bound to Cmd+D by default. This gives a low extra grip on what we want to edit. The words could be at any position, and the command would still work. Its broader version is the editor.action.changeAll, which will select all word occurrences under the file's cursor. This command is bound to Cmd+F2 by default, but since I like it so much, I have changed it to Option+Shift+D. There are some variations of this command that I'll mention, but let you find and customize to your liking. The editor.action.addSelectionToPreviousFindMatch command will select the previous occurrence of the word under the cursor; it is unbound by default. The editor.action.moveSelectionToNextFindMatch command will move the cursor to the next word occurrence under the cursor. This command is bound to Cmd+K Cmd+D by default. The editor.action.moveSelectionToPreviousFindMatch command will move the cursor to the previous occurrence of the word under the cursor. This command is unbound by default. Cursor Undo To close this section, I want to show you how to undo a mistake with multiple cursors. The cursorUndo command will undo the last cursor operation. This command is bound to Cmd+U by default, which is advantageous when handling many cursors simultaneously. That's the perfect closing for this chapter. See you in the next one. Main Sidebar Tools The VSCode main sidebar contains some of the most essential tools for a developer. The Explorer, the Search, the Source Control, the Extensions, and many others could be native, or added through extensions. This is our final chapter. Here we will cover the Explorer and the Search tools since these are probably the most used ones. The knowledge we will gain in this chapter can be applied to any other side menu tool. Explorer The explorer is possibly the most used tool in VSCode. It is where we can see all the files and folders in our project. It is also where we can create, rename, delete, and move files and folders. Our natural instinct when seeing a file explorer is to use the mouse to navigate through the files and folders. However, VSCode has a powerful keyboard navigation system that will allow us to navigate through the explorer without touching the mouse. First things first, how do I open it? The workbench.view.explorer command is what you want. The command is bound to Cmd+Shift+E by default, but additionally to this, I have also included the Ctrl+1 keybinding. That way, I can have a unified way to open all my sidebar tools. That's cool. Now let's start moving around. The explorer has a tree structure, so we can move up and down the tree using the list.focusUp, and list.focusDown commands. These commands are default bound to Up and Down. Additionally, we can expand or collapse a subtree using the list.expand and list.collapse commands. These commands are default bound to Right and Left. Notice that if one of the focus commands on a collapsed subtree, it focuses on the collapsed node. But if the subtree is expanded, the actions will focus on one of its children. From the movement perspective, this can be all you need, but there are two other movements that I like to use. These are the list.focusFirst and the list.focusLast, which will move the focus to the first and last node in the explorer, respectively. These commands are default bound to Home and End. However, I like to use Cmd+UpArrow and Cmd+DownArrow for these actions, and keep consistency with what I use in the editor. However, these new keybindings are in conflict with other commands. Therefore, I removed the conflicting commands. - For the Cmd+UpArrow keybinding are the list.collapse and list.scrollUp - For the Cmd+DownArrow keybinding are the explorer.openAndPassFocus, list.select and list.scrollDown Lovely, now that we can move around the explorer, the next step is to preview a file content without opening it and losing focus of the explorer. This is helpful when we are unsure of the content of the files of a project. The command VSCode exposes for us to do this is the filesExplorer.openFilePreserveFocus, which is bound to Space by default. However, we sometimes need to open a file and immediately switch focus to start working on such a file. The explorer.openAndPassFocus command opens the focused file on the explorer and switches focus to the editor. This command is bound to Cmd+DownArrow by default, but we removed that binding earlier in this section. It is up to you to configure this keybinding in a way that makes the most sense, but I like using Cmd+Enter for this action. Similarly, we can open a file in a new editor group using the explorer.openToSide command defaulted to Ctrl+Enter. That's all we need to know about opening files to be effective with the keyboard. The big missing part is creating, renaming, deleting, and moving files and folders. Let's start with creation. We can use the explorer.newFile command to create a new file on the focused folder. This command is unbound by default, so I have reassigned it to Option+Cmd+N. Of course, sometimes we just want to create a folder where we can drop files later. The command that enables folder creation is the explorer.newFolder command. This command is unbound by default. You can use whatever makes sense to you. I got accustomed to using Cmd+N+F. Files and folders can get created and also get destroyed. We can use the moveFileToTrash command to delete a file or folder. This command is bound to Cmd+Backspace by default. > You might notice that when deleting a file or folder in your IDE, you will be prompted to confirm the action. I have checked the not ask again option, and that's why the prompt is not showing on the video. Excellent, creating and deleting files are prevalent tasks; it is great we covered them, but sometimes we don't want to delete a file. We just want to rename it. The explorer.rename command will allow us to rename a file or folder. This command is bound to Enter by default. That's superb. To complete this section, we must cover how to move and copy files and folders. Copying a file or folder is as simple as using the filesExplorer.copy command. This command is bound to Cmd+C as you would expect to do in _Finder_. But copying is just the first half of the equation; we also need to paste. The filesExplorer.paste command will allow us to paste the copied file or folder. This command is bound to Cmd+V by default. Although there are different ways of moving a file, the easiest and more intuitive way is similar to copying and pasting. You might imagine how by now. You are right, the old cutting and pasting. We can use the filesExplorer.cut command to cut a file. This command is bound to Cmd+X by default. And the paste command is the same one we already saw. And this closes the cycle. Using the keyboard, we can now create, rename, delete, move and copy files and folders. There might be better ways of achieving the same results, let me know on Twitter what you find, but this gives us a good starting point and free us from the mouse. Search Let's take a moment to appreciate the road covered so far. I could say that at this moment, we could spend 95% of our time in VSCode using the keyboard. This final module would even improve on that number. We are going to learn about the search functionality of VSCode. I don't remember a day that has passed without me performing a global search in VSCode. This feature allows us to perform a filter-rich text search across all the files in a project. The first thing to do is open the search view. The command that does this is the workbench.action.findInFiles command. This command is bound to Cmd+Shift+F by default. Once the search input is focused, we can start typing our search query. This is exciting, but we need to be able to move around the search results. There are different ways to achieve this, but the easiest is using the search.action.openResult command. This command is bound to Cmd+DownArrow by default, and will move the focus to the search results list. You will notice that iterating over the search results is very similar to iterating over the explorer nodes, with the difference that the files will preview automatically. To open the focused search result and move the focus to the editor, use the search.action.openResult bound to Enter by default. Fantastic, that's all we need to solve the most significant part of our search needs. But we can do some other things with the search view that are worth mentioning. Are you ready for something special? It is a secret; I need you to trust me for a second. First, go to your keybindings configuration and set the search.action.openNewEditor to the command you prefer. I'm using Cmd+Shift+f replacing the workbench.action.findInFiles and workbench.view.search.focus set to that keybinding by default. Ready? Let's give it a try. You might ask yourself: "What is that, and how does it work?" The why is Search Editors, a feature that was added to VSCode in version 1.43, that's February of 2020. Crazy, right, that was there all this time, and nobody knew. Well, maybe some people knew, but I didn't. It works by opening the global search results in a full-sized editor, allowing us to use all the tricks we learned so far to move our cursor around a file, but in this case, that file contains the search results. Let's open our editor again and use relative lines goto move to place the cursor over the desired search result. Then we can use the editor.action.revealDefinition command to open the result file. This command is bound to Cmd+Enter as seen before. > For the results "Go to definition" command to work, you might need to remove the keybinding for search.action.openInEditor or change it to something different. Among the actions, I use the most with the search is the search.action.focusQueryEditorWidget command, which would take the focus back to the search input and is bound to Esc by default. The search.action.focusNextSearchResult will show us to move the focus to the following search result, which is bound to F4 by default, although I like to bind it to Cmd+Option+Enter. And the search.action.focusPreviousSearchResult will move the focus to the previous search result, and it is bound to Shift+F4 by default, but I modify it to Shift+Cmd+Option+Enter. To delete a search result from the IDE we use search.searchEditor.action.deleteFileResults command. This command is bound to Cmd+Shift+Backspace by default, and it is handy to remove results that are not relevant anymore. The last two commands I want to mention are the toggleSearchEditorCaseSensitive and toggleSearchEditorWholeWord commands. These commands are bound to Cmd+Option+C and Cmd+Option+W by default and will toggle the search's case-sensitive and whole word options. And that's all we will cover in this article, but there is a lot more. For example, as seen we the case sensitive and whole word options, we could also toggle the regex mode. I recommend you also play with the Search Editor: Apply changes Extension that persists the modifications made to the search results visible code in the original files. Conclusions The road to achieving keyboard proficiency in VSCode starts with you. What we have covered in this article is necessary to escape the tyranny of the mouse in the most common scenarios. However, there is still much to learn and master inside VSCode. More than that, VSCode itself will show you its limitations with time if you push hard enough. Luckily, we, as developers, can extend VSCode behavior and create our own extensions to bypass these limitations. Nevertheless, if you are truly passionate about becoming a keyboard wizard, I encourage you to explore other IDE like the Vim family. I hope this helped....

Nov 2, 2022

31 mins

VSCode

Building a Stripe App: A Step-by-Step Guide to QR Code Generation

Building a Stripe App: A Step-by-Step Guide to QR Code Generation Why Build a Stripe App? I recently participated in an audio space with the Stripe team, and something they said really stuck with me: the Stripe app store is a growing area that isn't overly saturated yet. There's a lot of potential for new apps, and companies can use this opportunity to grow. I work at a company called This Dot Labs, and we've created several Stripe apps and even own one. After looking at the data, I can confirm that the Stripe team was right! Creating a QR Code Generator App For this tutorial, we'll build a QR code app that can take a URL and generate a code for it. This is a good use case to help you understand the ins and outs of Stripe's developer tools. Why QR Codes? QR codes are useful tools that have become common in e-commerce, restaurants, and other industries. While Stripe already has a QR code tool, we'll make our own to familiarize ourselves with their syntax and problem-solving approaches. Project Structure Before we dive into the implementation, let's look at the structure of our Stripe App QR Code project: * .vscode: Contains settings for Visual Studio Code * source/views: Holds the main application views * .gitignore: Specifies files to ignore in version control * stripe-app.json: Defines the Stripe app configuration * ui-extensions.d.ts: TypeScript declaration file for UI extensions * .build: this is where the built Stripe app gets placed. Step-by-Step Implementation 1\. Install Stripe Locally First, you need to install Stripe on your local machine. The documentation provides great instructions for this: * For Mac users: Use Brew to install * For Windows users: Download the package and add it to your environment variables You can find the details here in the stripe docs to install the Stripe CLI https://docs.stripe.com/stripe-cli When using Windows, you must do stripe login from Powershell, NOT from Git bash or any other tool. After the server is up, then you can continue using git bash for everything else. After stripe login, you need to enter stripe apps start. Once you do that, the server is up and running and you can go back to using git bash or any other tool. 2\. Install Dependencies We'll be using an extra package for QR code generation. Install it using npm: ` 3\. Set Up the Main Component Let's look at the home.tsx file, where we'll use Stripe's UI components: ` These components are similar to other UI libraries like Bootstrap or Tailwind CSS. 4\. Create the UI Structure Our app will have: * An input field for the URL * Validation using a regex pattern * Error handling for invalid URLs * QR code generation and display Here is the Home.tsx file that is located in the src/views folder ` * ContextView` is at the top level of the app where we see the Title and the link to the Stripe Docs that we placed in our Context View. * Box is how you use Divs. * Banners can be used to show notification errors or any other item you wish to display. * Textfields are input fields. * Everything else is pretty self-explanatory. 5\. Handle Content Security Policy One problem I personally ran into was when I tried to redirect users, the Stripe policies would block it since I did not express that I knew what it was doing. I had to go into the stripe-app.json file and mention the specific security policies. For this particular exercise, I kept these as null. This is my stripe-app.json file. ` 6\. Configure App Views As you can see here, the stripe-app.json file shows the views for each file I have. The Home.tsx file and the Invoice.tsx are also included This is our way of saying that for each view we have, show the app functionality on that page. Our stripe-app.json file will show it but also, the manifest.js file in our .build folder will also show the same. Any view that doesn't have a file will not show the application's functionality. So, if I were to go to transactions, the app would not show the same logic as the home or invoices page. By following these steps, you'll have a fully functional QR code generator app for Stripe. This is just a simple example, but the potential for Stripe apps is massive, especially for businesses serving e-commerce customers. If you need help or get stuck, don't hesitate to reach out, danny.thompson@thisdot.co. The Stripe team is also very active in answering questions, so leverage them as a resource. Happy coding!...

Dec 18, 2024

4 mins

stripe

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Plugin Architecture for Angular Libraries using Dependency Injection

Plugin Architecture

Plugin-based Angular Libraries

Implementing a Plugin Architecture with Dependency Injection

The Angular code

The core system

The Plugins

Usage

Conclusion

Nacho Vazquez

You might also like

Angular 18 Announced: Zoneless Change Detection and More

Overview of the New Signal APIs in Angular

VSCode Keyboard Proficiency

Building a Stripe App: A Step-by-Step Guide to QR Code Generation

Let's innovate together!

You might also like

Angular 18 Announced: Zoneless Change Detection and More

Overview of the New Signal APIs in Angular

VSCode Keyboard Proficiency

Building a Stripe App: A Step-by-Step Guide to QR Code Generation