A nice way to pass along all scoped slots to a component. We can pass all props from the source component to target using this code - <wrapper> <b-table v-bind="$attrs" v-on="$listeners"> <template v-for="(_, slot) of $scopedSlots" v-slot:[slot]="scope" ><slot :name="slot" v-bind="scope" /></template> </b-table> </wrapper> Found this in this StackOverflow post. Why do this? You probably would do this when you have a component that is collating other components to get things done. The source component would then have to proxy what it received to the target components so that any conditional rendering/processing can happen based on inputs.

Assert is a general-purpose validator and should not be used in the context of testing alone. An assert in Javascript simply checks for truthy values and produces an error otherwise. We use it quite a bit in automated testing when checking for correctness of output for pre-defined inputs. We use asserts like so - var assert = require("assert"); function getSum(x, y) { return x + y; } assert(getSum(1, 2) === 3); assert(getSum(3, 6) == 9); The above code block will go through fine since there are no errors, but I am well capable of producing a few errors. ...

Why use unknown when we have any in Typescript? Type inferences are powerful and allows us to do magic when we don’t know types. const i: any = 1; console.log(i); // 1 unknown seems to do the same thing. let x: unknown = 1; console.log(x); So, which to use where? Let us extend the previous examples to put that question to rest. Consider what happens when you try to do any operation on the type. const i: any = 1; console.log(i + 1); //2 const x: unknown = 1; console.log(x + 1); // error TS2365: Operator '+' cannot be applied to types 'unknown' and '1' unknown applies itself enthusiastically to equality operations, asserts and checks, but not for any other operations. ...

Let’s get to know interfaces for functions - yes, that’s a thing. We have seen interfaces used as types and interfaces as array types. Since function is an object and interfaces are supported on other objects, they should be supported on functions also. Right? You betcha. What is this blog if we can’t write about all the stuff that no one care’s about? Well, to be clear - I am not starting that trend today. ...

It’s not the why, but more on what of ‘modules’. No Javascript is an island. It was an island about two decades back but Javascript has done some pretty good land reclaimation to form large continents now. So it goes without saying that these are not the days of writing Javascript or Typescript in <script> tag in a single HTML. A typical project has hundreds of packages and a lot of code written by you and others who hate you. ...

Interface an interface. If that doesn’t excite you, I don’t know what will. We have seen interfaces used as types before. But as our God Goop says - “abstract; (while && when) you can;”. So, we are here to know about interfaces for interfaces. Consider this simple example - interface Borg { name: string; } Now, any class implementing the interface Borg will have a name attribute. What if you want to add more attributes? Well, you can always add attributes to Borg, but what if you have a function that very much likes names and cannot digest anything else? ...

What exactly are interfaces for arrays? Previously we have seen interfaces as types. Interfaces provide useful abstraction on class and can be useful in tricky situations with complex types. But, what about interfaces for array? It turns out interfaces can be as easily applied for array types as well. They are just super useful as interfaces that define complex types and make arrays type-safe - nothing more, nothing less. Interfaces can define type for both array and its values. Let’s see an example. ...

Let’s talk anonymous functions and make them, well, “not anonymous”. Anonymous functions are just functions without names. If you have been following this blog, or have written some Javascript - you surely would have come across them. Anonymous functions are just function expressions. Let’s see a quick example. The following code block has a ’named’ function. function getSum(x: number, y: number): number { return x + y; } We can rewrite the same as an anonymous function and get the same end result. ...

Why and how of using abstract classes in Typescript. We have seen a bit of classes and objects in Typescript previously. There was however a key aspect of object oriented programming missing there. Although we discussed inheriting classes, we never mentioned abstract classes. Sacrilege, that. On the other hand, anything goes for the daily blogging gobble-gobble. Abstract classes are meant to be inherited and are not used directly. Defining such an abstract class is painfully easy. ...

Running out of space? You have VSCode and love tinkering with it? Then do this. Well the introductory line is cheesy and shows desperation for clicks. So, I had to have them. And - no, this is not even a secret. VSCode stays sane until it goes insane with storage space. But somehow I did not know my own drive utilization for a long, long time. Caution: Before you start deleting things. ...