DEV Community: Marko V

Azure Devops and your tests

Marko V — Wed, 17 Jun 2020 06:20:45 +0000

I did an example project recently for a new class library I also did (for work). Now, I wanted to publish the test results and code coverage into azure devops.

The project was made in .NET Core 3.1 and tests are run with "dotnet" command and not the vstest command in the CI/CD.

dotnet test with codecoverage as a parameter produced, apparently, a bad result file. Azure Devops was unable to parse it.... ok ?... (I reported this through twitter to the azure devops team as I did various tests and tweaks to the configurations)

So I googled a bit and found a few articles telling me to use the VSTest CI/CD step in azure devops instead. So I fiddled with that for ages trying to get it to work. Using VSTest I also had to move to a windows image for the build process which meant a few other things also had to be converted which were not available in the same format in a windows image (scripts being run). Then that ended in it not being able to build it with vstest so I had to shuffle around the steps to not make a debug/symbol build for the beta-package before it ran the tests...

A long story short... VSTest cannot run the "good" codecoverage on a .NET Core 3.1 project, and dotnet test can atleast produce a test result with code coverage but not with as high fidelity as the builtin code coverage in Visual Studio Enterprise does with a .codecoverage file.

So these are now the first steps in my azure-pipelines.yml file in case anyone ever finds this and has the same kind of issue with publishing code coverage and test results in azure pipelines for a .net core 3.1 project.

steps:
- task: NuGetAuthenticate@0
  displayName: 'NuGet Authenticate'
- script: dotnet test --logger trx --collect:"XPlat Code Coverage"
  workingDirectory: MyProjectFolder
  displayName: 'Run Tests'
- task: PublishCodeCoverageResults@1
  inputs:
    codeCoverageTool: 'cobertura'
    summaryFileLocation: $(System.DefaultWorkingDirectory)/**/TestResults/**/coverage.cobertura.xml
- task: PublishTestResults@2
  condition: succeededOrFailed()
  inputs:
    testRunner: VSTest
    testResultsFiles: '**/*.trx'

half glass full / half empty

Marko V — Sat, 18 Apr 2020 20:44:31 +0000

Earlier today I heard this classic statement about a glass half full and I figured, can it be programmatically defined to represent the statement(s)?

Glass glassFilledWithLiquid = new Glass(new Liquid[250]);

In C# you can initialize, at best, the size of the container to begin with before you can fill it. Meaning it has initial state of 0 and a desired state to be filled to the defined size of the array. So the directional and nominal state is to be filled. So it would be a glass half filled/full.

JS

var glass = [];

var secondGlass = [1,2,3,4,5,6];

Now this looks, at first glance as if you can have an initial state of both empty and full BUT.... since it uses C++ in the actual V8 engine running the javascript stuff, it still requires initialization of an empty array before filling it. Sooo....

Conclusion

Any container's initial state is empty, and to be useful, it's desired state is to be filled meaning it's half-filled at the time it's at 50%.

vscode-slides

Marko V — Sat, 11 Apr 2020 08:34:14 +0000

note: This will be the second time I write this post. If this vanished in thin air, I'll just give up....

I had a presentation last monday regarding linting this was to ensure the spread of knowledge of the causes and solutions to the problems they encounter. Also what linting is and why we do it.

So for that presentation I wanted to find a different presentation tool than powerpoint because if everything else can be expressed in code, why not a presentation? Just a short google away I found vscode-slides which seemed to fit my needs. I tried it out and it had two pain points.

It overwrote/didnt adhere to my settings in settings.json of the workspace. And sometimes it even overwrote the settings that existed there with it's own default ones.

I raised issues regarding these two things in the github project for the extension and for one of them I was referred to an old ticket that was similar, but not quite the same. However they also wanted to have a manner of changing/having custom settings that were not overwritten. So I started by forking the project and making changes to support the specified .slidesrc file that the author figured would solve it.

Long story short, I made a PR and the author was inspired to do additional changes and merge it with my PR and now there's a new version of the extension out! Check it out

Time estimation

Marko V — Thu, 02 Apr 2020 10:22:00 +0000

This is one of the hardest things a developer can do as it builds expectation in business which you may or may not be able to meet. Depending on the business you are dealing with, it may even be important to write down each estimation explicitly so that they can track it thouroughly and any excess time required you just won't get paid for.

So it really is different for each developer and their situation so I won't dig too deeply into that, but the main idea behind all of them is basically getting control over your time and development process.

So there are a few steps to get there.

The What and The Why

Is your task detailed and clear enough for you to be able to see the whole process ahead of you? Is it sufficiently split up into smaller pieces so it's not one big task that really should be an epic (a larger descriptive task that just generally describes a feature that the sub-tasks define more clearly). And if it's a full-stack development, does the task require it to be split up further or is the change small enough to be contained in the task (since there are interconnected dependencies)

Each specific development task should be small enough for you to be able to express psuedo-code for it that takes just as long to read as the specification. It's kind of like converting human-readable-text into, for the lack of a better term, nerd-speech.

Also, do challenge your client/product-owner in the task itself, what is it they're trying to solve and why it has to be solved the way they've described? Is there already another tool available for that purpose. Why reinvent the wheel? Maybe it's incorporating that existing tool into your application, but atleast you will then have an understanding of the requirement and what business need it meets.

The How

Now that the task is clear enough as to what is expected, do you know HOW to do it? If not, reflect back to when you were studying, or learning a new paradigm or pattern in coding... how long did it take to learn that and what was produced out of it. Because if you consider that you can learn and solve the problem at the same time, you can be quite efficient.

If you know what to do, how often do you do it? Is it in the back of your mind or do you need to refer to other pieces of code for a refresher?

The When

In terms of your overall work-load, when in time can this be performed? Are you already overencumbered with tasks so this has to fit into the next sprint?

The Where

Now this is just to complete the 5 questions, but if you are new to the project or workplace, or maybe you're a freelancer working with a new client, do they have any process tools for you to follow up on your progress with. JIRA or similar ... The physical "where" I hope would be in your chair infront of your computer.

And in these corona times, at home.

Stay home. Stay safe.

I.can.has("cheezeburger")

Marko V — Mon, 23 Mar 2020 22:31:41 +0000

When I was a youngin', there was a site called icanhas.cheezeburger.com...

I have been eyeing the mocha/chai/expect framework just for the sake of understanding/learning how it works in relation to the javascript internals to get that kind of behavior. And I was reminded of the old website, icanhas.cheezeburger.com when I saw someone name their check for undefined or null in a nested object to "has". So... I set on to improve on that code (because it was relying on implicit checks) as well as making my own funny version of it.

May I introduce the "I" function.

var food = { hamburger: false } 
I(food).can.has("cheezeburger");

So this is using ES2015 style code, in that it's not a class that you strictly need to new up, it also uses Object.defineProperty to make getters/setters and it's compatible with IE11. However it also uses an anti-pattern which really isn't OK strictly speaking, since there's a getter that modifies state, but the way that this function is used is also not a common/natural pattern in javascript world, only in unit-tests, so you could argue that it's OK.

So let's walk through it.

The first thing is that the function needs to keep to a fluent-like API where you can just keep on chaining methods/functions/properties from it because they all return a modified version of the function. So that's why a getter used in this way where it modifies state is considered OK because of the fluent-like api but using the getter as a necessary evil to provide that type of functionality that otherwise would have required a function call/invocation to be able to provide it.

This means that every property needs to return an instance of this unless it's a terminating expression/word. Like ".is.undefined" or similar. Now undefined was unfortunately a protected word. I was not able to override it in ES2015 style code, so I would have to dig a little deeper to see how mocha/chai does it

After initial checks it seems that it's using an Object internal function to override the default for a property if it already exists. So I'm not gonna do that for this.

So non-terminal getters always return the same instance is how we chain them without using a function-call. Since a property-getter is accessed just like any javascript object property

var normalObj = { prop: "value" }
> normalObj.prop
"value"

var objWithGetter = {}
Object.defineProperty(objWithGetter, 'prop', { get: function() { return "value"; }});

> objWithGetter.prop
"value"

Now it may not be apparent why this is an advantage, but it sort of gives you access to a function that can perform evaluation at access-time rather than pre-computing a value to a normal property. This is the key-ingredient for this type of functionality.

So what properties do we want? Well.... "I" is taken care of as the function name. We could choose to make it a static-like function that takes no parameters. But then we'd have to instantiate itself much later in the chain and there's no real advantage to that. So true to the mocha/chai pattern, we'll add the object we're working with when calling the function. I(food).

can, as a property really doesn't add anything to the chain. It could potentially add a flag saying that following this statement in the chain the end-property has to be a function, or something, it's a stretch of the mind to attribute the name "can" as a moniker for a function. But for me, it doesnt add anything, so all it does, is just return the same instance untouched.

has, as a property is just a function that checks for the existence of something and returns true/false. The function itself is based off of this SO article with a few improvements.

And then it would be a very small function/class if we ended it there. So I extended it with a not as well as null or undef checks, to make it slightly more useful.

not, as a property actually modifies state of the instance before returning an instance reference. It flips an internal boolean when used. So technically speaking you could chain it indefinitely and it would toggle it on/off all the time.

null, as a property just checks if the initial object provided is equal to null

undef, as a property checks if the intial object provided is equal to undefined

So with these properties, null, undef and has are the terminators as they dont return an instance of the function/class when they return a value. Ofc you could make it so that they do and you add a value property that contains the end-result. So that you always have an instance to work with. But I guess that's just a flavor of choice.

Trying to reconcile not instantiating/newing up a class/function but still maintain an instance for the sake of syntax, was a bit trickier than I wanted, so I ended up just making sure that we're not overwriting "this." whenever the function was called. This in the end, became cleaner than doing it the "proper" way.

function I(obj) {
    this._obj = obj;
    this._negate = false;
    if(!this.can) Object.defineProperty(this, 'can', { get: function() { return this; } });
    if(!this.is) Object.defineProperty(this, 'is', { get: function() { return this; } });
    if(!this.not) Object.defineProperty(this, 'not', { get: function() { this._negate = !this._negate; return this; } });
    function everyProp(currObj) {
        return function(prop) {
            if( typeof currObj === "undefined" || currObj === null || !(prop in currObj))
                return false;
            currObj = currObj[prop];
            return true;
        };
    }
    this.has = function(key) {
        var tObj = this._obj;
        const returnObj = key.split(".").every(everyProp(tObj));
        if (this._negate) return !returnObj;
        return returnObj;
    };
    if(!this.undef) Object.defineProperty(this, 'undef', { get: function() { 
        if(this._negate) return typeof this._obj !== "undefined";
        return typeof this._obj === "undefined"; 
    }});
    if(!this.null) Object.defineProperty(this, 'null', { get: function() { 
        if(this._negate) return this._obj !== null;
        return this._obj === null; 
    }});
    return this;
}

var food = { hamburger: false } 
console.log(I(food).can.not.not.has("cheezeburger"));

So can I? node has.js

false

FeelsBadMan

UT(e), no flatbed, but a testbed.

Marko V — Sat, 21 Mar 2020 23:37:41 +0000

Did I touch on this? Maybe. TDD is one way of doing things, personally I think it's quite difficult to think of all the scenarios that you may end up with and you'll come to make changes/additions to your unit-tests anyway after the fact which sort of just starts you off with TDD and then devolves into normal development cycle where your progress in development keeps being interrupted by having to add new unit-tests because of an if-statement or similar condition that requires immediate changes to be true to the TDD approach.

TDD also is quite ambitious, sometimes you can't do it that way because you end up spending a lot of time to do unit-tests, and as we all know, sometimes you may scrap entire paths because you realize that wasn't the right approach. If you've then spent 4 times longer on that code-path it might hurt even more than you'd like.

So back to the task at hand. I have recently downloaded a JSON file containing all of Cards Against Humanity and started applying ES6 classes and some logical functions and utility functions to consume it. So let's create some unit-tests for these. I do some validations in the constructor of these classes to ensure that you can't insert invalid value-types into the specific fields when it parses and creates card-instances.

So let's get crackin.

First of all, I'm installing mocha and nyc, mocha is the testing framework, and nyc (istanbul) is the code-coverage wrapper/reporting tool for unit-testing. npm install mocha chai nyc mocha-multi-reporters --save-dev

Note that when I did this, I encountered an issue with chai/mocha not being able to find util.promisify
Just install it with npm install util.promisify --save-dev if you encounter this.

So let's analyze the first test that we should do. Now here approaches may differ, but I feel that I don't necessarily need to do a test per constant defined in a class but I can do a single constant-check to wrap all of them in multiple asserts.

class Utility {
    CONST_SMALL_TAG_START = "<small>";
    CONST_SMALL_TAG_END = "</small>";
    CONST_BR_TAG = "<br/>";
    CONST_BR_TAG2 = "<br>";
    CONST_I_TAG_START = "<i>";
    CONST_I_TAG_END = "</i>";
    CONST_B_TAG_START = "<b>";
    CONST_B_TAG_END = "</b>";
...

describe('Utilities', function() {
    it('should validate the static constants expected in the class', function() {
        expect(Utility.CONST_SMALL_TAG_START).to.equal("<small>");
        expect(Utility.CONST_SMALL_TAG_END).to.equal("</small>");
        expect(Utility.CONST_BR_TAG).to.equal("<br/>");
        expect(Utility.CONST_BR_TAG2).to.equal("<br>");
        expect(Utility.CONST_I_TAG_START).to.equal("<i>");
        expect(Utility.CONST_I_TAG_END).to.equal("</i>");
        expect(Utility.CONST_B_TAG_START).to.equal("<b>");
        expect(Utility.CONST_B_TAG_END).to.equal("</b>");
    });
...

They don't think it be like it is, but it do.

Now there was a scenario as I was writing this, where I saw a possible bug so I caught it and created a test-scenario for it. It was quite small, it was a number-coercion of null to 0, that was a side-effect which I didn't want. I spotted it because I expected null coercion to 0 to not be true. But it do.

Now later on as I was creating more scenarios to include into this blog, I also saw a happy-path that was made. And also as I was writing that code I accepted early on that I would not be writing defensive code for it. However, in the spirit of this post, I set on to make an improvement on it through the TDD-process.

The original function

    static getStackByCategory(stack, stackKey) {
        return stack.filter(c=>c.category.key === stackKey);
    }

So what's wrong with it?
Well first of all, ensure all variables you're dependent on, exist and won't throw an error before using them. So which ones do we have?

stack = We don't know if this is an array so that the filter-method/function is available to us. So that's the first thing to ensure. Next, we don't know if the items in the array contain a category property before enumerating it and using the key property inside of it.

we don't know if stackKey is defined or not before comparing against it, however since it's on the right hand side of the comparison, it's not as "bad" as it could be. Because it's checking against a defined value vs an undefined or null reference... that means they just simply won't be equal. However, for our sanity's sake, we should check it.

I created tests, that tries to use this function in each of those scenarios, so either you define an array of inline-data and re-iterate the same test for each or you create separate it-entries for the scenarios. I went with the latter.

The end-resulting function-refactoring became this;

static compareCategoryKey(key) {
  return function(c) {
    if(!Utility.isStr(key)) return false;
    if(Utility.isNuN(c) && Utility.isNuN(c.category) && Utility.isStr(c.category.key)) {
      return c.category.key === key;
    }
    return false;
  }
}
static getStackByCategory(stack, stackKey) {
  if(!Array.isArray(stack)) return [];
  return stack.filter(Utility.compareCategoryKey(stackKey));
}

Example tests for the above scenario

it('should not throw an error when a card has a category and category.key but key is not a string', function() {
  let badCard3 = { category: { key: 0 }};
  let badStack = [badCard3];
  let response = null;
  try {
    response = Utility.getStackByCategory(badStack,"heythere");
  } catch(err) {
    expect(err).to.be.undefined;
  }
  expect(Array.isArray(response)).to.be.true;
  expect(response.length).to.be.equal(0);
});

it('should return an empty array when the category key to check for is not a string', function() {
  let goodCard = { category: { key: "heythere" }};
  let goodCardNoMatch = { category: { key: "nope" }};
  let goodStack = [goodCard, goodCardNoMatch];
  const response = Utility.getStackByCategory(goodStack,5);
  expect(Array.isArray(response)).to.be.true;
  expect(response.length).to.be.equal(0);
});

Now with all of that, just repeat to your heart's content, you'll eventually reach 100% code coverage. Not that it's required or anything, it just feels good. Don't you think? nyc mocha helpers/*.test.js --recursive

(Normally you could quit at somewhere between 50% or 80% depending on scale of things)

File	% Stmts	% Branch	% Funcs	% Lines	Uncovered Line #s
All files	100	100	100	100
Utility.js	100	100	100	100

Finally, my tip for unit-testing; Always be explicit with your checks, it will make writing the tests much easier, and side-effects also easier to detect.

Example Utility class

class Utility {
    static CONST_SMALL_TAG_START = "<small>";
    static CONST_SMALL_TAG_END = "</small>";
    static CONST_BR_TAG = "<br/>";
    static CONST_BR_TAG2 = "<br>";
    static CONST_I_TAG_START = "<i>";
    static CONST_I_TAG_END = "</i>";
    static CONST_B_TAG_START = "<b>";
    static CONST_B_TAG_END = "</b>";

    static isNuN(obj) {
        return typeof obj !== "undefined" && obj !== null;
    }
    static isStr(obj) {
        return Object.prototype.toString.call(obj) === "[object String]";
    }
    static isNum(obj) {
        if (!this.isNuN(obj)) return false;
        return !isNaN(Number(obj));
    }
    static compareCategoryKey(key) {
        return function(c) {
            if(!Utility.isStr(key)) return false;
            if(Utility.isNuN(c) && Utility.isNuN(c.category) && Utility.isStr(c.category.key)) {
                return c.category.key === key;
            }
            return false;
        }
    }
    static getStackByCategory(stack, stackKey) {
        if(!Array.isArray(stack)) return [];
        return stack.filter(Utility.compareCategoryKey(stackKey));
    }
    static genNumbers(amount, max) {
        const returnArr = [];
        for(let i=0;i<amount;i++) {
            returnArr.push(Utility.genNumber(max, returnArr, amount));
        }
        return returnArr;
    }
    static genNumber(max, existing, amount) {
        if(Utility.isNuN(existing) && Utility.isNuN(amount) && Utility.isNum(max)) {
            for(let i=0;i<existing.length+amount;i++) {
                let newNum = this.genNumberPrivate(max);
                if(existing.indexOf(newNum) === -1) return newNum;
            }
        } else if(Utility.isNum(max)) {
            return this.genNumberPrivate(max);
        }
        return -1;
    }
    static genNumberPrivate(max) {
        return Math.floor(Math.random()*max);
    }
    static getItemsAtIndexes(arr, items) {
        if(Array.isArray(arr)) {
            const retArr = [];
            arr.forEach(idx=> {
                if(Utility.isNum(idx)) {
                    if (idx < items.length && idx > -1) {
                        retArr.push(items[idx]);
                    }
                }
            });
            return retArr;
        }
        return [];
    }
}

module.exports = Utility;

Example Mocha Test

const expect = require('chai').expect;
const Utility = require('./Utility');
describe('Utilities', function() {
    it('should validate the static constants expected in the class', function() {
        expect(Utility.CONST_SMALL_TAG_START).to.equal("<small>");
        expect(Utility.CONST_SMALL_TAG_END).to.equal("</small>");
        expect(Utility.CONST_BR_TAG).to.equal("<br/>");
        expect(Utility.CONST_BR_TAG2).to.equal("<br>");
        expect(Utility.CONST_I_TAG_START).to.equal("<i>");
        expect(Utility.CONST_I_TAG_END).to.equal("</i>");
        expect(Utility.CONST_B_TAG_START).to.equal("<b>");
        expect(Utility.CONST_B_TAG_END).to.equal("</b>");
    });
    describe('is-Not-Undefined-or-Null helper function', function() {
        it('is undefined returns false', function() { expect(Utility.isNuN(undefined)).to.be.false; });
        it('is null returns false', function() { expect(Utility.isNuN(null)).to.be.false; })
        it('is "undefined" returns true', function() { expect(Utility.isNuN("undefined")).to.be.true; })
    });
    describe('is-String helper function', function() {
        it('is undefined returns false', function() { expect(Utility.isStr(undefined)).to.be.false; });
        it('is null returns false', function() { expect(Utility.isStr(null)).to.be.false; })
        it('is "undefined" returns true', function() { expect(Utility.isStr("undefined")).to.be.true; })
        it('is 5 returns false', function() { expect(Utility.isStr(5)).to.be.false; })
        it('is {} returns false', function() { expect(Utility.isStr({})).to.be.false; })
    });
    describe('is-Number helper function', function() {
        it('is undefined returns false', function() { expect(Utility.isNum(undefined)).to.be.false; });
        it('is null returns false', function() { expect(Utility.isNum(null)).to.be.false; })
        it('is "undefined" returns false', function() { expect(Utility.isNum("undefined")).to.be.false; })
        it('is 5 returns true', function() { expect(Utility.isNum(5)).to.be.true; })
        it('is {} returns false', function() { expect(Utility.isNum({})).to.be.false; })
    });
    describe('getStackByCategory helper function', function() {
        //setup
        let badCard = { nocategory: { }};
        let badCard2 = { category: { }};
        let badCard3 = { category: { key: 0 }};
        it('should return an empty array if stack is not an array', function() {
            let badStack = {};
            const response = Utility.getStackByCategory(badStack,"heythere");
            expect(Array.isArray(response)).to.be.true;
            expect(response.length).to.be.equal(0);
        });
        it('should return an empty array if stack is an empty array', function() {
            let badStack2 = [];
            const response = Utility.getStackByCategory(badStack2,"heythere");
            expect(Array.isArray(response)).to.be.true;
            expect(response.length).to.be.equal(0);
        });
        it('should return a single match', function() {
            let goodCard = { category: { key: "heythere" }};
            let goodCardNoMatch = { category: { key: "nope" }};
            let goodStack = [goodCard, goodCardNoMatch];
            const response = Utility.getStackByCategory(goodStack,"heythere");
            expect(Array.isArray(response)).to.be.true;
            expect(response.length).to.be.equal(1);
        });
        it('should not throw an error when a card is undefined', function() {
            let badStack = [undefined];
            let response = null;
            try {
                response = Utility.getStackByCategory(badStack,"heythere");
            } catch(err) {
                expect(err).to.be.undefined;
            }
            expect(Array.isArray(response)).to.be.true;
            expect(response.length).to.be.equal(0);
        });
        it('should not throw an error when a card is missing category property', function() {
            let badStack = [badCard];
            let response = null;
            try {
                response = Utility.getStackByCategory(badStack,"heythere");
            } catch(err) {
                expect(err).to.be.undefined;
            }
            expect(Array.isArray(response)).to.be.true;
            expect(response.length).to.be.equal(0);
        });
        it('should not throw an error when a card has a category but no category.key property', function() {
            let badStack = [badCard2];
            let response = null;
            try {
                response = Utility.getStackByCategory(badStack,"heythere");
            } catch(err) {
                expect(err).to.be.undefined;
            }
            expect(Array.isArray(response)).to.be.true;
            expect(response.length).to.be.equal(0);
        });
        it('should not throw an error when a card has a category and category.key but key is not a string', function() {
            let badStack = [badCard3];
            let response = null;
            try {
                response = Utility.getStackByCategory(badStack,"heythere");
            } catch(err) {
                expect(err).to.be.undefined;
            }
            expect(Array.isArray(response)).to.be.true;
            expect(response.length).to.be.equal(0);
        });

        it('should return an empty array when the category key to check for is not a string', function() {
            let goodCard = { category: { key: "heythere" }};
            let goodCardNoMatch = { category: { key: "nope" }};
            let goodStack = [goodCard, goodCardNoMatch];
            const response = Utility.getStackByCategory(goodStack,5);
            expect(Array.isArray(response)).to.be.true;
            expect(response.length).to.be.equal(0);
        });
    });
    describe('genNumber', function() {
        it('should return a single number non -1 if max is a number and not providing any other properties', function() {
            let response = null;
            try {
                response = Utility.genNumber(5);
            } catch(err) {
                expect(err).to.be.undefined;
            }
            expect(response).to.be.greaterThan(-1);
            expect(response).to.be.lessThan(6);
        });
        it('should return a single -1 if it is unable to randomize a unique entry into the array', function() {
            let response = null;
            try {
                response = Utility.genNumber(1, [0,1], 3);
            } catch(err) {
                expect(err).to.be.undefined;
            }
            expect(response).to.be.equal(-1);
        })
    });
    describe('genNumbers', function() {
        it('should not throw an error and return empty if provided a string as amount', function() {
            let response = null;
            try {
                response = Utility.genNumbers("asd", 10);
            } catch(err) {
                expect(err).to.be.undefined;
            }
            expect(response).to.not.be.null;
            expect(Array.isArray(response)).to.be.true;
            expect(response.length).to.be.equal(0);
        });
        it('should not throw an error and return an array with -1 if provided an amount but not max', function() {
            let response = null;
            try {
                response = Utility.genNumbers(1, "asd");
            } catch(err) {
                expect(err).to.be.undefined;
            }
            expect(response).to.not.be.null;
            expect(Array.isArray(response)).to.be.true;
            expect(response.length).to.be.equal(1);
            expect(response[0]).to.be.equal(-1);
        });
        it('should not throw an error and return an array with numbers if provided an amount and max', function() {
            let response = null;
            try {
                response = Utility.genNumbers(2, 10);
            } catch(err) {
                expect(err).to.be.undefined;
            }
            expect(response).to.not.be.null;
            expect(Array.isArray(response)).to.be.true;
            expect(response.length).to.be.equal(2);
        });
    });
    describe('getItemsAtIndexes', function() {
        it('should return an empty array if arr-param is a string', function() {
            let test1 = Utility.getItemsAtIndexes("asd", [1,2,3,4,5]);
            expect(test1).to.not.be.undefined;
            expect(Array.isArray(test1)).to.be.true;
            expect(test1.length).to.be.equal(0);
        });
        it('should return an empty array if arr-param is a number', function() {
            let test2 = Utility.getItemsAtIndexes(0, [1,2,3,4,5]);
            expect(test2).to.not.be.undefined;
            expect(Array.isArray(test2)).to.be.true;
            expect(test2.length).to.be.equal(0);
        });
        it('should return an empty array if arr-param is an object', function() {
            let test3 = Utility.getItemsAtIndexes({}, [1,2,3,4,5]);
            expect(test3).to.not.be.undefined;
            expect(Array.isArray(test3)).to.be.true;
            expect(test3.length).to.be.equal(0);
        });
        it('should return an empty array if arr-param is an object with enumerable properties', function() {
            let test4 = Utility.getItemsAtIndexes({"key":"value"}, [1,2,3,4,5]);
            expect(test4).to.not.be.undefined;
            expect(Array.isArray(test4)).to.be.true;
            expect(test4.length).to.be.equal(0);
        });
        it('should return an empty array if arr-param is an empty array', function() {
            let test = Utility.getItemsAtIndexes([], [1,2,3,4,5]);
            expect(test).to.not.be.undefined;
            expect(Array.isArray(test)).to.be.true;
            expect(test.length).to.be.equal(0);
        });
        it('should return an empty array if arr-param is an array with non-numbers', function() {
            let test = Utility.getItemsAtIndexes(["asd"], [1,2,3,4,5]);
            expect(test).to.not.be.undefined;
            expect(Array.isArray(test)).to.be.true;
            expect(test.length).to.be.equal(0);
        });
        it('should not throw an index-out-of-bounds error if arr-param is an array with -1', function() {
            let test = Utility.getItemsAtIndexes([-1], [1,2,3,4,5]);
            expect(test).to.not.be.undefined;
            expect(Array.isArray(test)).to.be.true;
            expect(test.length).to.be.equal(0);
        });
        it('should not throw an index-out-of-bounds error if arr-param is an array with 5 and provided lookup array is only 0-4', function() {
            let test = Utility.getItemsAtIndexes([5], [1,2,3,4,5]);
            expect(test).to.not.be.undefined;
            expect(Array.isArray(test)).to.be.true;
            expect(test.length).to.be.equal(0);
        });
        it('should return expected values at provided indexes', function() {
            let test = Utility.getItemsAtIndexes([1,3], [1,2,3,4,5]);
            expect(test).to.not.be.undefined;
            expect(Array.isArray(test)).to.be.true;
            expect(test.length).to.be.equal(2);
            expect(test[0]).to.be.equal(2);
            expect(test[1]).to.be.equal(4);
        });
    });
});

How to increase your CoQ.

Marko V — Thu, 19 Mar 2020 21:38:47 +0000

Code Quality. What did you think it meant?

I've already written about linting, unit-testing is another and documentation is a third. JSDoc is one way to keep track of things. If you haven't encountered it before, it's a structured way to maintain your in-line comments and make use of it as a documentation tool. You can express the in's and out's of functions, what their usage is, their limitations and dependencies. You can define your modules and classes.. and finally, you can generate an interactive documentation site based on your comments.

So to get started it's quite simple. In Visual Studio, and VS Code, you can start to type "/**" and it will auto-complete the beginnings of a JSDoc entry if it's a .js file. If you do it above the line of a function definition, and you press enter it will auto-complete the parameters for you and all you need to do is add typing (unless that is already clearly defined and the IDE can detect it) and the usage of the parameter.

So to start documenting your code, it kind of looks like this;

Sample

/**
 * Localization Service for angular
 * @exports services/localeService
 * @param {NgModule} $http injection of the AngularJS native $http module (supplies access to XHR requests)
 * @param {NgModule} $window injection of the AngularJS native $window module (supplies access to the window object)
 * @param {NgModule} $q injection of the AngularJS native $q module (supplies promises)
 * @param {NgModule} $cookies injection of the AngularJS native $cookies module (supplies access to cookies)
 * @returns { function } a localeService singleton
 */

@exports defines what this file/function exports/relates to in terms of modules. This one in particular is a part of the shared service modules and is called localeService
@param is quite clear. It defines one of the parameters, what type it is, it's name and what it is used for.
@returns just states the return type and what it contains.

Ok, so now that you've documented everything, well... atleast something, you can now run jsdoc command-line tool to generate the documentation site.

First, install the jsdoc tool

npm i jsdoc -g

Next add a jsdoc config file, you can name it whatever you want, I named mine jsdoc.conf.json

{
  "plugins": [ "plugins/markdown" ],
  "recurseDepth": 10,
  "source": {
    "includePattern": ".+\\.js(doc|x)?$",
    "excludePattern": "(^|\\/|\\\\)_|.+es5.js|.+es2015.js|JsonEditor.js|angular.js|angular-cookies.js|angular-mocks.js|angular-sanitize.js"
  },
  "sourceType": "module",
  "tags": {
    "allowUnknownTags": true,
    "dictionaries": [ "jsdoc", "closure" ]
  },
  "templates": {
    "cleverLinks": false,
    "monospaceLinks": false
  }
}

Next, run the command-line tool. All of our scripts are contained in a hierarchy inside the Scripts folder of our web application, so this is the line I ran.

jsdoc Scripts --recurse -c jsdoc.conf.json

And voilá... a nice documentation site is now available in the output path (which you can change btw). Default an "out" folder is created in the working directory you run this command from.

References;

Full Example (with redacted code blocks)

/**
 * Localization Service for angular
 * @exports services/localeService
 * @param {NgModule} $http injection of the AngularJS native $http module (supplies access to XHR requests)
 * @param {NgModule} $window injection of the AngularJS native $window module (supplies access to the window object)
 * @param {NgModule} $q injection of the AngularJS native $q module (supplies promises)
 * @param {NgModule} $cookies injection of the AngularJS native $cookies module (supplies access to cookies)
 * @returns { function } a localeService singleton
 */
function localeService($http, $window, $q, $cookies) {
    'use strict';
    var self = this;
    /**
     * Function to find out which locale is relevant for the user and if we support it.
     * @returns { string } A string representing the localization moniker.
     * */
    this.resolveBrowserLocale = function () {
      // ... redacted ...
    };
    /**
     * Initialization function that tries to get the current list of valid translations provided by a service
     * @returns { Promise } A promise that contains the translations
     * */
    this.init = function () {
      // ... redacted ...
    };
    /**
     * Waits for the resolution of the translations to retrieve an entry from the resultset.
     * @param { string } entry representing the dotannotated path to lookup a translation for.
     * @param { boolean } debug a true/false value to whether or not output debug data in the console.
     * @returns { Promise } A promise containing the attempted lookup. If it fails to find it, it will return the string provided in entry.
     */
    this.getEntry = function (entry, debug) {
        return $q(function (resolve, reject) {
          // ... redacted ...
        });
    };
    /**
     * A complex function to do translation lookup based on the provided object and property to do lookup on. Multiple paths of execution.
     * @param {any} obj Object that contains values to translate
     * @param {string} propToRepl If provided, it will attempt to do lookup on this property and replace it's content before returning the modified object.
     * @param {string} propToLookUp If provided, it will attempt to do lookup on this property-value compounded with propToRepl and insert the found value in propToRepl
     * @param {boolean} tdebug true/false if truthy it will log data to console.
     * @returns { any } The modified object is returned.
     */
    this.translateObject = function (obj, propToRepl, propToLookUp, tdebug) {
      //... redacted ...        
    };
    /**
     * Internal logger function
     * @param {any} obj Object to inject to console.log
     * @param {any} logthis if defined at all, it will use it as a truthy value and output data to console.
     * @returns {void} It outputs data to console. It has no return value.
     */
    this.logger = function (obj, logthis) {
      // ... redacted ...
    };
    /**
     * Lookup helper function, not intended for external consumption/usage.
     * @param {string} dotValue Lookup value to find.
     * @param {any} logThis if defined, it will log data through the private logger function.
     * @returns {string} A translated string or the original string
     */
    this.getDotAnnotatedValue = function (dotValue, logThis) {
      // ... redacted ...
    };
    /** A promise that contains the initialization status of the singleton and it's returned value */
    this.initialized = this.init();
    this.initialized.then(function (data) { self.data = data; });
    return this;
}
/** Injects the localeService into the angular module myAteaApp.services for others to consume */
angular.module('myApp.services').factory('localeService', ['$http', '$window', '$q', '$cookies', localeService]);

Tags: https://jsdoc.app/index.html#block-tags
Getting started: https://jsdoc.app/about-getting-started.html

Stepping stones: Web Components

Marko V — Fri, 13 Mar 2020 23:13:16 +0000

Today I delved into web components to learn the innards of web components, before getting into angular elements and understanding how angular elements wraps the native stuff.

So I did a floating icon, wrapping a little bit of functionality before rendering content. It's like a preamble to a work-related task where I will create a common floating container-area for our floating buttons for things like chat, surveys, etc.

Initial thoughts

I keep IE11 in the back of my head, and so many things, need to be "reworked" to get this to function in IE11, even a basic thing such as this. Ignoring the ES6 class issue it was quite easy to get the "bound" properties. However, all bound properties are sent as strings, so no fancy schmancy conversions happening.

So to send an object, it would be sent as a string or you need to do so atleast, and functions are also passed as string, so you could eval() those, for better or worse, mostly worse, or if it's non-native events that you wish to raise, you can just raise them normally and parent elements can capture them through addEventListener or similar methodology.

The template

If I wanted to make something entirely self-contained, I had to create the elements through JS and not through a template definition made in an html file because then you would have to have that template in the consuming markup. Maybe that's not a problem for you. But for the intents that I have, where I want to be able to ship out custom components to other projects disconnected from mine, that's not ideal.

So I had to do a fair bit of document.createElement() in my code to detach it from that dependency and have my "template" through code.

I'll have to go over this code once more to make it IE11 safe.

It was surprisingly easy to get started from scratch. Next part of this will likely be angular elements or the IE11 variation.

chatButton.js

customElements.define('chat-button',
    class extends HTMLElement {
        _imgSrc = "";
        _initials = "";
        constructor() {
            super();
            this.parseImg();
            this.parseInitials();
            const buttonContent = document.createElement("span");
            buttonContent.id= "chat-button-content";
            buttonContent.addEventListener("click", this._clickFn);
            if(this._imgSrc !== "") {
                let img = document.createElement("img");
                img.src = this._imgSrc;
                img.className = "chat__icon";
                buttonContent.appendChild(img);
            } else {
                let initSpan = document.createElement("span");
                initSpan.textContent = this._initials;
                initSpan.className = "chat__initials";
                buttonContent.appendChild(initSpan);
            }
            const randomColor = this.getRandColor();
            const style = document.createElement("style");
            const styleStr = `
                #chat-button-content {
                    display: inline-block;
                    height: 50px; 
                    width: 50px;
                    border-radius: 50px;
                    box-shadow: 2px 2px 3px #999;
                    overflow: hidden;
                    text-align: center;
                    margin: 5px;
                    ${this._imgSrc === ""?"background-color: " + randomColor: ""}
                }
                #chat-button-content > .chat__icon {
                    margin: auto; 
                    width: 50px;
                    height: 50px;
                    max-width: 200px;
                }
                #chat-button-content > .chat__icon > img {
                    position: absolute;
                    left: 50%;
                    top: 50%;
                    height: 100%;
                    width: auto;
                }
                #chat-button-content > .chat__initials {
                    vertical-align: center;
                    line-height: 50px;
                }`;
            style.textContent = styleStr;
            var wrapper = document.createElement("div");
            wrapper.appendChild(style);
            wrapper.appendChild(buttonContent);
            this.attachShadow({mode: 'open'}).appendChild(wrapper);
        }
        getRandomInt(max) {
            return Math.floor(Math.random() * Math.floor(max));
        }
        getRandColor() {
            const r = this.getRandomInt(16).toString(16);
            const g = this.getRandomInt(16).toString(16);
            const b = this.getRandomInt(16).toString(16);
            return "#" + r+g+b;
        }
        parseImg() {
            const img = this.getAttribute("img");
            if(Object.prototype.toString.call(img) === "[object String]" && img !== "") {
                this._imgSrc = img;
            } 
        }
        parseInitials() {
            const initials = this.getAttribute("initials");
            if(Object.prototype.toString.call(initials) === "[object String]" && initials !== "") {
                this._initials = initials;
            }
        }

        /// LIFE-CYCLE
        connectedCallback() {
            console.log("Connected.");
        }
        disconnectedCallback() {
            console.log('Disconnected.');
        }          
        adoptedCallback() {
            console.log('Adopted.');
        }
        attributeChangedCallback(name, oldValue, newValue) {
            console.log('Attributes changed.', name, oldValue, newValue);
        }
    }
);

index.html

<html>
    <head>
        <title>
            WebComponent test
        </title>
        <script defer src="chatButton.js"></script>
        <style>
            .chat__container {
                position: fixed;
                bottom: 60px;
                right: 60px;
            }
        </style>
        <script>
            function _myClickFunction() {
                console.log("Callback!");
            }
        </script>
    </head>
    <body>
        <div class="chat__container">
            <chat-button onClick="_myClickFunction()" img="https://vision.org.au/business/wp-content/uploads/sites/14/2019/08/1600-business-success.jpg" initials="AD"></chat-button>
            <chat-button initials="JD"></chat-button>
        </div>
    </body>
</html>

reference;
https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM
https://github.com/mdn/web-components-examples/blob/master/popup-info-box-web-component/main.js

Blah blah blah cloud, blah blah blah cloud.

Marko V — Tue, 10 Mar 2020 21:41:10 +0000

Requirements:

All user-relations are to be centralized for GDPR reasons.
Be able to create a ticket with an on-time provisioned user in remote system.
User must be able to be on-time provisioned at login time.
User experience during login process cannot deteriorate.

Login process

We use Auth0 currently in our infrastructure to authenticate and authorize users. Now Auth0 allows something called rules to execute in the login process before passing on the JWT back to the calling application. There are some limitations to this. Per rule there is a limit on amount of ms of execution time before the rule is discarded. There is also a limit on the total amount of seconds before the entire rulechain is discarded.

So adding more into the rule chain to be executed synchronously/awaited async calls, will increase the total login time for a user.

The process itself is without any meaningful or informative graphics or copy telling them what is happening. Just a short loader and a bunch of redirects and stalled pages.

Improvement

So here we can improve things. Not only can we scale down the rule-chain into bare essentials and offload everything else into a queue/service-bus/event-hub/etc (Azure Service Bus) and we could do websocket/long-running polls (SignalR) to get status updates on the login process, it wouldn't matter how much we add into it, but the user gets to know that we're doing something. Even if we're not explicitly telling them exactly what, they get something pretty to look at before we return them to the calling application.

So now we can ensure any number of remote systems being able to get auto-created users if they are not already created.

The rest of the owl...

The same system then, that is listening to the queue, also has API endpoints exposed to manually fire off requests with payloads saying things like "take this user's JWT, create the user in system X in country Y" and the abstraction in that auto-provisioning API will handle it.

Not particularly ground breaking since these kinds of loaders are quite abound, but considering the backend systems we have to deal with, it's a nice upgrade.

Summary

The first part is solved where we can maintain the already established centralized user-store.

The second and third parts are solved by being able to initiate remote system synchronization/on-time-provisioning through it's integration layer either through a queue or direct API calls.

And the fourth part is solved by that SignalR enabled spinner-app that awaits user to be fully finished with their login process by listening/watching that signoff of the user in the event-stream.

Do I make myself clear

Marko V — Tue, 10 Mar 2020 08:57:09 +0000

We had some late night work and testers found what they considered a bug. A developer was set to solve it according to the task set forth, and he made a PR. At 7pm I get a request to approve this PR for this new task.

The problem: An input that was defaulted to 1, when decreased to 0 was then unable to be increased again.

Testers solution: Disallow 0 values, preset to 1 as minimum.

The testers that wrote the task, did not just describe the issue but also attributed a solution path for the developer rather than letting the developer do the analyze to find the true solution. Also the task had UX opinions without involving the designer that is responsible for the UX guidelines.

And in all of this, they lost track of the future and what is to come. All involving parties knew of the upcoming sprint(s) where we will be developing further upon this and would need to be able to 0 out a value without side-effects.

After some discussions with the tester and reminding them of the change to come, I steered them on the path to solving the true cause and letting the developer do the analyzing of the issue. Once that was done, we resolved the side-effect of not being able to increase from 0.

So my take away from this;

Remember what is to come and the bigger picture so you don't paint yourself into a wall and then have to re-paint everything because you've created something that is non-transferable and will not behave the same way in the next turnover.
Don't impose UX guidelines if there are no clear ones. Instead defer to the Designer that is responsible for them.
Let the developer do the analyzing and find a path that conforms to both of the above points.

Also, don't do PRs at 7pm. Take some time off.

Down the rabbit hole we go!

Marko V — Fri, 06 Mar 2020 17:37:41 +0000

One part of my migration plan to angular typescript is also to get rid of something we called "page scripts" which basically were a bunch of globally registered jQuery scripts that were pertinent to a certain page but not limited to a certain controller or directive but enacted upon all or multiple rendered components. It was a way to previously get some code-reuse across parts where the developer was not aware of how to do it through services or similar approaches.

With that explained, I now went down the rabbit hole of checking "What is this function used for and is it needed anymore?"-queries... There was one particular one that removed and added a class to an input's child element if you clicked on the input and if you clicked outside of it.

We have similar functionality that recently got converted into a component, so I checked that component and it also had some issues. It was also binding to the document and with a global click event. Manipulating the DOM or attaching to "outside" isn't a desirable thing as it may introduce unnecessary or unexpected DOM manipulations or cause serious side-effects. There's an isolate scope for a reason.

So.... to get some code-reuse and reusing that drop-down component, I have to first fix that so it's keeping to itself, then replace all instances of a dropdown multi-select element with that shared component instead and once that is done I can remove the pageScript code.

I'm feeling a little bit like Hal from Malcom in the middle.

AngularJS Component Directives

Marko V — Thu, 05 Mar 2020 21:35:26 +0000

A little background... Our application started way back when AngularJS was in it's infancy and it's SPA functionality and routing left much to desire. So we started off using AngularJS as just a binding framework ontop of MVC Views. Now we managed to create a lot before angularjs became manageable as a SPA framework, but by then, it would mean a lot of work to get it to be a SPA so we just skipped it and Angular 2 (TS) was just around the corner.

Years later...

Time has passed and management saw little use in updating the frameworks and keeping upto date, pushing for new features and functionality. Our technical debt increased. Now finally, after a few years, we have managed to convince management that certain efforts are required before we get to a point where we can't continue due to outdated frameworks and no support in the platform.

And now...

Part of that migration to Angular 8 and SPA, is an intermediary step to create AngularJS component directives for everything meaning all controllers, all directives, are converted. Services are services, just using the factory method to implement them. That last one was thankfully an easy conversion.

Our angular 1 controllers were HUGE. One controller could provide data, and juggle views between a small dashboard view, a list view and a detail view... all in one. And one big (CS)HTML file.

Now, when approaching Component Directives, we're going the opposite... as small as possible and as many reusable components as possible. One of these components that I just made, is a toggle component. We have something called featuretoggles in our application which means that product owners can pick and choose which parts of the developed application they want to activate in their own instance.

Now we used to use razor to select out which parts to show based on those featuretoggles, but now all razor stuff is moved out and refactored into api endpoints that the clientside can use. We have an angularjs service that provides the data and simple functions for lookups and other helper functions.

However, until recently, we used the service in just about every component we have and reused the service functions to find, check and choose paths regarding whether or not to activate a child-component based on the toggles used.

Now I abstracted this into it's own component using something called transclusion in angular.

So, what is transclusion? It is a way to make your component accept content inside it's tags and dedicate a location for that content inside your template.

Example;

<toggle>
  <h1>Internal content in toggle-component</h1>
</toggle>

angular.module('myApp.shared').component("toggle", {
    transclude: true,
    template: `
          <div ng-if="$ctrl.error !== \'\'">{{$ctrl.error}}</div>
          <ng-transclude ng-if="$ctrl.sumToggle"></ng-transclude>
    `,
    ...
});

So let's break this up in case you haven't encountered a component directive before.

angular.module(String name, String[] dependencies)

angular.module('myApp.shared')

This hooks into angular, telling it that we are about to register a component that belongs to the module "myApp.shared" and also that the myApp.shared is defined elsewhere with it's core dependencies because we are not providing it here. If we were, it would be a secondary parameter to the function containing an array of strings representing other modules that this module would be dependent upon.

Our convention is to register these in the angularApp.js bootstrapping script.

component(String name, Options opt)

component("toggle", { ... })

This registers the component that will be named "toggle" to the module defined previously. Now you can access this component as an element with the name provided. If you were to name it "featureToggle" (notice the camel case) you would be able to access that as <feature-toggle>. The camelcase makes it so that when using the element it itself requires kebab-case to invoke it. One of the quirks of angular. The secondary parameter to component function are the configurations for that component. Such as transclude, bindings, template (or templateUrl), controller and many more...

We will touch on just these but there are more. You will find details about them in the documentation(s) linked herein.

Component Option: transclude

Official documentation: https://docs.angularjs.org/api/ng/directive/ngTransclude

I've so far used transclude in two ways. One where it only says "true" which means it only has a single transclude directive in the template.

I've also used it as a multi-transclusion where we have multiple targets. An example of this would be to define for instance a header transclusion and a footer transclusion. Then you could direct content specifically for these areas in the component like this

<my-component>
   <my-component-header>
       <h1>This is content in the header transclusion</h1>
   </my-component-header>
   <!-- content that my template itself inserts and not shown in the parent DOM/component binding the my-component component-directive -->
   <my-component-footer>
       <h3>This is a footer content</h3>
   </my-component-footer>
</my-component>

Phew, a lot of "component" in there, but it's just a sample. Now to achieve that, you would not just provide "true" but an object representing the ng-transclude targets. For the above example, it would look like

{
  transclude: {
    "header": "myComponentHeader",
    "footer": "?myComponentFooter"
  },
  template: `
    <ng-transclude ng-transclude-slot="header">
       <!-- this is where h1 ends up -->
    </ng-transclude>
    <div>
       <!-- content that is not visible in the parent component injecting this one -->
    </div>
    <ng-transclude ng-transclude-slot="footer">
       <!-- this is where h3 ends up -->
    </ng-transclude>
  `
}

But... with our current example, we kept it simple and used only a single transclude directive in the template and thus also only needed "transclude: true"

Component Option: bindings

Official Documentation: https://docs.angularjs.org/guide/component#component-based-application-architecture

Do note that it says "bindings" not "binding" or "bind", it's "bindings". I know this, and yet I manage to do typos and then be left wondering why it's not working and getting undefined when trying to access the values I pass to the component.

So if you define bindings as such

{
  bindings: {
    debug: "<",
    names: "<"
  }
}

You will have a one-way binding for attributes to your component with the attribute-names "debug" and "names". Used like this;

<toggle debug="true" names="orders,!invoices"></toggle>

So now the binding properties are "magically" available to the controller of the component through "this.debug" and "this.names". However, due to javascript being javascript, I always defer "this" to it's own variable "self" that I can refer to even when I am deep inside nested blocks and scopes so that "this" isn't suddenly the window or document or such, so I refer to them as "self.debug" and "self.names" in my code.

You can pass function callbacks as bindings, so that you can make a on-update attribute that a parent component can bind a function to and you can just call that function inside your new component. One such functionality would be where you do some massaging of data based on user-input and perform a callback that treats the result as that parent component requires it. This is close to how you could use two-way binding, but then the child-component keps on getting updated even when you're not using it unless you despawn it through ng-if. They each have their use-cases so be sure to think things through first or revise it as needs arise. Try to not create hard dependencies from child components to parent components and vice versa. Keeping SOLID principles in mind.

Component Options: template

Now this is likely the simplest one. It's just the HTML string that you will use as a template for your component. Doing it inline will improve performance drastically. You can assign templateUrl option a url but then it will do an XHR request to get that html file when the component loads. So if you have a lot of components, it might take a while depending on the browser's capabilities and limitations. Some browsers only allow 8 concurrent XHR requests. Just an FYI.

Even worse is if you have a template that just adds a div with ng-include directive in it pointing to an HTML file. That will give you the worst of both worlds.

If you need to bind controller variables to the view in the template, you can access them, by default, with the $ctrl prefix like so "$ctrl.debug" much like "this.debug" or for my sake "self.debug" when in the controller itself. You can reassign $ctrl to something else if you like using the controllerAs option. But I prefer to keep it simple and maintain the default $ctrl.

Component Options: controller

The controller option takes a function as it's value. The function parameters provided would be services and providers that angular has available to it to inject based on the names of the parameters. So if you do function($http) it will inject the $http-provider native to Angular and you will be able to use it in your controller as any other variable passed as parameter to a function in javascript. Dependency Injection ftw.

controller: function (toggleService) {
  var self = this;
  ///...
  this.$onInit = function () {
    self.togglesToFind = parseStringOrArray(self.names);
    toggleService.initialized.then(function (toggles) {
      for (var i = 0; i < self.togglesToFind.length; i++) {
        var item = self.togglesToFind[i];
        /// _redacted_ 
        var foundToggle = toggleService.findToggle(toggles.data, item);
        /// _redacted_ 
        if (i === 0) self.sumToggle = foundToggle;
        else self.sumToggle = self.sumToggle && foundToggle;
      }
    });
  };
}

Now toggleService is being injected by angular into this controller. We use it inside the life-cycle event $onInit. This function, if defined in a controller, is called by angular when the component is being initialized. So this is the place to be when massaging inputs to outputs and views.

toggleService provides a promise that all interested parties can "await" before continuing using the data/functions that the service provides to ensure that the singleton service is done and available. The toggleService calls an external API to get data regarding the featuretoggles, so that's why we need to wait for it.

the toggleService also then provides a helper function to do lookup in the resulting toggle-data. We have sanitizied the "names" attribute/binding through the parseStringOrArray function defined in the controller, meaning we will always have an array of strings even if you only provide a single toggle, a comma separated list of toggles or an actual array of strings representing toggles. The redacted code was just allowing added logic-functionality to the inputs irrelevant to this blog post.

Summary

So it summarizes the feature toggles requested, and now looking back at the template, it will only show the content in the transcluded section IF we meet the requirements. Meaning we won't show the child-components if they have not been toggled on. Now we reduced a lot of code-repetition in each of the components by reusing this toggle-component instead. And it makes the html code much more legible.

Reference: https://docs.angularjs.org/guide/component