Posted on

Type assertions

We are supposed to put type definitions on our variables in TypeScript. But I often had to resort to the frowned-upon type any. Here I declare a type for sng but then I cannot use sng for a bog standard shift. The language’s shift method can return undefined. My definition of ITEM (elsewhere) does not allow that because (duh, of course) it is a type definition. I get Type ‘ITEM | undefined’ is not assignable to type ITEM:

I would resort to this:

Yesterday I finally found a better solution. Use a type assertion on the shift:

If a Type Assertion is incorrect it can lead to runtime errors that Typescript would normally prevent. But in this case I am confident that this line of code will never return an undefined value.

sng might be null. It is immediately after it is declared in the first line. That does not matter to the type assertion because 1. the type assertion is only for its own line of code, and 2. I am promising the compiler that this shift will never return something that is undefined. I am not promising it will never return a null.

Posted on

Song-count badges in Egalitarian option

BADGES

Now when you turn on the Egalitarian option, artists that appear in a playlist more than once get a badge that shows their number of songs so far.

Here Counting Stars is the second song by Kool&Klean and A Summer Walk is the third. Cool Desert Night (Synth Remix) is the second song by Bullcrane:

SHUFFLE

With the Egalitarian option turned on, shuffle prioritizes not repeating artists. Badges wind up at the bottom.

If you shuffle more than once and are puzzled by what seems to be inconsistent results, you probably have songs with more than one artist. Here are two egalitarian shuffles of the same four-song playlist. All badges are at the bottom in both. Early placement of the two-artist song causes the first shuffle to start repeating artists at song three:

The second shuffle starts repeating artists at song four: