Forem: Philippe Vaillancourt

Vite Tips: Conditional Configs and Aliases

Philippe Vaillancourt — Mon, 02 Sep 2024 16:06:13 +0000

When it comes to front-end development, especially for game jams like JS13k, having a streamlined build process is crucial. In this post, we’ll explore how to leverage Vite, a modern front-end build tool, to optimize your development workflow. We’ll dive into what Vite is, introduce JS13k and LittleJS, and show you how to use Vite's conditional configuration and resolve aliases, with code examples, to get the most out of your development setup.

What is Vite?

Vite is a fast, opinionated build tool designed to provide a smoother development experience. Unlike traditional tools like Webpack, Vite offers a lightning-fast development server with hot module reloading (HMR) out of the box. It’s designed to be minimalistic, with great defaults, but also highly configurable to suit more advanced needs.

What is JS13k?

JS13k is an annual game jam where developers are challenged to create web-based games that must fit within a 13 kilobyte zip file. This strict size limit pushes developers to write extremely efficient code, often resorting to creative ways to reduce the size of their game assets and code.

What is LittleJS?

LittleJS is a lightweight JavaScript game engine designed to help developers build small, performant games for the web. It’s particularly popular in competitions like JS13k because of its small footprint and efficiency. LittleJS provides all the basics you need to get a game up and running, while still being small enough to help you meet those tight JS13k size constraints.

Using Conditional Configuration in Vite

One of Vite’s powerful features is its ability to handle conditional configurations. This is particularly useful when you need different settings for development and production builds. For example, you might want to use a debug version of a library during development but switch to a minified version for production.

Here’s how you can set up conditional configuration in Vite, using TypeScript:

import { defineConfig } from 'vite';
import path from 'path';

export default defineConfig(({ mode }) => {
  return {
    resolve: {
      alias: {
        'littlejsengine': mode === 'production'
          ? dist/littlejs.esm.min.js'
          : dist/littlejs.esm.js'
      }
    },
    // Other configurations can go here...
  };
});

In this example, we use Vite’s defineConfig function to set up different configurations based on the build mode (development or production). The mode parameter allows us to determine which version of LittleJS to use. The debug version (littlejs.esm.js) is used in development, providing useful console logs and assertions, while the minified version (littlejs.esm.min.js) is used in production to keep the final bundle size as small as possible.

Using Resolve Aliases in Vite

Resolve aliases in Vite allow you to remap module imports, making it easier to switch between different versions of a library or package. This feature is particularly useful in cases where a package provides multiple builds (e.g., debug vs. production versions).

Continuing from the previous example, the resolve.alias field in Vite’s configuration is where you can set up these aliases. Here’s how it works:

import { defineConfig } from 'vite';
import path from 'path';

export default defineConfig(({ mode }) => {
  return {
    resolve: {
      alias: {
        'littlejsengine': mode === 'production'
          ? dist/littlejs.esm.min.js'
          : dist/littlejs.esm.js'
      }
    },
    // Other configurations can go here...
  };
});

In this example, any time you import LittleJS in your code, Vite will use the path specified in the alias. This is incredibly useful when you want to enforce the use of a specific build of LittleJS across your project without having to change import statements throughout your codebase.

Why These Features Matter

For a competition like JS13k, every byte counts. By using conditional configuration and resolve aliases, you can ensure that your development environment is optimized for debugging, while your production builds are as small as possible. This not only helps you meet the strict size limits of JS13k but also improves the overall performance of your game.

Vite’s flexibility allows you to easily switch between different configurations, making your workflow smoother and more efficient. Whether you’re working on a small game for JS13k or a larger project, these features can save you time and headaches.

Conclusion

Vite is a powerful tool that, when used effectively, can greatly enhance your development process. By mastering conditional configurations and resolve aliases, you can ensure that your projects are optimized for both development and production environments. And when combined with tools like LittleJS, Vite becomes an essential part of your game development toolkit, especially for challenges like JS13k.

So, dive into Vite, explore its capabilities, and start building faster, more efficient games today!

The Problem with Eating an Elephant One Bite at a Time

Philippe Vaillancourt — Mon, 19 Aug 2024 20:03:32 +0000

You've probably heard it before: when faced with a massive task, someone will inevitably try to motivate you with the famous phrase, "You eat an elephant one bite at a time."

But here's the thing—I call b.s. on this metaphor. While it sounds comforting, it falls apart when applied to truly big, daunting tasks. We're not talking about something you can knock out in a day or two; we're talking about multi-week, month, or even year-long projects. The "eating an elephant" metaphor isn't just unhelpful for such projects—it actually highlights the problems with tackling them "one bite at a time."

Let's break it down. An average male African elephant weighs around 6,000 kilograms (13,227 pounds). A typical bite of food might weigh about 15 grams (0.033 pounds)—roughly the size of a small piece of steak. So, we're talking about 400,000 bites to eat the entire elephant.

Now, if each meal consists of 50 bites, it would take 8,000 meals to finish the elephant. At three meals a day, that's 2,700 days, or 7.3 years, of eating nothing but elephant for breakfast, lunch, and dinner. That’s an overwhelming thought.

The trouble is, when people use the "eat an elephant a bite at a time" expression, they imply that you can tackle a huge project by doing a little bit here and there, fitting it in with everything else going on in your life. "Just get started," they say, "do a little bit whenever you have time, and you'll eventually get it done." But that works for a 20 oz. steak, not for an elephant.

Now, imagine if you only ate elephant for dinner. That would stretch the timeline to 22 years. And if only a third of your dinner was elephant, with the rest being mashed potatoes and salad, now we're talking 66 years.

Are you really going to keep an elephant carcass around for 66 years, slowly chipping away at it? Probably not. Even if you froze it, would you still want to eat 66-year-old elephant meat? And think about the logistics: the size of the freezer you'd need, the hassle of thawing it every time you wanted a few bites. It's ridiculous.

But here's the thing—this metaphor, despite its flaws, does have its place in certain contexts. It’s also used to emphasize the importance of breaking down overwhelming tasks into smaller, manageable parts, and this approach can be effective. However, for large, complex projects, the metaphor oversimplifies the reality of what’s required.

For truly big endeavors, the "one bite at a time" approach often leads to a slow, sporadic progress that doesn’t account for the psychological and practical challenges involved. Big projects have an expiration date—after 66 years, that book, app, or video game you’re working on might not be relevant anymore. They also take up mental space and add a cognitive load. Constantly switching back and forth between tasks comes with significant costs, making it harder to maintain momentum.

You'll find plenty of advice urging you to "finish something," and it's true—completing a project has enormous benefits. But the odds of finishing something substantial by just taking a bite here and there, mixed in with your other tasks, are slim.

So, how do you eat an elephant? You clear the kitchen. Get rid of the ice cream, pizza, and cucumbers—anything that isn't elephant. You focus. You put your head down and eat elephant all day, every day, until it's done.

Sometimes the only way forward is full immersion, intense focus, and a relentless commitment to the task at hand. Just remember to chew between bites.

Balancing Form and Function: What Tiny Glade Teaches Us

Philippe Vaillancourt — Fri, 31 May 2024 17:02:15 +0000

I just downloaded the demo for a wonderful little game called Tiny Glade. "Game" might not even be the right term to describe this interesting piece of software. Here’s how it introduces itself:

Tiny Glade is a relaxing game where you doodle whimsical castles, cozy cottages and romantic ruins. There's no management, combat or goals. Just kick back and turn forgotten meadows into lovable dioramas.

After spending some time with Tiny Glade, I am impressed by the level of care the developers have put into it. The attention to detail is remarkable. Every interaction feels organic and fluid, thanks to numerous subtle features.

At its core, Tiny Glade is a castle-builder sandbox. You construct castles by laying down building blocks that can be translated, rotated, scaled, and joined. Essentially, it's a graphics editor like Blender or Illustrator, but much more enjoyable, especially for first-time users. Why? Because Tiny Glade focuses on form as much as function.

The game’s emphasis on form does not come at the expense of function. It offers great flexibility while maintaining a natural and intuitive feel. Every action has a corresponding visual or sound effect, enhancing the experience without being overwhelming. This level of craftsmanship makes interactions pleasing.

Words can't really do it justice, so here's a gameplay trailer video.

This experience made me question why the applications we use daily don’t offer the same level of enjoyment. Many business applications prioritize function over form, resulting in user frustration. Product owners often justify this by citing monetary reasons, implying that investing in form is a waste. But Tiny Glade proves otherwise.

As software developers, we should recognize the intrinsic value in form. People are willing to pay for pleasant interactions with software. While the balance between form and function varies by application, it is clear that focusing solely on function might be costing us more than we realize. I'm confident that Tiny Glade will show that enhancing user experience can lead to commercial success.

Quick and easy local web server

Philippe Vaillancourt — Mon, 17 Jan 2022 22:26:11 +0000

I was working on the documentation for some of my open source libraries this week (@snowfrog/option and @snowfrog/result, check them out) and found myself wanting to quickly serve the documentation websites locally.

I'm using TypeDoc, which parses your TypeScript code and generates an entire API documentation website pretty much automatically. But seeing as it's an actual website and not just a simple static html file, you can't just open index.html in your browser and have the whole thing work. You need to actually serve the site with a web server.

Now I know there are different options out there for doing that, some are even integrated with your favourite IDEs and code editors. But this week I have found a way to do this that is amazingly simple and works from the command line; so it works no matter what you're doing and which software you are using in the moment.

All you need is to have Python 3 installed on your machine - you probably have it, if not here's a download link. Then, simply run the following command from the folder where your index.html is located:

python -m http.server 4200

The 4200 here is the port number, you can make that whatever you want. For more information, here is a link the documentation for this Python http server module.

Break out command object

Philippe Vaillancourt — Tue, 07 Sep 2021 12:56:29 +0000

In many applications, long functions are very hard to work with. In a legacy codebase, they are often contained in large classes that have many dependencies. The work that it takes to bring such functions and classes into a test harness is often significant and may even be overkill for the changes you need to make.

If the function that you need to work with is large or uses instance variables and functions, consider using Break Out Command Object. To make a long story short, this refactoring technique gets you to move a long function to a new class. Objects created using that new class are called command objects because they are mostly built around a single function, whose request and execution is the purpose of the object. It is an object that encapsulates a request, following the command pattern in Design Patterns.

After you’ve used Break Out Command Object, you can often write tests for the new class easier than you could for the old function. Local variables in the old function can become instance variables in the new class. Often that makes it easier to break dependencies and improve the code.

Here's an example in Typescript (large parts of the class have been removed to preserve pixels):

class ApplicantInfoComponent {
  applicantCommonModel = new ApplicantCommonEditModel();
  isSmartMoveActive = false;
  datePickerComponents: QueryList<CustomDatePicker>;
  ...

  constructor(private flashMessageService: NotifyFlashMessageService, ...) {
    ...
  }

  validateDates() { ... }
  ...

  validateBirthDate(finalValidation) {
    let isValid = true;
    let tempDate = new Date(this.applicantCommonModel.DateOfBirth);

    if (
      this.isSmartMoveActive && new Date(
        tempDate.getFullYear() + 18, tempDate.getMonth() - 1, 
        tempDate.getDay()
      ) >= new Date()
    ) {
      isValid = false;
      let birthDate = this.datePickerComponents['_results']
        .find(item => item.Name == 'birthDate');
      birthDate.invalidDate = true;
      this.flashMessageService.warning('Age must not be less than 18 years.');
    }
    else if (
      this.isSmartMoveActive && new Date(
        tempDate.getFullYear() - 125, tempDate.getMonth() - 1,
        tempDate.getDay()
      ) >= new Date()) {
      isValid = false;
      let birthDate = this.datePickerComponents['_results']
        .find(item => item.Name == 'birthDate');
      birthDate.invalidDate = true;
      this.flashMessageService.warning('Age must not be more than 125 years.');
    }
    if (finalValidation)
      return isValid && this.validateDates();
    return isValid;
  }
  ...
}

The ApplicantInfoComponent class has a long function named validateBirthDate. We can’t easily write tests for it, and it is going to be very difficult to create an instance of ApplicantInfoComponent in a test harness. Let’s use Break Out Command Object to move validateBirthDate to a new class.

The first step is to create a new class that will do the birth date validation work. We can call it BirthDateValidator. After we’ve created it, we give it a constructor. The arguments of the constructor should be a reference to the original class, and the argument to the original function.

class BirthDateValidator {
  constructor(component: ApplicantInfoComponent, finalValidation: boolean) {}
}

You might be looking at this and saying, “Wait a minute, it looks like we are going to end up in the same place. We are accepting a reference to a ApplicantInfoComponent, and we already decided that we don't want to instantiate one of those in our test harness. What's the point of all this?” Wait, we are going to make things better.

After we’ve made the constructor, we can add another function to the class, a function that will do the work that was done in the validateBirthDate() function. We can call it validate().

class BirthDateValidator {
  constructor(component: ApplicantInfoComponent, finalValidation: boolean) {}

  validate() {}
}

Now we add the body of the validateBirthDate() function to BirthDateValidator. We copy the body of the old validateBirthDate() function into the new validate() function.

class BirthDateValidator {
  constructor(component: ApplicantInfoComponent, finalValidation: boolean) {}

  validate() {
    let isValid = true;
    let tempDate = new Date(this.applicantCommonModel.DateOfBirth);

    if (
      this.isSmartMoveActive && new Date(
        tempDate.getFullYear() + 18, tempDate.getMonth() - 1, 
        tempDate.getDay()
      ) >= new Date()
    ) {
      isValid = false;
      let birthDate = this.datePickerComponents['_results']
        .find(item => item.Name == 'birthDate');
      birthDate.invalidDate = true;
      this.flashMessageService.warning('Age must not be less than 18 years.');
    }
    else if (
      this.isSmartMoveActive && new Date(
        tempDate.getFullYear() - 125, tempDate.getMonth() - 1,
        tempDate.getDay()
      ) >= new Date()) {
      isValid = false;
      let birthDate = this.datePickerComponents['_results']
        .find(item => item.Name == 'birthDate');
      birthDate.invalidDate = true;
      this.flashMessageService.warning('Age must not be more than 125 years.');
    }
    if (finalValidation)
      return isValid && this.validateDates();
    return isValid;
  }
}

If the validate() on BirthDateValidator has any references to instance variables or functions from ApplicantInfoComponent, our compile will fail. To make it succeed, we can make getters for the variables and make the functions that it depends on public. In this case, we depend on a few variables and one validateDates() function, all of which are public except for the flashMessageService variable. After we make it public on ApplicantInfoComponent, we can access it from a reference to the BirthDateValidator class and the code compiles.

Now we can make ApplicantInfoComponent’s validateBirthDate function delegate to the new BirthDateValidator.

class ApplicantInfoComponent {
  ...

  validateBirthDate(finalValidation) {
    birthDateValidator = new BirthDateValidator(this, finalValidation);
    birthDateValidator.validate();
  }
  ...
}

Now back to the ApplicantInfoComponent dependency. The whole reason why we decided to create a new class is that ApplicantInfoComponent would be too hard to instantiate in a test harness. As of right now, we still have that problem because our new BirthDateValidator class still depends on a reference to ApplicantInfoComponent. What we can do is extract a new interface to break the dependency on ApplicantInfoComponent completely. To do that we create a new interface, we'll call it DateValidator. Then we change the reference that the BirthDateValidator holds from ApplicantInfoComponent to DateValidator, compile, and let the compiler tell us what functions and properties have to be on the interface. Here is what the code looks like at the end:

interface DateValidator {
  applicantCommonModel: ApplicantCommonEditModel;
  isSmartMoveActive: boolean;
  datePickerComponents: QueryList<CustomDatePicker>;
  flashMessageService: NotifyFlashMessageService;
  validateDates(): boolean;
}

class ApplicantInfoComponent {
  ...

  validateBirthDate(finalValidation) {
    birthDateValidator = new BirthDateValidator(this, finalValidation);
    birthDateValidator.validate();
  }
  ...
}

class BirthDateValidator {
  constructor(component: DateValidator, finalValidation: boolean) {}

  validate() {
    let isValid = true;
    let tempDate = new Date(component.applicantCommonModel.DateOfBirth);

    if (
      component.isSmartMoveActive && new Date(
        tempDate.getFullYear() + 18, tempDate.getMonth() - 1, 
        tempDate.getDay()
      ) >= new Date()
    ) {
      isValid = false;
      let birthDate = component.datePickerComponents['_results']
        .find(item => item.Name == 'birthDate');
      birthDate.invalidDate = true;
      component.flashMessageService.warning('Age must not be less than 18 years.');
    }
    else if (
      component.isSmartMoveActive && new Date(
        tempDate.getFullYear() - 125, tempDate.getMonth() - 1,
        tempDate.getDay()
      ) >= new Date()) {
      isValid = false;
      let birthDate = component.datePickerComponents['_results']
        .find(item => item.Name == 'birthDate');
      birthDate.invalidDate = true;
      component.flashMessageService.warning('Age must not be more than 125 years.');
    }
    if (finalValidation)
      return isValid && component.validateDates();
    return isValid;
  }
}

Now that we've extracted the code that we need to modify to a new class, we're ready to write some tests, refactor and make whatever changes we came here to make. You can see me work with Break Out Command Object, and the following steps of writing tests and refactoring code, this video series I made on working with legacy code.

How to wrap an Angular directive library?

Philippe Vaillancourt — Tue, 30 Mar 2021 01:39:51 +0000

You've been asked to implement a new feature in the Angular application at work. As you sit at your desk and reach for the keyboard a thought pops into your mind: "I can't be the first one to have to implement something like this. I bet there's a library that does what I need".

Good for you. That's a good reflex to have in today's open-source world. Why reinvent the wheel when you can just borrow someone else's wheel? Chances are you are right; someone did have to solve the same problem you are trying to solve and was nice enough to share it with the world.

So a quick search on npmjs.com and you find exactly what you are looking for. The perfect Angular library which, through a few exported directives, does pretty much what you want.

Now, you realize that it might not be the best idea to start using those directives all over the app and would like to wrap that library so that your app doesn't become tightly coupled to it. But how?

When we are talking about wrapping a 3rd party library, we are usually talking about using composition to provide a new interface to our application, interface that will delegate work to the 3rd party library. That way, the 3rd party library does all the heavy lifting, but our app doesn't even know it exists, it just knows about the pretty wrapper we've made for it.

If you are familiar with design patterns, you'll probably end up using something that looks a lot like the Adapter, the Proxy, or the Façade pattern.

For our demonstration, we'll wrap the angular-resizable-element library. You can try it out, and see the code associated with this article, in the following Stackblitz.

Choose your API

angular-resizable-element is a cool little library that makes it possible to resize elements by dragging their edges. Let's take a quick look at how it works. According to its documentation, it provides two directives through it's exported module: ResizableDirective and ResizeHandleDirective.

Upon examination, we conclude that we don't really need to use ResizeHandleDirective. It's purpose is to give finer grain control over each handle to the sides of the resizable element and we don't really care about that. So that leaves us with ResizableDirective. Looking at the docs, we see that it takes in 9 inputs and emits 3 outputs.

As is often the case with libraries, they tend to offer a much wider API than you actually need. Do not feel like you have to mirror the 3rd party library with your wrapper. In fact, your wrapper's API should only provide what your app needs. No more, no less.

In our case, after a careful examination of our requirements, we determine that we don't need to provide the equivalent of the allowNegativeResizes, mouseMoveThrottleMS, resizeCursors, resizeCursorPrecision and resizeSnapGrid inputs. Other than that, it would make sense for our wrapper to provide a similar interface to that of the 3rd party library, as it will cover our needs nicely.

Wrap it up

At the moment, our demo component uses the 3rd party library directly and the code looks like this:

<div class="text-center">
  <h1>Drag and pull the edges of the rectangle</h1>
  <div
    class="rectangle"
    [ngStyle]="style"
    mwlResizable
    [validateResize]="validate"
    [enableGhostResize]="true"
    (resizeEnd)="onResizeEnd($event)"
    [resizeEdges]="{bottom: true, right: true, top: true, left: true}"
  ></div>
</div>

import { Component } from "@angular/core";
import { ResizeEvent } from "angular-resizable-element";

@Component({
  selector: "my-app",
  templateUrl: "./app.component.html",
  styleUrls: ["./app.component.css"]
})
export class AppComponent {
  public style: object = {};

  validate(event: ResizeEvent): boolean {
    const MIN_DIMENSIONS_PX: number = 50;
    if (
      event.rectangle.width &amp;&amp;
      event.rectangle.height &amp;&amp;
      (event.rectangle.width &lt; MIN_DIMENSIONS_PX ||
        event.rectangle.height &lt; MIN_DIMENSIONS_PX)
    ) {
      return false;
    }
    return true;
  }

  onResizeEnd(event: ResizeEvent): void {
    this.style = {
      position: "fixed",
      left: `${event.rectangle.left}px`,
      top: `${event.rectangle.top}px`,
      width: `${event.rectangle.width}px`,
      height: `${event.rectangle.height}px`
    };
  }
}

As you can see, we are using the mwlResizable directive selector from the library in our template and its ResizeEvent interface in the component. We need to use our wrapper instead. So let's do that.

Step one: inputs and outputs

As a first step I often find it useful to define the inputs and outputs of our wrapper. To begin we will create a new directive in a new file for our wrapper. Since we plan on providing a similar, yet simpler, interface than the one exposed by the library, we can use its source code as a base and simply copy the inputs and outputs that we plan to provide. After this step we end up with something like this:

@Directive({
  selector: "[resizableWrapper]"
})
export class ResizableDirective implements OnInit, OnChanges, OnDestroy {
  @Input() validateResize: (resizeEvent: ResizeEvent) =&gt; boolean;
  @Input() resizeEdges: Edges = {};
  @Input() enableGhostResize: boolean = false;
  @Input() ghostElementPositioning: "fixed" | "absolute" = "fixed";
  @Output() resizeStart = new EventEmitter&lt;ResizeEvent&gt;();
  @Output() resizing = new EventEmitter&lt;ResizeEvent&gt;();
  @Output() resizeEnd = new EventEmitter&lt;ResizeEvent&gt;();
}

You'll also want to make sure that you don't just reuse the library's interfaces and instead provide your own. For instance, in the above code we have the ResizeEvent and Edges interfaces. We made sure to define our own, in separate files.

Step two: constructor parameters

As we will be creating an instance of the library's directive whenever we create an instance of our wrapper, we will need to pass the appropriate dependencies. Here the 3rd party directive's constructor:

constructor(
    @Inject(PLATFORM_ID) private platformId: any,
    private renderer: Renderer2,
    public elm: ElementRef,
    private zone: NgZone
  ) {
    this.pointerEventListeners = PointerEventListeners.getInstance(
      renderer,
      zone
    );
}

So we'll need to pass in four dependencies. All four are part of the @angular/core package and therefore should be easy for the DI system to resolve. Let's do that now.

This step is not particularly hard. All we need to do is add the library's directive to our wrapper's constructor and supply Angular's DI with a factory provider.

function resizableDirectiveFactory(
  platformId: any,
  renderer: Renderer2,
  elm: ElementRef,
  zone: NgZone
) {
  return new ResizableDirective(platformId, renderer, elm, zone);
}

const resizableDirectiveProvider = { 
  provide: ResizableDirective,
  useFactory: resizableDirectiveFactory,
  deps: [PLATFORM_ID, Renderer2, ElementRef, NgZone]
};

@Directive({
  selector: "[resizableWrapper]",
  providers: [resizableDirectiveProvider]
})
export class ResizableWrapperDirective implements OnInit, OnChanges, OnDestroy {
  constructor(private library: ResizableDirective) {}
}

Step three: Lifecycle hooks

One thing to keep in mind when wrapping a directive in Angular is that we need to account for the lifecycle hooks. They can be viewed as part of your wrapper's API. You'll probably want to have the same lifecycle hooks as the directive you are wrapping. Keeping that in mind, let's look at the three hooks we'll need to implement.

First ngOnInit. The first thing we wanna do is hook up the outputs.

ngOnInit(): void {
  this.library.resizeStart
    .pipe(takeUntil(this.destroy$))
    .subscribe(event =&gt; this.resizeStart.emit(event));
  this.library.resizing
    .pipe(takeUntil(this.destroy$))
    .subscribe(event =&gt; this.resizing.emit(event));
  this.library.resizeEnd
    .pipe(takeUntil(this.destroy$))
    .subscribe(event =&gt; this.resizeEnd.emit(event));
}

Keep in mind that this example is very simple because our event interfaces are a mirror image of the library's interfaces. Were it not the case, you would have to map them to your own interfaces before emitting them.

Ok, all that is left is to delegate to the library's own ngOnInit function.

ngOnInit(): void {
  ...

  this.library.ngOnInit();
}

As simple as that. Moving on to ngOnChanges which gets called before ngOnInit and every time one or more data-bound input properties change. So guess what we need to do in that function. That's right, assign our input properties... and delegate to the library's ngOnChanges function.

ngOnChanges(changes: SimpleChanges): void {
  if (changes.validateResize)
    this.library.validateResize = this.validateResize;
  if (changes.resizeEdges) this.library.resizeEdges = this.resizeEdges;
  if (changes.enableGhostResize)
    this.library.enableGhostResize = this.enableGhostResize;
  if (changes.ghostElementPositioning)
    this.library.ghostElementPositioning = this.ghostElementPositioning;

  this.library.ngOnChanges(changes);
}

And finally, ngOnDestroy

ngOnDestroy(): void {
  this.library.ngOnDestroy();
  this.destroy$.next();
}

Step four: Declare your wrapper and use it

All that is left is to add our wrapper to our module and to use it in our template.

import { NgModule } from "@angular/core";
import { BrowserModule } from "@angular/platform-browser";
import { FormsModule } from "@angular/forms";

import { AppComponent } from "./app.component";
import { ResizableWrapperDirective } from "../lib/resizable-wrapper.directive";

@NgModule({
  imports: [BrowserModule, FormsModule],
  declarations: [AppComponent, ResizableWrapperDirective],
  bootstrap: [AppComponent]
})
export class AppModule {}

As you can see, our module has no references to the 3rd party angular-resizable-element library. It only declares our wrapper directive. Our template and component also now only depend on our wrapper directive.

<div class="text-center">
  <h1>Drag and pull the edges of the rectangle</h1>
  <div
    class="rectangle"
    [ngStyle]="style"
    resizableWrapper
    [validateResize]="validate"
    [enableGhostResize]="true"
    (resizeEnd)="onResizeEnd($event)"
    [resizeEdges]="{bottom: true, right: true, top: true, left: true}"
  ></div>
</div>

Conclusion

Wrapping 3rd party libraries is generally good practice but it can be a challenge to do so when dealing with Angular directives. Each library is different and will require a slightly different approach but the four steps laid out in this article should serve as a good foundation.

WSL is a memory hog, deal with it

Philippe Vaillancourt — Thu, 11 Mar 2021 18:17:15 +0000

I recently upgraded my computer's RAM to 32GB from 16GB. It was running fine but ever since I started doing more work with Docker containers, it felt like it would get sluggish once in awhile.

With now double the RAM, I figured I'd be golden. It turns out it isn't that simple. This week, the company I work for decided to start using containers for most of our project's dependencies, you know, SQL server, Solr, Redis etc... There is quite a few of them, but I've never had a problem running them simultaneously on my machine.

A docker-compose up later and my computer became sluggish again. What?! A quick look at the Processes tab in Task Manager showed that 98% of my system's memory was being used and 23GB out of my 32GB was being used by something called Vmmem. What the heck is Vmmem and why is it using so much memory?

Damn you Vmmem!

A quick Google search later produced some answers. The short of it, Vmmem is the process that runs the Windows Subsystem for Linux (WSL), which is used by Docker on Windows. So Vmmem = WSL = Docker. This is a major over-simplification but if you never use WSL directly and are only using it for Docker, for you it's pretty close to reality.

Anyway, even though I now understood what this Vmmem thing was, it was pretty clear in my mind that there was no way the roughly 30 processes I was running inside Docker containers needed to consume this much memory. Most of them were relatively lightweight.

The first thing I started by doing was to bring down all my containers to see if this would help. After docker-compose down the situation improved. But not nearly as much as it should have.

Better, but not nearly enough

Why in the world is Vmmem still using 17 GB of RAM if I'm no longer running any Docker containers? Well, let's find out, shall we? In the terminal, I switched over to WSL and ran the Linux free command which gives you an overview of memory usage.

Ah Ah! WSL you memory thief you!

As far as WSL was concerned, it considered that it had rights over 25GB of my system's memory. At the moment is was using 8.8 GB (for what?!) but what is interesting is that it had reserved a full 14 GB as buff/cache.

You see, nature, and Linux apparently, abhors a vacuum. Since it considered that it had rights over 25 GB or my RAM but it didn't need all of it, it figured it would just earmark whatever it didn't need as cache. You know, because why not. It's not like the host machine has any need for memory on the Windows side of things (looking at you Google Chrome).

So why does WSL feel entitled to this much RAM. Well, it turns out that, depending on which build of Windows or WSL you are on, WSL gets access to 50%-80% of your system's RAM by default. Again, what?! 25 GB of RAM is way more than is needed to run a few fistfuls of Docker containers.

Thankfully, there is a way to fix this. To impose our will on WSL and get it to forget about that silly default setting, all we need to do is place a .wslconfig file into the root directory of our users folder: C:\Users\<yourUserName>\.wslconfig.

In my case I ended up limiting WSL to 8 GB of my RAM and, while I was at it, 4 of my 8 CPU cores - it has access to all of them by default.

.wslconfig, the hero of this story

All that was left to do was stop and restart WSL. A simple wsl --shutdown in the terminal will stop WSL. At that point Docker will notice that it has shutdown and offer to restart it. Let it do that for you.

Docker offers to restart WSL

And there you have it. We have tamed the hungry beast.

There are other setting options you can set for the Windows Subsystem for Linux in that .wsconfig file, you can find them here.

Are Single-Page Applications Bounded Contexts - and who the heck cares?

Philippe Vaillancourt — Thu, 18 Feb 2021 01:35:40 +0000

In the first and second article in the series we have established that a Bounded Context includes more than just the domain model but extends to the other layers of our system, in a vertical slice.

To better understand how this all plays out, and why this means that a Single-Page Application should be part of it's server-side API, I decided to map out a simple class diagram over Uncle Bob's famous clean architecture. First, for comparison, I mapped out the typical MVC application.

Typical MVC Application

If you are not familiar with this architecture or diagram you'll find plenty of examples with a quick Google search for "Clean Architecture". Suffice to say that at the center, in yellow, is the domain model. This diagram is meant to represent one specific use case, a vertical slice, dealing with Products. According to Vernon, this entire diagram could constitute a Bounded Context.

Now let's look at what the same use case would look like with a SPA.

API Endpoint Server with SPA client

There is a bit more going on here, as can be expected. But as you can see, the core of our application didn't change. We are still using the same domain model, application service and repository interface. The only thing that changed is that we have added a few intermediaries between our ProductController and our View. That's normal since we now have to go through the Web to reach it. The important thing here is to realize that the fact that we have swapped our client from a traditional server side MVC UI to a SPA didn't change anything for the core domain. And everything in this diagram is is still a vertical slice, handling the same use-case, dealing with Products.

So, if the setup in the first diagram is a Bounded Context it stands to reason that the setup in the second diagram also represents one Bounded Context. We haven't changed the domain model. We haven't changed the words we use to refer to the components in the domain model. We are still talking the same Ubiquitous Language.

As stated previously, the components in the green and blue layers are not part of the domain model, but they ARE part of the Bounded Context. If we swap components in and out of the green and blue layers but don't add anything to the pink and yellow ones, we're still dealing with the same domain model, the same Ubiquitous Language... the same Bounded Context.

Does it even matter?

When I was discussing this with Steve - remember him from the first article? - he rightfully reminded me that "all models are wrong, but some are useful". So the question is, despite the fact that, according to our analysis of the DDD literature, viewing the SPA as part of the same BC as the server-side API is more "right" than viewing it as a separate BC, is it more useful?

All models are wrong, but some are useful

I honestly don't know for sure, but I do see some advantages to modelling it that way. One of them stems from what Vernon says about Bounded Contexts and teams. He says: "There should be one team assigned to work on one Bounded Context. [...] It is especially important to be clear that one team works on a single Bounded Context."

I do believe that the best way to develop software is generally to work in small, multidisciplinary teams, using vertical slices. Given what Vernon says, if we were to model the SPA as it's own BC, we would presumably have different teams working on the SPA and the back-end, which I think is less than ideal. But that's a topic for another blog post.

What do you think? Is it more useful to view the SPA as its own BC, or as part of the server-side API's BC? Why? Let me know in the comments.

Are Single-Page Applications Bounded Contexts - and what the heck is inside a Bounded Context?

Philippe Vaillancourt — Thu, 18 Feb 2021 01:35:28 +0000

In the previous article in this series we arrived at a simple, but rather abstract definition of what a Bounded Context(BC) is. This definition seemed to confirm my intuition that a Single-Page Application(SPA) should be part of the same BC as its server-side API, but does it really?

To my mind, if in the SPA I'm dealing with a ProductComponent, ProductView or ProductViewModel, the data for which I received from the api/product/:id endpoint, endpoint that was custom made for the particular use case served by ProductComponent by members of my team, then we're talking the same Ubiquitous Language.

I'll admit that due to the abstract nature of the definition of a Bounded Context, someone could arrive at a different conclusion. My conclusion is influenced by the fact that I'm a full-stack developper and usually work on multi-disciplined teams who do vertical slices.

But what if the people in charge of developing the api/product/:id endpoint are technically not on my team and teams are split between client-side and server-side 🤮? Also, the ProductViewModel might not be a perfect 1 to 1 mapping of the server-side Product entity, doesn't that mean that when I'm thinking of a Product I'm not thinking of exactly the same thing as my server-side brethren?

A Bounded Context is composed of more than a domain model.

By that logic though, even in a standard MVC type app, where the pages are rendered on the server, you would have to say that the Bounded Context excludes the Controller, the View and the Model. Is that what Vernon envisions when he sees a BC? Does a BC only contain the classes and interfaces that are part of the domain model (entities, value object, domain services, domain events and repositories) or does it extend to the classes (application services, controllers, etc.) in other layers?

To those questions, at least, Vernon offers precise and satisfying answers, with an accompanying diagram no less. He says that "There is another question that you may have wondered about. What’s inside a Bounded Context? Using this Ports and Adapters architecture diagram, you can see that a Bounded Context is composed of more than a domain model.

Domain-Driven Design Distilled - Vaughn Vernon

These layers are common in a Bounded Context: Input Adapters, such as user interface controllers, REST endpoints, and message listeners; Application Services that orchestrate use cases and manage transactions; the domain model that we’ve been focusing on; and Output Adapters such as persistence management and message senders."

So there we have it. When talking about Bounded Contexts, Vernon, at least, is talking about the entire stack. A bit like a vertical slice or slices.

But surely Vernon didn't have SPAs in mind when he said this? SPAs are different, they are more than just UI, some even have a bit of business and application logic. Plus, they are separate applications (it's in the name after all), that run on a different machine, surely BCs do not cross process boundaries?

To this I answer, really? Why not? Where in the definitions of a Bounded Context or the Ubiquitous Language do we see any mention of anything that has to do, even remotely, with the concept of deployment location or process boundaries? Nowhere, that's where.

To add some weight to the argument that it is absolutely not antithesis to DDD for a Bounded Context to span multiple deployment artifacts or processes, here's what Vernon says in 'Implementing DDD': "A Bounded Context does not dictate the creation of a single kind of project artifact. It’s not an individual component, document, or diagram. So it’s not a JAR or DLL, but these can be used to deploy a Bounded Context as described later in the chapter."

A Bounded Context does not dictate the creation of a single kind of project artifact. It’s not an individual component, document, or diagram.

So a BC does not equal a package, project or any other kind of deployment artifact. It can, but it doesn't have to. For example, a DLL could contain more than one BC and one BC could span several DLLs.

Regarding the idea that a BC can also span several processes and physical or virtual machines Vernon gives the following explanation while talking about an example application that deals with Scrum-based software project management: "some consider a microservice to be much smaller than a DDD Bounded Context. Using that definition, a microservice models only one concept and manages one narrow type of data. An example of such a microservice is a Product and another is a BacklogItem. If this is the granularity that you consider a worthy microservice, understand that both the Product microservice and the BacklogItem microservice will still be in the same larger, logical Bounded Context. The two small microservice components have only different deployment units, which may also have an impact on how they interact. Linguistically they are still within the same Scrum-based contextual and semantic boundary."

Yes he is talking about microservices, but the same principles apply when talking about a SPA. The fact that it runs in a different process and is deployed separately is not a valid reason not to consider the SPA as part of the same BC as the rest of the server-side BC. These factors are orthogonal to the concept of a BC.

Keep reading, in the next article we will illustrate our findings using Uncle Bob's famous Clean Architecture and discuss WHY it is preferable to view the SPA as part of its server-side API's Bounded Context.

Are Single-Page Applications Bounded Contexts - and what the heck is a Bounded Context?

Philippe Vaillancourt — Thu, 18 Feb 2021 01:35:13 +0000

That is the question I have been pondering these past few weeks. It led to a series of interesting conversations with Steve "ardalis" Smith on our devBetter community Discord server. At the time of these discussions I wasn't sure of the answer. I was however leaning towards the idea that most Single-Page Applications (SPA) were not Bounded Contexts (BC) but in fact belonged to the BC of their corresponding server-side API.

Steve had the good idea to consult the Twittersphere to see what other developers thought. The results were far from conclusive with only 54% of respondents being of the opinion that the SPA was part of its server-side API's Bounded Context. A majority, but barely.

Folks building SPAs with #DDDesign and considering Bounded Contexts (BCs). Are the SPA and its server-side APIs it uses (see poll):

RT for reach pls.
— Steve "ardalis" Smith (@ardalis) February 1, 2021

I would need to analyze this question further to come to a satisfying conclusion. So I decided to go back to the source, to the authoritative works on the subject of Domain Driven Design (DDD), namely, the works of Eric Evans and Vaughn Vernon.

This analysis led me to the conclusion that the majority of SPAs (those backed by a corresponding, in-house, server-side API) are not BCs in their own right but, rather, belong to the BC of their server-side API. Here's why.

First, some definitions

Our question involves three elements: 1) a Single-Page Application 2) a server-side API 3) the concept of a Bounded Context. I thought it would be prudent to make sure I was really clear on what those three things were before trying to answer our question.

Single-Page application : A client-side web application that doesn't need to load new pages from the server. The kind of application you would generally write with Angular, React, Vue.js or Blazor frameworks.

Server-side API : A server-side application containing business logic and exposing an API to web clients, often through REST endpoints. You could write such an application with the ASP.Net or the Spring frameworks, to name but a few. These applications are usually backed by a database.

Bounded Context : .... and this is were we get in trouble. As I read through the DDD body of work, I quickly realized that the concept of a Bounded Context was not that easy to define. This is precisely why it seemed hard to find a clear cut answer to our question. So, before we can go any further, a discussion on what constitutes a Bounded Context is in order.

What is a Bounded Context

In Evans' blue book on DDD, in the glossary, we find the following definition for Bounded Context: "The delimited applicability of a particular model. BOUNDING CONTEXTS gives team members a clear and shared understanding of what has to be consistent and what can develop independently." A little vague, I know.

Vernon, for his part, says in 'DDD Distilled' that a "Bounded Context is a semantic contextual boundary. This means that within the boundary each component of the software model has specific meaning and does specific things. The components inside a Bounded Context are context specific and semantically motivated. That's simple enough. " No Vaughn, no, it's not simple enough. But thanks for trying.

To understand both of Evans' and Vernon's definitions, you kind of have to understand the concept of Ubiquitous Language(UL). Notice how Vernon talks about a "semantic contextual boundary" and about the components being "semantically motivated"? He's talking about the UL. In other words, according to Vernon, one BC equals one UL.

A Bounded Context is a part of the system where the same people work on the same things and call those things by the same names.

So what is a Ubiquitous Language? Evans says it is "a language structured around the domain model and used by all team members to connect all the activities of the team with the software." In other words, on the team, if I'm talking about a Product or a Customer, everyone knows exactly what I'm referring to. Now, another team working on the same app might also have to deal with Products or Customers but they have a slightly different definition of what they are and what they do. As such they do not speak our Ubiquitous Language and therefore are dealing with a different Bounded Context.

So, if I had to give my own, super simple, definition of a Bounded Context I would say that it is a part of the system where the same people work on the same things and call those things by the same names.

Yeah, I know, still a little vague. I wasn't very satisfied either. In this article we have defined, in the abstract, what a Bounded Context IS. Still on our quest to determine if a SPA is a Bounded Context, in the next article we will look at what a Bounded Context HAS. What is part of a Bounded Context? What does it contain? Keep reading to find out...

The Spy of Testadel: A Medieval Testing Tale

Philippe Vaillancourt — Thu, 26 Dec 2019 16:55:57 +0000

The year is 1453. After 116 years of war, your kingdom, Testadel, is finally at peace. Now is the time to rebuild and strengthen your relationships with your neighbours. To the North lies the fiefdom of Lord PureFunction, who fought valiantly at your side during the war. In an effort to establish stronger commercial ties, you both sign a treaty whereby you promise to supply his keep with as many sheep as you can every month, in exchange for 15 pieces of gold per sheep.

class LordPureFunctionsKeep {
  priceOfOneSheep = 15;

  calculatePaymentForSheep(sheep: number): number {    
    return sheep.length * this.priceOfOneSheep;
  }
}

After a few months, as was agreed by both parties, an independent auditor travels to Lord PureFunction's keep to make sure that the commercial agreement is being fulfilled properly.

describe('LordPureFunctionsKeep'() => {
  test('should pay 300 gold pieces when supplied with 20 sheep', () => {
    const keep = new LordPureFunctionsKeep();

    const payment = keep.calculatePaymentForSheep(20);

    expect(payment).toBe(300);
  });
});

Upon completion, the auditor reports that Lord PureFunction was very accommodating. A true paragon of virtue, PureFunction opened up its books willingly and complied happily with every request from the auditor. "Usually", the auditor says, "people try to hide things from me, but not so with Lord PureFunction. You are lucky to have such a transparent and trustworthy ally".

Happy with the auditor's findings and secure in the knowledge that you have a strong relationship with your ally to the North, you turn your attention to the South. There lie the ravaged lands of Sir SideEffects.

Photo by udit saptarshi / Unsplash

Sir SideEffects had the misfortune of taking the other side, the losing side, during the recently ended war. The peace treaty that ended the war, and that he signed reluctantly, imposes serious limitations on the amount of weapons he is allowed to stockpile and forbids him from having any contacts with his previous allies.

It is agreed that Sir SideEffects will provide every month to your envoy a full account of his weapons stock.

class SirSideEffectsCamp {
  private armoury: Weapons[] = [] ;
  private scribe = new Scribe();

  reportWeaponsStock(): number {
    const report = this.scribe.writeWeaponsReport(this.armoury);
    return report;
  }
}

describe('SirSideEffectsCamp'() => {
  test('should report having less than 50 weapons', () => {
    const camp = new SirSideEffectsCamp();

    const weaponsStock = camp.reportWeaponsStock();

    expect(weaponsStock).toBeLessThan(50);
  });
});

For the first few months, Sir SideEffects seems to abide by the terms of his surrender. Every month your envoy shows up at the gate, asks for a report, and every month Sir SideEffects has a piece of paper attached to a rock thrown over the rampart, detailing the level of his weapons stock. The amount varies a little every month but is always below the agreed ceiling.

Everything seems under control until one day your envoy asks to speak with you about a matter that seems to have him worried. "My lord, I fear that Sir SideEffects might be up to no good. Indeed, this is the fourth month in a row that he has reported exactly 6 weapons. Something's not right; the amount always used to vary before".

class SirSideEffectsCamp {
  private armoury = Weapons[] = [];
  private scribe = new Scribe();

  reportWeaponsStock(): number { 
    const report = this.scribe.writeWeaponsReport(this.armoury);
    return 6; // <- Now reports 6 weapons
  }
}

Taking this matter to heart, you convene a meeting of your councillors to address the situation with Sir SideEffects. After debating for the better part of the day, everyone agrees that although it is highly suspicious that the reports for the past fours months have all been the same, it is not in itself a proof of foul play. More information needs to be gathered. But how? Sir SideEffects keeps the gate to his camp closed to outsiders and it is impossible to see what is going on inside.

One of your councillors speaks up. "Sir, we need to send a spy. Someone crafty enough to find a way in without being recognized and raising the alarm. The spy could check the weapons store and report back. Then we'll know for sure."

And so it is decided, a spy will be sent to Sir SideEffects' camp, with the difficult mission of infiltrating the camp and gathering vital information. Thankfully, you know just the man for the job. Your court jester, aptly nicknamed Jest, is a master of disguise and despite what some might think, an intelligent and resourceful man.

Later, as you go over the mission's plan with Jest, he points out a problem with the plan. If he is to somehow infiltrate the camp under the guise of one of its inhabitants, an opportunity for a swap must be created. At the moment, such an exchange is impossible as all of the camp's residents remain inside day and night.

"Leave that up to me," you say, "I know just what to do. I'll send forged orders to Sir SideEffects' scribe requiring him to leave the camp for the day. Upon his return, you can intercept him a short distance from the gate and take his place. You should be able to walk right through the front gate if your disguise is convincing enough."

As Jest makes preparation for his departure, you arrange for the forged orders to be sent to Sir SideEffects' scribe.

class SirSideEffectsCamp {
  private armoury = Weapons[];
  constructor(private scribe: Scribe) { } // <- Scribe now passes through gate

  reportWeaponsStock(): number { 
    const report = this.scribe.writeWeaponsReport(this.armoury);
    return 6;
  }
}

The next day, exactly as planned, Jest lies in wait by the wayside, about half a league from SideEffects' camp. As the sun begins to set, he finally sights his target. The scribe, back from surveying Sir SideEffects' fields, can already taste the turnip and cabbage soup waiting for him at home. Lost in his thoughts, he pays no attention to his surroundings. As he passes by the bushes where Jest had been lying in wait, he receives a massive blow to the head and immediately falls to the ground, unconscious.

Jest drags the scribe's limp body into the bushes, removes his clothing and adorns himself with the lavish clothes and accoutrement.

describe('SirSideEffectsCamp'() => {
  test('should report having less than 50 weapons', () => {
    // Our spy mimicks the scribe's ability to 'writeWeaponsReport'
    // but makes sure to keep a copy of the report in his pocket
    const spyScribe = {
      writeWeaponsReport(armoury: Weapons[]) {
        const report = armoury.length;
        spyScribe.pocket = report; // <- Keep copy of report in pocket
        return report;
      }
    }
    const camp = new SirSideEffectsCamp();

    const weaponsStock = camp.reportWeaponsStock();

    expect(weaponsStock).toBeLessThan(50);
  });
});

All that is left now is to walk through the front gate and take the scribe's place.

describe('SirSideEffectsCamp'() => {
  test('should report having less than 50 weapons', () => {
    const spyScribe = {
      writeWeaponsReport(armoury: Weapons[]) {
        const report = this.armoury.length;
        spyScribe.pocket = report;
        return report;
      }
    }
    const camp = new SirSideEffectsCamp(spyScribe); // <- Spy infiltrates the camp

    const weaponsStock = camp.reportWeaponsStock();

    expect(weaponsStock).toBeLessThan(50);
  });
});

The next morning, your envoy shows up at the gate of Sir SideEffects' camp and asks for a report like he did every month since the end of the war. This time though, your spy is in place inside the camp and is able to observe the weapons stock from the inside.

describe('SirSideEffectsCamp'() => {
  test('should report having less than 50 weapons', () => {
    const spyScribe = {
      writeWeaponsReport(armoury: Weapons[]) {
        const report = this.armoury.length;
        spyScribe.pocket = report;
        return report;
      }
    }
    const camp = new SirSideEffectsCamp(spyScribe);

    camp.reportWeaponsStock();

    expect(spyScribe.pocket).toBeLessThan(50); // <- Get spy's report
  });
});

Later that day, your spy manages to sneak out and report his findings. Although the report given by Sir SideEffects once again said that he only had 6 weapons in his armory, Jest reports that he in fact has close to 100 weapons in stock and that he has been willfully giving false reports.

What's more, while in the camp, Jest has heard a troubling rumour. Word around the drinking well is that Sir SideEffects has taken to dark magic. Apparently, the rumour goes, Sir SideEffects is in possession of a magical artifact that allows him to communicate directly with anyone, however far removed from the camp they may be. The rumour even goes as far as to say that the artifact - some say it is called The Console^TM - would allow him to communicate with mystical beings from another realm.

Though this seems a little far-fetched, you do suspect Sir SideEffects is using the artifact to communicate with his old ally, Sir EvilScreen.

class SirSideEffectsCamp {
  private armoury = Weapons[];
  constructor(private scribe: Scribe) { }

  reportWeaponsStock(): number { 
    const report = this.scribe.writeWeaponsReport(this.armoury);
    console.log(`We now have ${report} weapons, death to Testadel!`); // <-
    return 6;
  }
}

If only there was a way to intercept the messages being sent through this magical object. "My Lord," a croaked voice is heard from the back of the hall as a wizened old man steps forward, "my name is Sir Mockalot and through my travels and adventures, I have acquired an object that I believe may be of assistance".

Sir Mockalot explains that he possesses an artifact called the The Mocksole^TM. "It is said to have been forged together with The Console^TM and to possess very similar properties. If we could substitute The Console^TM with our own artifact, we would be the ones receiving Sir SideEffects' messages and he would be none the wiser".

As Sir Mockalot, accompanied by Jest, your trusty jester / spy, goes to his chamber to prepare The Mocksole^TM for delivery to Sir SideEffects camp,

describe('SirSideEffectsCamp'() => {
  test('should not be sending treasonous messages', () => {
    const theMocksole = { // <- Preparing the Mocksole
      log: jest.fn()
    }
  });
});

you set to writing an accompanying note.

"Dear Sir SideEffects, I was not able to hear your last message through The Console^TM as the sound was all garbled. Please find attached to this note, a replacement artifact to be used in its stead. Sincerely, Lord EvilScreen."

The next day, The Mocksole^TM is found at the camp's gate and brought in. Sir SideEffects reads the note and complies with its message.

class SirSideEffectsCamp {
  private armoury = Weapons[];
  constructor(private scribe: Scribe, private artifact: Console) { } // <- A console-like artifact at the gate

  reportWeaponsStock(): void { 
    const report = this.scribe.writeWeaponsReport(this.armoury);
    artifact.log(`We now have ${report} weapons, death to Testadel!`); // <- Let's use it instead of the old console.
    return 6;
  }
}

Everything is now in place to intercept the messages, all you need to do is stand by and listen.

describe('SirSideEffectsCamp'() => {
  test('should not be sending treasonous messages', () => {
    const theMocksole = {
      log: jest.fn()
    }
    const treasonousTalk = 'death to Testadel!'
    const camp = new SirSideEffectsCamp(spyScribe, theMocksole);

    camp.reportWeaponsStock();

    expect(theMocksole.mock.calls[0][0]).not.stringMatching(treasonousTalk);
  });
});

Horror! It is as you feared, Sir SideEffects is planning a rebellion. Thanks to the valiant efforts of your subjects you are made aware of this fact before it is too late and can make preparations. Peace will have unfortunately been short-lived.

When Should You Use A Web Framework?

Philippe Vaillancourt — Tue, 19 Mar 2019 03:07:05 +0000

Starting a new web app project. Wary of bloated frameworks with a gabillion dependencies. I'm a relatively inexperienced developper and I often feel like I don't know what the heck is going on under the hood in a framework like Angular. Part of me wants to code closer to the browser API but at the same time I want to be efficient and not reinvent the wheel.

I've read many posts like this one:

Why You Shouldn't Use A Web Framework

David Wickes ・ Jul 26 '18

#webdev #framework #beginners #react

and if you take a look at the comment sections, you can see that most reasonable people, whether they tend to be pro-framework or not, agree that in certain cases, it does make sense to use a framework, or to not use one.

Both sides go on at length explaining the pros and cons of using, or not using, a framework. The one thing that everyone just seem to never get into is WHEN, exactly should we use / not use a framework? Where is this imaginary threshold where one passes from "framework good for my project" to "framework bad for my project"? How do YOU make that determination? Where do YOU draw the line? Let's get into specifics. Examples. Level of complexity. Scope. Team size.

You're pro-framework but are reasonable enough to admit that sometimes it makes sense to not use one? On what kind of project would you consider ditching the framework and go vanilla / few small libraries?

You're anti-framework (looking at you @gypsydave5) but are reasonable enough to admit that sometimes it makes sense to use one? On what kind of project would you consider using a framework?

You're of the opinion that one should NEVER / ALWAYS use a framework? Please avoid commenting on this post and consider adding to the lively discussion on @gypsydave5 's post instead. 😜

Really interested to hear your diverse opinions.