Forem: Ana Liza Pandac

Learning TypeScript with React - Part 2 (The what, why and how of interfaces)

Ana Liza Pandac — Sat, 06 Jul 2019 13:19:50 +0000

⚡TL;DR: Understanding what are interfaces, why use them and how to use them can help you in writing more reusable code and creating awesome applications.

In the previous article, we talked about types, what is it, how to use them and why use them. If you haven't read it yet, I recommend that you read it first.

In this post, we'll get to know what is an interface, why should you care about it, and how to use it to write more reusable code.

Let's begin.

What is an interface?

Interfaces are the core way in TypeScript to compose multiple type annotations into a single named annotation.

It’s a way of creating a new type that describes an object’s property names and their types. Remember the types that we covered before (number, boolean, string, etc.)? An interface is the same as those types.

Why should you care about interfaces?

For me, interfaces are one of the best features of the TypeScript language. Let me show you just how awesome it is.

Let's start with the following example.

You have a function called renderVideo which accepts video as a parameter in which you annotated with all the properties that should be present in a video object.

const video = {
  videoId: '',
  title: '',
  description: '',
  thumbnailURL: ''
};

const renderVideo = (video: { videoId: string; title: string; description: string; thumbnailURL: string }): void => {

}

Even though the parameter annotation is quite long, the code above is okay, the function parameter and return value was annotated correctly.

However, imagine if you added more functions which accepts a video.

const video = {
  videoId: '',
  title: '',
  description: '',
  thumbnailURL: ''
};

const renderVideo = (video: { videoId: string; title: string; description: string; thumbnailURL: string }): void => {

}

const getVideoSummary = (video: { videoId: string; title: string; description: string; thumbnailURL: string }): void => {

}

// another function has a `video` parameter
// another one
// and another one
// *shouts* "DJ Khaled"

Aaahhhh. I don't know about you but to me, the code above doesn't look good.

There are a lot of long annotations which are duplicated several times. The code is harder to read as well.

Now imagine again (we're imagining a lot here) that you need to do either one or more of the following changes to a video:

add the date it was published as a new property
rename thumbnailURL to imageURL
change the type of videoId from string to a number

Applying these new changes to the code above means you need to change all the video annotations in a lot of places.

That's a lot of work and we don't want that so how can we solve this?

Simple, by using an interface.

How to create an interface?

We can convert this long video annotation into an interface called Video.

To create an interface, use the interface keyword followed by a name that represents the object, in this case Video.

The name should start with a capital letter just like how we create React components and a set of curly braces where you declare all of the object's properties and methods and its types.

This is how you create the Video interface.

interface Video {
  videoId: string;
  title: string;
  description: string;
  thumbnailURL: string;
}

How do you use an interface?

Since an interface is a custom type, we can annotate it to a variable just like a normal type.

let item: Video;

By using the Video interface, we can rewrite the previous example to this:

interface Video {
  videoId: string;
  title: string;
  description: string;
  thumbnailURL: string;
}

const renderVideo = (video: Video): void => {};
const getVideoSummary = (video: Video): void => {};

// another function that uses a video
// another one
// and another one

const video = {
  videoId: "",
  title: "",
  description: "",
  thumbnailURL: ""
};

renderVideo(video);

This code looks wayyyyy better than the previous one right?

It looks cleaner and in one glance, we can see right away that the parameter is a type of Video.

Most of all, we can add, remove or rename a property or change a property type only in one place, the interface declaration. Awesome!

💡 If you use VS code, which I highly recommend you should, you can see all the property names and types of an interface by holding the ctrl/cmd key and hovering over the interface name.

Pretty cool right?

How are interfaces used in the app?

Aside from using the Video interface, I created another interface to represent how the Youtube API response is structured.

interface YoutubeVideo {
  id: { videoId: string };
  snippet: {
    publishedAt: string;
    title: string;
    description: string;
    thumbnails: { medium: { url: string }; default: { url: string } };
    channelTitle: string;
    channelId: string;
  };
}

interface YoutubeAPIResponse {
  data: { items: YoutubeVideo[] };
}

This interface is used in the fetchChannelVideos function.

export const fetchChannelVideos: (
  args: FetchVideosArguments
) => Promise<Video[]> = async ({
  shouldUseDefaultVideos = false,
  searchQuery
}) => {
 const requestURL = '';
 const response:YoutubeAPIResponse = await axios.get(requestURL);
};

Since an interface is a type, it means the TS compiler also does error-checking on the annotated data.

By creating an interface for the API response structure and annotating it to the variable, we made sure that we don't accidentally access a property that does not exist.

So if we try to access comments, which is not included in the API response, the TypeScript compiler will give us an error.

Writing Reusable Code with Interfaces

Now that we covered the what, why and how of interfaces, let's talk about how we can use it to write more reusable code.

Let's say you have a component that renders comments from a Youtube user and the channel.

First we write it like this:

interface User { name: string; avatar: string; }
interface Channel { name: string; avatar: string; }

const renderUserComment: (user: User, comment: string) => React.ReactNode = (
  user,
  comment
) => { /* return user comment */ };

const user = { name: "Ana", avatar: "ana.png" };
const channel = { name: "Tedx Talks", avatar: "tedxtalks.png" };

const renderChannelComment: (
  channel: Channel,
  comment: string
) => React.ReactNode = (channel, comment) => {/* return channel comment */};

renderUserComment(user, 'hello there');
renderChannelComment(channel, 'hi, thanks for watching');

There are two separate interfaces to represent a user and a channel as well as separate functions to render these comments even though they do the same thing, rendering a comment with the author.

How can we rewrite this to remove the duplicated code?

Although we can use a union type to indicate that the comment author can be a User or a Channel,

const renderComment: (author: User|Channel, comment: string) => React.ReactNode = (
  author,
  comment
) => { /* return comment */ };

In this scenario, it's better to create one interface to represent the two types of users.

Let's rewrite it using a more generic interface called Author.

interface Author { name: string; avatar: string; }

const renderComment: (author: Author, comment: string) => React.ReactNode = (
  author,
  comment
) => { /* return comment */};

const user = { name: "Ana", avatar: "ana.png", github: "analizapandac" };
const channel = { name: "Tedx Talks", avatar: "tedxtalks.png", channelId: "UCsT0YIqwnpJCM-mx7-gSA4Q" };

renderComment(user, 'hello there');
renderComment(channel, 'hi, thanks for watching');

Even though user and channel represents two different types of data, they satisfy the requirements to be considered an author which is a name and avatar so the renderComment function works for both objects.

The examples above are very basic but the point here is that we can use a generic interface to represent different objects which can work with different functions. This is one way to use interfaces to write more reusable code.

Closing Thoughts

Aside from learning about the what, why and how of interfaces, I hope that I have also shown you a glimpse of the power of interfaces and how you can use it to create amazing applications.

There's a lot more to interfaces especially on how to use it together with the other TypeScript features such as classes and write even better code.

I'll continue learning the more advanced TS concepts, creating new exciting projects using them and sharing them with you.

I hope you'll do the same 😊

Project Github Repo

Here's the source code of the app: https://github.com/analizapandac/tedflix

You can clone it and play with the source code on your local if you want.

You can see the deployed app at https://tedflix.netlify.com/.

Here's the previous article:

Learning TypeScript with React - Part 1

Ana Liza Pandac ・ Jul 1 '19

#typescript #react #beginners #webdev

Let me know in the comments below if you have any feedback and suggestions or pointers on where to go next. Thank you in advance.

Learning TypeScript with React - Part 1

Ana Liza Pandac — Mon, 01 Jul 2019 18:30:29 +0000

⚡TL;DR: Understanding what are types, type annotations, why use them and how to use them can help you catch errors during development while also enhancing code quality and readability.

Two weeks ago, I decided to pick up TypeScript so I started learning it by creating TEDFlix. Built together with React, it fetches the videos from the official Tedx Talks Youtube channel for you to watch. Why TEDFlix? It sounds fun and honestly, I ran out of ideas 😛

In this two-part series, I wanted to share what I learned from doing this project.

Before diving into it, let me give you a short definition of what is TypeScript (TS) taken from the official TS website.

“TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.”

Now, let me also give you a high level overview of the app’s features and how the React side is structured.

It is a one page app where it has a video player, a list of related talks and a search bar which are all built as separate React components. On page load, it fetches a default list of talks from a JSON file instead of fetching from Youtube to avoid exceeding the daily usage quota of the Youtube API when the page is loaded by many users. The app only communicates with Youtube when searching for talks.

Okay, let's start.

First, the project setup

I generated the project using Create React App with TypeScript

create-react-app my-app-name --typescript

How did I use TypeScript in this app?

Since I’m a TS beginner, I get started by learning the syntax and features of the language first specifically the types, type annotations and interfaces. In this first post, I'm gonna be talking about types and annotations only.

What is a type?

Since TypeScript is a typed language, it means we can specify/annotate the type of the variables, function parameters and object properties.

From my own understanding, a type is a symbol/representation of all the properties and methods that a variable has access to. It means if we added a type of number to a variable, the TS compiler knows that the variable has and can only access all the properties and methods that a number has.

A type is annotated to the variable, parameter or property using this format :type.
For example, let name: string.

There are a lot of available types in TS however, in this app, these are the ones that I've used:

Primitive Types - number, string, boolean
Arrays - by adding [] after the type (e.g. let names: string[])
Video - an interface or a custom type I created to represent a video object's properties

See here for a more comprehensive list of types.

Why do we care about annotating types?

Types are one of the best forms of documentation you can have. This is a very helpful to the next developer who has to read your code which could also be the future you.
It helps the TypeScript compiler help you. If you annotate a variable as a number and a few lines later assigned it a value which is a string, the compiler will give you the following error.

let x: number = 123;
x = '123'; // Error: cannot assign a `string` to a `number`

Even if we remove the :number annotation from variable x, the same error will be given by the compiler because TypeScript is smart*.

*If you declare a variable with a value without specifying the type, TypeScript will figure out the type of the variable based on the initial value assigned to it.

This is called type inference.

"So if type inference is present then why do I have to bother annotating the variables?"

Type inference does not work all the time.

An example scenario is when you delay the initialization of a variable as shown below.

let age;

// a few lines later
age = 12; 
// The compiler will NOT give an error even 
// if we assign a non-numeric value to `age`
age = 'Ana';

If you delay the variable initialization without annotating a type to it, the variable will automatically have a type of any associated with it since the TS compiler does not have any idea what kind of properties age will have later on.

Variables with a type of any should be avoided as much as possible. It defeats the purpose of the idea behind the TS type system where we want to catch as many errors as possible during development. Why? Because, the compiler cannot do error checking on types of any.

Remember, use types to help the TS compiler help you.

How is type annotation used in the app?

Aside from using types on the variable declarations, I also used annotations in the function declarations.

A function can be annotated in the following ways:

1. Arrow function

const add = (a:number, b:number):number => {
 return a + b;
}

// or
const add: (a: number, b: number) => number = (a, b) => {
  return a + b;
};

2. Non-arrow function

function add(a:number, b:number):number {
 return a + b;
}

In both of these examples, the compiler will give an error if the function returns a string or any type that is not a number since it is expecting a number.

For fetching the channel's videos, I created a function called fetchChannelVideos which accepts a boolean flag indicating whether to fetch the default videos from the JSON file and a search query string. Both of these are optional parameters (by adding ? after the property name) which are represented as an interface. I will explain later what an interface is but for now let’s take a closer look on how the function is annotated.

interface FetchVideosArguments {
 shouldUseDefaultVideos?: boolean;
 searchQuery?: string;
}

export const fetchChannelVideos: (
 args: FetchVideosArguments
) => Promise < Video[] > = async ({
 shouldUseDefaultVideos = false,
 searchQuery
}) => {};

On the left side of the assignment operator (=),

const fetchChannelVideos: (args: FetchVideosArguments) => Promise <Video[]>

we are annotating the variable fetchChannelVideos that was declared not the function assigned. We are telling the TS compiler that this variable will have a function assigned to it with these types of arguments and return value.

While the right part of the = is the function assigned.

async ({
 shouldUseDefaultVideos = false,
 searchQuery
}) => {};

To annotate the function itself, we have to specify its arguments and their types and the return value as well.

So why didn't I annotate the function to assigned to fetchChannelVideos? Because again, TypeScript is smart.

Seeing that I assigned the function to a variable that was annotated, it is able to infer that the function will have the same argument names and types and the return value as well, otherwise it will give an error if I add or specify different argument names or return a different value.

*The function arguments and return value is inferred

However, if I’m exporting the function directly without assigning it to a variable then I have to annotate it like below.

export async function fetchChannelVideos({
 shouldUseDefaultVideos = false,
 searchQuery
}: FetchVideosArguments): Promise<Video[]> {
 // function body
}

Okay, now that we have an idea about the what, why and how of type annotations, there's one last question.

Where do we use types?

The answer is: everywhere. By using TypeScript, every data in your application will have a type associated with it whether you like it or not.

Closing Thoughts

I have only touched the basics so far but I’ve already seen how helpful it is, seeing the errors the compiler gives while writing the code instead of discovering them later when running the app saved me a lot of time.

Learning Resources

If you want to learn more and join me on this journey, here are some available resources that can help you get started.

TypeScript in 5 Minutes

TypeScript Deep Dive

Official TypeScript Documentation

I deployed the app in Netlify: https://tedflix.netlify.com/

I will share the Github repo of the project soon.

*Update: 06/07*
Last part about interfaces is up 🎉

Learning TypeScript with React - Part 2 (The what, why and how of interfaces)

Ana Liza Pandac ・ Jul 6 '19

#typescript #react #javascript #webdev

Let me know in the comments below if you have any feedback and suggestions or pointers on where to go next. Thank you in advance.

Cheers!

Using CSS grid, flexbox and multi-columns layout to recreate the Daily Prophet

Ana Liza Pandac — Mon, 17 Sep 2018 08:19:27 +0000

Recently, I posted an article about how I created a copy of Red Onion’s The Daily Prophet using CSS flexbox. And since I started learning CSS grid, I decided to implement it again by using the two layout modules along with the multi-columns layout.

However, before we dive right into it, let me make this clarification first cause I think it’s really important.

The next day after posting my previous article, I stumbled upon a post from Smashing Magazine about flexbox and I realized there’s one important aspect of the flex-direction that I completely misunderstood. I thought the rows will always start from left to right. And guess what, not always.

The rows and columns are displayed depending on the writing mode that you’re working with, not the physical dimensions of the screen.

So if you’re working with English, it uses the default writing mode which is horizontal-tb which means content flows horizontally from left to right, vertically from top to bottom. The next horizontal line is positioned below the previous line.

However if you’re working with other languages that uses a different writing mode like Hebrew and Arabic which are written right to left then your flex items would start at the right. Or if the writing mode is top-to-bottom, then your row items would be displayed like a column.

Okay now that’s done, let’s start.

Since I've mostly talked about flexbox before, let's take a closer look on the usage of the grid layout.

Using the grid layout and flexbox together

How do I decide when to use grid or flexbox? Actually, it's simple.

I make use of CSS grid when dealing with two-dimensional sections (both row and column, for example the main stories section).

Flexbox for simple one-dimensional sections (only row OR column, like the publication name section) and for the alignment of text and elements.

Dividing columns

To specify the number (and the widths) of columns in a grid container, you have to use the grid-template-columns property.

Let’s take a look at the main story section.

As you can see, the story’s left content takes three-fourth (3/4) of the section while the right part takes one-fourth (1/4) of it.

At first I declared grid-template-columns with a value of 1fr 250px but when I made the screen smaller, the left part’s content gets squished. The reason is that the right part will always take 250px of the grid parent while the left part will take the remaining available space since I declared it with a fr value (fraction of the free space).

So I modified it to this:

<div class="story--main">
  <div class="section--left">
  </div>
  <div class="section--right">
    </div>
</div>

.story--main {
  display: grid;
  grid-template-columns: 3fr 1fr;
}

.story--main .section--left {}
.story--main .section--right {}

3fr 1fr means the left part will always take three-fourth of the available space and one-fourth will be given to the right part. This also means that whenever you resize the viewport, the columns will automatically adjust their widths depending on the size of the grid parent.

Making the page responsive

The previous flexbox exercise that I made is not responsive but this time, I took care of the responsiveness by using media queries and manipulating the value of grid-template-columns on specific viewport sizes.

.parent {
        display: grid;
        grid-template-columns: repeat(2, 1fr);
        gap: 10px;

        @media (min-width: 768px) {
          & {
            grid-template-columns: repeat(6, 1fr);
          }
        }
}

In the example above, on iPad and desktop view, the columns would be displayed in this manner.

While on mobile, since I specified it as repeat(2, 1fr), it would be displayed like this.

repeat()

Instead of writing grid-template-columns: 1fr 1fr 1fr 1fr 1fr 1fr; which is very repetitive, you can use the repeat() function so repeat(6, 1fr) will repeat the specified width 6 times thus producing the same result.

I’ve also used repeat(auto-fill, minmax(min, max)) in some of the sections for automatically calculating the number of repetitions.

Actually, I’m confused about what is the difference between auto-fill and auto-fit. If anyone knows, please let me know.:D

Using multi-columns layout for sections that only contains text

For some sections that only contains text separated by columns, instead of using grid or flexbox I decided to use another existing layout module called multi-columns layout to produce the same effect.

<div class="paragraphs_wrapper">
 <p>Veteran Captain Oliver Wood did not seem too anxious about the hurricane threat.</p>
 <p>Ducimus qui blanditiis praesentium voluptatum delenit.</p>
 <p>Harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio.</p>
</div>

.paragraphs_wrapper {
  column-count: 2;
}

.paragrahps_wrapper {
  p {
    // to ensure that the paragraph will not be broken into two columns
    page-break-inside: avoid;
    break-inside: avoid;
  }
}

Which produces this result.

Conclusion

Using all of these layout modules together helped me understand what kind of scenarios they are most useful of and how to utilize each of its strength to make even better pages. I'm so excited to the possibilities.

Thanks for reading and you can check the page @CodePen.

Have any feedback/comments, please let me know.

*The Daily Prophet copyrights reserved to Red Onion.

I created a copy of Red Onion's Daily Prophet using CSS Flexbox

Ana Liza Pandac — Sat, 15 Sep 2018 10:53:14 +0000

If you have ever seen Red Onion’s Daily Prophet page then you’d know that it's a really awesome and creative layout which is built using CSS Grid. It’s similar to an old-style print layout which seems quite challenging to replicate on the web. Creating a clone of it using flexbox instead of css grid would be a really good challenge if you want to learn how to use the flexbox layout. (I guess that’s what my senior also thought when he sent me the link.)

Although flexbox and css grid have been around for awhile now, I haven’t really used them that much since I mostly relied on the existing css frameworks most of the time (I know).

So I decided to this exercise to find out if it's really complicated as it seems and here's what I've learned.

Seeing in boxes

The page layout seems very complicated when you first look at it but what I found is that it’s easier if I start looking at each section as a box. This is what the page looks like in boxes.

Inline and blocked elements

Some of the boxes are displayed inline to each other while others are displayed in blocks. By default when a flexed parent box has several children, those children are displayed beside each other in a row.

In order to display each child in it’s own block, you can use the flex-direction property as column.

Wrapping overlapping elements

One of the most important thing to also consider is how the page will look like in smaller devices (or the page responsiveness). By default when using flexbox,items will not be wrapped into a new line. So as the screen gets smaller, some of the content will not be visible. In order to fit them to the new viewport size, you have to declare the flex-wrap property as wrap.

.parent {
    display: flex;
    flex-wrap: wrap;
    flex-direction: row;

    .child {}
}

Centering things inside an element

If I need to vertically and horizontally center a text inside the element, in the past, I would’ve use positioning on the parent and child element.

But with flexbox, you can use justify-content and align-items for this exact behaviour.

<div class="exclusive-story__marker">exclusive</div>

.exclusive-story__marker {
    display: flex;
    align-items: center;
    justify-content: center;
}

Additional learnings

Use substitute fonts when the original font is not available

The original page is using Headline One HPLHS for the story headlines but I can’t find the exact font on Google fonts so I decided to use serif instead since it looks appropriate for newspaper headlines as well. It would be nice to have the exact same font but it’s not necessary at the moment. My goal is to learn how to use flexbox not making a pixel perfect replica of a page.

Avoid using height on divs to prevent overlapping content on smaller screens

Seeing the page sections in terms of boxes is a very helpful approach but it also made me think in heights. Yes, heights. I started assigning heights to the boxes that seems to have a very specific height like the publication name section and the exclusive story section.

But when I decreased the size of the viewport, the text and images inside it overlaps the flex container so I decided to remove those height declarations.

Lastly...

Using object-fit:cover to crop an image and display the center
Using the first-letter pseudo-code to make the first letter of the paragraph bigger than the rest of the sentence just like how it behaves in a newspaper.

Overall, I really liked doing this exercise. I gained more understanding on how flexbox works. There’s still a whole lot of flex properties I haven’t used like flex-basis, order, flex-shrink but for now this is okay, I can learn them as I go on.

Thanks for reading and you can check the cloned page @CodePen.

Have feedback/comments, please let me know.

*Daily Prophet's copyright reserved to Red Onion.

P.S. This wouldn't be possible without the encouragement of my senior/mentor Dinesh Pandiyan @flexdinesh. Thank you po.