Forem: ben hultin

Dynamically create an object from another one

ben hultin — Thu, 04 May 2023 21:58:49 +0000

Here we will be discussing how to format one object type into another without duplicating the property names from the original object. Here is an example of what we are starting with:

const en = {
  catLabel: 'cat label',
  birdLabel: 'bird label',
  dogLabel: 'dog label',
  lizardLabel: 'lizard label',
  // more props we dont care about
}

we want to create a new object with it to be used in our app:

const object = {
  cat: { label: en.catLabel },
  bird: { label: en.birdLabel },
  dog: { label: en.dogLabel },
  lizard: { label: en.lizardLabel },,
  // more props we dont care about
}

There is some repetition going on here that we can clean up so we dont repeat ourselves so much. Lets first make a change to our original object:

const obj = {
  labels: {
    cat: 'cat label',
    bird: 'bird label',
    dog: 'dog label',
    lizard: 'lizard label'
  }
  // more props we dont care about
};

Now lets create our new object in a way so we dont expressly call out each label:

const myLabels = Object.keys(obj.labels).reduce(
  (result, current) => ({
    // passing along object from past iterations 
    // and adding them to the next iteration in the loop
    ...result, 

    // current would refer to the 'cat' | 'bird' | 'dog' 
    // these values are obtained from Object.keys()
    [current]: {
      // we get the label value via bracket notation: [`${current}`]
      // same as obj.labels.cat or obj.labels.bird
      label: obj.labels[`${current}`]
    }
  }),
  // due to quirk in .reduce() it will skip first item in loop unless we pass in default object
  {}
);

when we console.log(myLabels) we get the following outout

If you have any questions how this went together, feel free to leave a comment.

Thanks for reading!

Will AI take your job or allow you to work faster?

ben hultin — Thu, 13 Apr 2023 01:24:10 +0000

With the rapid evolution of AI from all different aspects whether its writing blogs, creating images, generating code, etc, what will happen to our jobs?

I have been pondering various questions about this the impact of AI as we all have. I have developed some thoughts about these questions:

Will AI completely replace us?

I would tend to argue no. I am going off this conclusion based on business and competition reasoning.
Companies are always trying to get more done faster with less cost.
AI does get more stuff done faster, but just like employees AI also needs to be told what to do and much more so than humans.
If one employee can generate x amount of product with AI, then 10 employees can generate 10x that amount all using AI.
Being first to market is more important than saving a buck.

What are your thoughts? Do you agree or disagree with my assessment of the new technology?

Level Up TS: Dynamically Extend Interfaces with Generics

ben hultin — Tue, 04 Apr 2023 20:13:21 +0000

With Typescript you can define what kind of interface or type a function should expect to take in as an argument. This allows you gain control over your application as to what your function will take in or reject.

interface Pet {
  name: string;
  weight: number;
  age: number;
}

function myPet(pet: Pet) {
  // do something with pet
}

What if we have more specific types for pets like birds or cats?

interface Pet {
  name: string;
  weight: number;
  age: number;
}

interface Bird extends Pet {
  wingspan: number;
}

interface Cat extends Pet {
  furType: string;
}

function myBird(bird: Bird) {
  // do something with bird
}

function myCat(cat: Cat) {
  // do something with cat
}

What if we want to combine myCat and myBird so there is just one function?

interface Pet {
  name: string;
}

interface Bird extends Pet {
  wingspan: number;
}

interface Cat extends Pet {
  furType: string;
}

// T refers to either Cat or Bird interfaces
function myPet<T extends Pet>(pet: T) {
  // do something with extended pet
  // pet can either be of type Bird or Cat 
}

const cat: Cat = {
  name: 'Snowball 2'
  furType: 'short'
}

const bird: Bird = {
  name: 'Tweety'
  wingspan: 12
}

// both are now accepted objects to pass into the same function
myPet(cat)
myPet(bird)

Here we have learned how to make Generics work for us to implement DRY into our application reducing duplicate code.

Thanks for reading!

TS: Next Level Index Signatures Inside Interfaces and Types

ben hultin — Mon, 27 Mar 2023 23:36:07 +0000

With Typescript we can make our interfaces flexible as to what kind of properties it will accept. Why would this be helpful you may ask, well there are various situations where we need to define the TS compiler to more open to other properties besides the ones defined in the interface. These would include but not limited to:

The interface will have more properties than is reasonable to define.
We intend to access the properties dynamically via bracket notation myObj[value].

So lets take a look how this can be done

interface Pet {
  // allows any property value of type string
  // what if we want more control over possible properties
  [key: string]: string
}

const myPet: Pet = {
  // all valid values
  // what if we have a general rule about our props naming convention?
  foo: 'foo',
  bar: 'bar',
  kbgyb: '??'
}

This approach maybe a bit too flexible and we have a pattern our properties will look

interface Pet {
  // by adding the prefix 'content-' we can lock down part of the props name
  [key: `content-${string}`]: string
}

const myPet: Pet = {
  'content-type': 'foo', // valid property name
  two: 'bar' // invalid property name as it is not prefixed with 'content-'
}

Let us take this another step further and define the different values our interface / type can accept.

type StringProps = 'type' | 'name' | 'breed';
type StringPet { [key in StringProps]: string }

// same as this 
interface StringPet {
  type: string;
  name: string;
  breed: string;
}

const myPet: Pet = {
  type: 'foo', // valid property name
  two: 'bar' // invalid property name
}

By making use of StringProps we can reduce the interface from 5 lines of code to 2 also without having to write string 3 times as well. This approach can be expanded even further:

type StringProps = 'type' | 'name' | 'breed' | 'eyeColor';
type StringPet { [key in StringProps]: string }

type IntProps = 'age' | 'weight' | 'legs';
type IntPet { [key in IntProps]: number }

type BoolProps = 'wings' | 'claws' | 'fur';
type BoolPet { [key in BoolProps]: boolean }

// here we intersect two types together into one
// note: types are intersected, not extended like interfaces are
type WholePet = IntPet & StringPet & BoolPet;

// WholePet in the more verbose view looks like this
interface WholePet {
  type: string;
  name: string;
  breed: string;
  eyeColor: string;
  age: number;
  weight: number;
  legs: number;
  wings: boolean;
  claws: boolean;
  fur: boolean;
}

The above approach not only brings control over index signature, but can also be used to make our interfaces and types much more scalable. We are not forced to repeat ourselves with primitive types like string, number, or boolean.

If we want to change the primitive type for one of our properties, we simply move it to appropriate Prop type like from IntProps to StringProps.

Thanks for reading!

TS: 6 Techniques For Combining Interfaces and Types

ben hultin — Mon, 27 Mar 2023 03:55:33 +0000

Typescript offers numerous ways of combing interfaces and types together to create a whole new interface based off of two other ones. That sentenced had two redundant thoughts, should have combined it into a one thought. Maybe this short article will help.

Let's say we have these two interfaces to work with:

interface Parent {
  foo: string;
  bar: string;
  baz: string;
}

interface Uncle {
  foo: string;
  peanuts: string;
  peas: string;
}

We want to combine and re-use them in various ways to create new and interesting interfaces. First something simple.

// Here we extend off of Parent
// Then add carrots property to Sibling
interface Sibling extends Parent {
  carrots: string;
}

In Sibling all Parent properties are required, what if I don't want that?

// we can use Partial<> to define Parent properties as all optional
interface Sibling extends Partial<Parent> {
  carrots: string;
}

What if I only want certain properties from Parent in Sibling?

// will only accept foo and bar from Parent
// foo and bar are required props
interface Sibling extends Pick<Parent, 'foo' | 'bar'> {
  carrots: string;
}

One step further, I want those selected properties from Parent to be optional

// lets combine Partial<> and Pick<> together
// foo and bar are now optional inside of Sibling
interface Sibling extends Partial<Pick<Parent, 'foo' | 'bar'>> {
  carrots: string;
}

Now let's flip all this on its head and do the reverse of Pick<> with Omit<>.

// Omit<> does the oposite of Pick<>
// here we define which props to exclude from the interface/type
// only 'baz' is allowed as a prop
type NewParent = Omit<Parent, 'foo' | 'bar'>;

One more and a little bit different, Extract<> will take the similar properties and a new interface with those

// Extract<> will find the commonalities between types
// Only the props shared between two types will be made into a new type
// only 'foo' is allowed as a prop
type LikeType = Extract<keyof Parent, keyof Uncle>

These are a selection of different built-in tools available in Typescript we can make use of to combine and create new interfaces based off of current ones.

Thanks for reading!

TS: Gain Control of Primitive String Types

ben hultin — Mon, 27 Mar 2023 00:06:55 +0000

Let's say you know what kind of values you expect to receive for a certain property / parameter, you want to lock down that property so it will only accept certain values. There are a number of ways we can do that with Typescript. This can be achieved simply using pipe (|) as in 'cat' | 'dog'.

const PET_TYPES = {
  cat: 'cat',
  dog: 'dog'
}

interface Pet {
  species: 'cat' | 'dog'
}

const myPet: PET = {
  // incompatible types, type string does not match type 'cat' | 'dog'
  species: PET_TYPES.cat, 
  // valid
  species: 'cat'  
}

We want to be able to use PET_TYPES though in our object and interface. Let us make use of 'as const' after PET_TYPES to make the properties 'readonly'.

const PET_TYPES = {
  cat: 'cat',
  dog: 'dog'
} as const

interface Pet {
  species: keyof typeof PET_TYPES;
}

const myPet: PET = {
  // valid
  species: PET_TYPES.cat 
}

There are some other ways we can also defining string values as well.

type PetType = 'cat' | 'dog';

interface Pet {
  species: PetType;
}

const myPet: PET = {
  // this is not valid as we are trying to use PetType like a value, but it is a type
  species: PetType.cat
  // valid
  species: 'cat'
}

By doing these approaches we are give more definition to our string values when we know that a property will be one of only a few different values. When making use of 'as const' on the of our constant objects then we make the properties within all readonly which allows the Typescript compiler to treat 'cat' and 'dog' as well read-only and thus not a type string.

The major benefit of moving the definition of 'cat' and 'dog' value to PET_TYPE is we are now able to make the values for re-use and making changing of the values into one place in our app which is DRY (Don't Repeat Yourself).

Thanks for reading!