Lightning Web Component (LWC) Class Definition Syntax

Question

Lightning Web Components (LWC) are made up of multiple files in a bundle. For this question I am focusing on the component's main .js file where the web component js class is implemented.

Example code:

import { LightningElement, api } from 'lwc';
import { NavigationMixin } from 'lightning/navigation';
import doSomething from '@salesforce/apex/MyApexClass.doSomething';

export default class MyLWC extends NavigationMixin(LightningElement) {
    @api a;
    @api b;

    download() {
        let that = this;
        doSomething({
            param1: this.a,
            param2: this.b
        })
        .then((result) => {
            that.navigateToWebPage(result);
        })
        .catch((error) =>{
            console.log(`Error occured ${error}`);
        });
    }

    navigateToWebPage(url) {
        // Navigate to a URL
        this[NavigationMixin.Navigate]({
            type: 'standard__webPage',
            attributes: {
                url: url
            }
        },
        false // Replaces the current page in your browser history with the URL
      );
    }
}

There are two things I don't understand here:

• extends NavigationMixin(LightningElement) syntax - why brackets? Can js classes extend more than one parent class?
• this[NavigationMixin.Navigate] - judging by the code it seems like 'this' got assigned the Navigate function (and potentially other functions from NavigateMixin?) to its prototype. Why aren't we using NavigationMixin like any other imported component - just calling their functions directly, not through this?

Can someone explain what is actually happening when using this kind of class extensions/inheritance, and if the syntax used here is something standard from the web components world or something specific for LWC?

Thanks for your answers!

Answer 1

The navigation API uses JavaScript Mixins!

Mixin – is a generic object-oriented programming term: a class that contains methods for other classes. Some other languages allow multiple inheritance. JavaScript does not support multiple inheritance, but mixins can be implemented by copying methods into prototype.

Read more about mixins here and more about class based mixins here

I have always questioned on this since on how hard the syntax is and why lwc team have chosen mixin only for navigation. It seems to deviate away from composition and in this case inheritance is chosen over composition!

Response from LWC platform Team — LNS(Lightning Navigation Service) has it on their roadmap to move away from the Mixin because of the inconsistent look/feel.

The root quality of the navigation API that led to something different is that it’s a contextual API that should be handled like an event would, but we choose to surface it more like a traditional JS/function API to avoid the dependency on events and for possible future static analyzability that one could not get with events.

There is a roadmap to bring in alignment with single imports than creating a mixin class

Answer 2

Mixins can basically merge some elements into the prototype of a class. For a succinct example:

class Animal {
    constructor(family) { this.family = family; }
    makeSound() { console.log('Animal of the ' + this.family + ' family making a sound.'); }
}
const StickCatcher = (superclass) => class extends superclass {
    catchStick() { console.log('Entity of the ' + this.family + ' family catching a stick.'); }
}
class Dog extends StickCatcher(Animal) {
    constructor(dogName) {
        super('canine'); // the super() "routes" to Animal (not to the StickCatcher)
        this.dogName = dogName;
    }
    wagTail() { console.log(this.dogName + ' wags his tail.'); }
}
const fido = new Dog('Fido');
fido.makeSound(); // Animal of the canine family making a sound
fido.catchStick(); // Entity of the canine family catching a stick
fido.wagTail(); // Fido wags his tail

The StickCatcher is a MixIn; it is a "class factory" which returns a class that was "enriched" with some functions -- in this case with a catchStick() function. The StickCatcher doesn't care which particular class it will be trying to extend. (however, catchStick() would care that this.family exists inside it).

On the other hand, note that the super-class of Dog is Animal. StickCatcher is not a class, it is a function that returns classes, i.e. a "class factory". The super('canine') is thus fed to the Animal constructor. The result is a Dog which has all the elements of Animal and of StickCatcher (alongside those of Dog, of course) -- i.e. the StickCatcher methods got mixed into the Animal-to-Dog class hierarchy.

What is the difference from just doing inheritance, i.e. the difference from class StickCatcherClass extends Animal { catchStick(){} } ? The difference is that the StickCatcher mixin is not "tied" to Animal, that you can use it in many other circumstances too, e.g. also use it in class StickCatchingDancingRobot extends StickCatcher(Robot) { dance(){} }.

LWC's NavigationMixin is of a similar nature. It will add the functions for navigation and for URL generation into your class prototype - but will add them under some "ugly, non-conflicting function names". The NavigationMixin.Navigate is a static string or getter, meant to return the said "ugly but non-conflicting function name", so that this[NavigationMixin.Navigate] dereferences to the navigation function that was added to your prototype by the said mix-in.