DEV Community: Nicholas Costa

Working with forms in SvelteKit coming from React

Nicholas Costa — Tue, 17 Oct 2023 02:10:33 +0000

Every application nowadays will run into the need of handling forms. In this article, we will take a look at how to handle forms in SvelteKit coming from React. We will look at how to handle form state, both validation and submission, and also loading states. For the React examples, I'll be using React with Next.js prior to v13, meaning I'm not going to be using app directory.

I know there are many differences when using Next.js v13 but for the time being, since many applications are built and are still being built using pages directory, I'll be using that for the examples.

NOTE: It's important that you follow the post sequentially, the code will start small and will grow with each functionality we add.

Form Submissions

In React, you're probably used to doing something like this to handle form submissions:

function FormSubmission() {
    function handleSubmit(e: FormEvent) {
        e.preventDefault()
        // do your fetch calls to an api endpoint
    }

    return (
        <form onSubmit={handleSubmit}>
            {/* ... */}
        </form>
    )
}

In SvelteKit on the other hand, you can use a +page.server.ts with a +page.svelte to handle form submissions without needing javascript on the client-side, doing something like this:

// +page.server.ts
export const actions = {
    login: async ({ request }) => {
        // get the input data from the FormData
        const { ... } = Object.fromEntries(await request.formData())
    }
}

<!-- +page.svelte -->
<form action="?/login" method="post">
    <!-- ... -->
</form>

This way, the form submission will go to the route you specified in the "action" attribute. It is important to use method="post" since other methods are not able to reach to form actions in SvelteKit.

You can take a more in depth look at SvelteKit's form actions documentation.

Now lets dive in

Lets get to an actual example using a form with inputs for a login functionality in React vs Svelte.

React

One way to do so with React if you're using a meta framework like Next.js is:

// /pages/api/login
export function handler(req: NextApiRequest) {
    const { username, password } = req.body
    // ...
}

function FormSubmission() {
    const [username, setUsername] = useState("")
    const [password, setPassword] = useState("")

    async function handleSubmit(e: FormEvent) {
        e.preventDefault()
        try {
            const res = await fetch("/api/login", {
                method: "POST",
                body: JSON.stringify({
                    username,
                    password
                })
            })

            if(!res.ok) throw new Error(...)
        } catch(err) {
            // ...
        }
    }

    return (
        <form onSubmit={handleSubmit}>
            <input type="text" value={username} onChange={(e) => setUsername(e.target.value)} />
            <input type="password" value={password} onChange={(e) => setPassword(e.target.value)} />
        </form>
    )
}

And that's it, we save the input values as state, send to the route handler and pick those values from req.body.

SvelteKit

In SvelteKit, you don't have to handle the input state if you don't want to, you can just use form actions and get the input values by their name.

export const actions = {
    default: async ({ request }) => {
        const { username, password } = Object.fromEntries(await request.formData()) as {
            username: string;
            password: string;
        };

        // ... do something with username and password
    }
};

<!-- +page.svelte -->
<form action="?/login" method="post">
    <input type="text" name="username" />
    <input type="password" name="password" />
</form>

I may be biased, but it's pretty cool we can do something like this in so less lines of code.

Validations

Of course it wouldn't be a great comparison without showing how validations would work in both cases, since every form you use nowadays will probably need some kind of validation.

There are libraries for handling form submissions with builtin integrations for validations libraries, like react-hook-form with @hookform/resolvers for React, and we have superforms for SvelteKit, that handles validation with zod, they both are made for the same purpose.

For the examples, I'll be using zod for both React and Svelte, but won't be using libraries for the sake of showing the differences. You should be able to use any other validation libraries you want with no problem, but since I'm more familiar with zod, that's what I'm goin to be using. It's good to know that I'll only handle validations on the server-side, that's why it's useless for us to save some variables state in Svelte.

As we're going to be using validation libraries, it's important that you render the errors that happen to let the user know what happened.

React

// /pages/api/login
const LoginSchema = z.object({
  username: z.string().min(3).max(10),
  password: z.string().min(10).max(100),
})

export function handler(req: NextApiRequest) {
    const result = LoginSchema.safeParse(req.body)

    if(!result.success) {
        return res.status(400).json({ error: result.error.format() })
    }

    const { username, password } = result.data

  // do something with username and password
}

function FormSubmission() {
    const [username, setUsername] = useState("")
    const [password, setPassword] = useState("")
    const [error, setError] = useState<{
        username: string | null
        password: string | null
    }>({
        username: null,
        password: null
    })

    async function handleSubmit(e: FormEvent) {
        e.preventDefault()
        try {
            const res = await fetch("/api/login", {
                method: "POST",
                body: JSON.stringify({
                    username,
                    password
                })
            })

            // 400 status code are not considered errors in fetch API
            if(!res.ok) {
                const data = await res.json()

                setError({
                    username: (data?.username && data?.username._errors.length >= 1) ? data?.username._errors[0] : null,
                    password: (data?.password && data?.password._errors.length >= 1) ? data?.password._errors[0] : null
                }),
            }
        } catch(err) {
            // ...
        }
    }

    return (
        <form onSubmit={handleSubmit}>
            <input type="text" value={username} onChange={(e) => setUsername(e.target.value)} />
            {error.username && <small>{error.username}</small>}
            <input type="password" value={password} onChange={(e) => setPassword(e.target.value)} />
            {error.password && <small>{error.password}</small>}
        </form>
    )
}

What we can see as a pattern here is that we have to store the username and password in states and also save the error as a state for showing it in the UI. In SvelteKit, it works very differently, lets see.

// +page.server.ts
const LoginSchema = z.object({
    username: z.string().min(3).max(10),
    password: z.string().min(10).max(100)
});

export const actions = {
    login: async ({ request }) => {
        const result = LoginSchema.safeParse(Object.fromEntries(await request.formData()));

        if (!result.success) {
            return {
                status: 400,
                error: result.error.format()
            };
        }

        const { username, password } = result.data;

        // do something with username and password
    }
};

<!-- +page.svelte -->
<script>
    export let form;
</script>

<form action="?/login" method="post">
    <input type="text" name="username" />
    {#if form?.error?.username && form.error.username._errors.length >= 1}
        <small>{form.error.username._errors[0]}</small>
    {/if}
    <input type="password" name="password" />
    {#if form?.error?.password && form.error.password._errors.length >= 1}
        <small>{form.error.password._errors[0]}</small>
    {/if}
</form>

With builtin form actions return from export let form, we can take the validation errors and show directly on the UI, without having to save internal state.

If we want to have SPA like feeling, we can even use enhance coming from "$app/forms" to progressively enhance the form, and the page will not be refreshed like an MPA when javascript is enabled.

<!-- +page.svelte -->
<script>
    import { enhance } from '$app/forms';

    export let form;
</script>

<form action="?/login" method="post" use:enhance>
    <input type="text" name="username" />
    {#if form?.error?.username && form.error.username._errors.length >= 1}
        <small>{form.error.username._errors[0]}</small>
    {/if}
    <input type="password" name="password" />
    {#if form?.error?.password && form.error.password._errors.length >= 1}
        <small>{form.error.password._errors[0]}</small>
    {/if}
</form>

With that, we learned how to create and handle form submissions, and also learned how to validate forms using a schema validator library like zod, but what if our request to the server takes some time? How would we show this to our user?

Loading states

It's extremely important to show to our user that we're not just hanging the window whenever he submits it, it's important to show in the UI that something is happening, so let's see how we would do so in React vs SvelteKit. For that, we will also add a button for submitting the form.

If you want to simulate a slow response time, you can use this util function, easy and simple, you just have to await on the call, like await wait(ms) and it will work.

function wait(ms: number) {
    return new Promise((resolve) => setTimeout(resolve, ms));
}

React

In React, we would need to add a new state and set it to the fetching state whenever it starts and whenever it ends, and based on that state, we can do whatever we want with our UI.

function FormSubmission() {
    const [username, setUsername] = useState("")
    const [password, setPassword] = useState("")
    const [error, setError] = useState<{
        username: string | null
        password: string | null
    }>({
        username: null,
        password: null
    })
    const [isLoading, setIsLoading] = useState(false)

    async function handleSubmit(e: FormEvent) {
        e.preventDefault()
        try {
            setIsLoading(true)
            const res = await fetch("/api/login", {
                method: "POST",
                body: JSON.stringify({
                    username,
                    password
                })
            })

            // 400 status code are not considered errors in fetch API
            if(!res.ok) {
                const data = await res.json()

                setError({
                    username: (data?.username && data?.username._errors.length >= 1) ? data?.username._errors[0] : null,
                    password: (data?.password && data?.password._errors.length >= 1) ? data?.password._errors[0] : null
                }),
            }
        } catch(err) {
            // ...
        } finally {
            setIsLoading(false)
        }
    }

    return (
        <form onSubmit={handleSubmit}>
            <input type="text" value={username} onChange={(e) => setUsername(e.target.value)} />
            {error.username && <small>{error.username}</small>}
            <input type="password" value={password} onChange={(e) => setPassword(e.target.value)} />
            {error.password && <small>{error.password}</small>}
            <button>
                {isLoading ? "Loading..." : "Submit"}
            </button>
        </form>
    )
}

Svelte

For SvelteKit, it isn't much different, we only have to handle the same loading variable changes but in a bit easier way when you get used to it.

We first will need to create a SubmitFunction for us to pass as a parameter to use:enhance, and inside there, we would change the loading states. Also, with Svelte's syntax, we don't have to create states with setters, states are just variables that you can assign and reference.

<!-- +page.svelte -->
<script lang="ts">
    import { enhance } from '$app/forms';
    import type { SubmitFunction } from '@sveltejs/kit';

    export let form;

    let loading = false;

    const handleSubmit: SubmitFunction = () => {
        loading = true;

        return async ({ update }) => {
            loading = false;
            await update();
        };
    };
</script>

<form action="?/login" method="post" use:enhance={handleSubmit}>
    <input type="text" name="username" />
    {#if form?.error?.username && form.error.username._errors.length >= 1}
        <p>{form.error.username._errors[0]}</p>
    {/if}
    <input type="password" name="password" />
    {#if form?.error?.password && form.error.password._errors.length >= 1}
        <p>{form.error.password._errors[0]}</p>
    {/if}

    <button>
        {#if loading}
            Loading...
        {:else}
            Submit
        {/if}
    </button>
</form>

Final comparison

Now let's compare the final result of both frameworks(or library, as React likes to say it is one).

React

// /pages/api/login
const LoginSchema = z.object({
  username: z.string().min(3).max(10),
  password: z.string().min(10).max(100),
})

export function handler(req: NextApiRequest) {
    const result = LoginSchema.safeParse(req.body)

    if(!result.success) {
        return res.status(400).json({ error: result.error.format() })
    }

    const { username, password } = result.data

    // do something with username and password
}

function FormSubmission() {
    const [username, setUsername] = useState("")
    const [password, setPassword] = useState("")
    const [error, setError] = useState<{
        username: string | null
        password: string | null
    }>({
        username: null,
        password: null
    })
    const [isLoading, setIsLoading] = useState(false)

    async function handleSubmit(e: FormEvent) {
        e.preventDefault()
        try {
            setIsLoading(true)
            const res = await fetch("/api/login", {
                method: "POST",
                body: JSON.stringify({
                    username,
                    password
                })
            })

            // 400 status code are not considered errors in fetch API
            if(!res.ok) {
                const data = await res.json()

                setError({
                    username: (data?.username && data?.username._errors.length >= 1) ? data?.username._errors[0] : null,
                    password: (data?.password && data?.password._errors.length >= 1) ? data?.password._errors[0] : null
                })
            }
        } catch(err) {
            // ...
        } finally {
            setIsLoading(false)
        }
    }

    return (
        <form onSubmit={handleSubmit}>
            <input type="text" value={username} onChange={(e) => setUsername(e.target.value)} />
            {error.username && <small>{error.username}</small>}
            <input type="password" value={password} onChange={(e) => setPassword(e.target.value)} />
            {error.password && <small>{error.password}</small>}
            <button>
                {isLoading ? "Loading..." : "Submit"}
            </button>
        </form>
    )
}

Svelte

// +page.server.ts
const LoginSchema = z.object({
    username: z.string().min(3).max(10),
    password: z.string().min(10).max(100)
});

export const actions = {
    login: async ({ request }) => {
        const result = LoginSchema.safeParse(Object.fromEntries(await request.formData()));

        if (!result.success) {
            return {
                status: 400,
                error: result.error.format()
            };
        }

        const { username, password } = result.data;

        // do something with username and password
    }
};

<!-- +page.svelte -->
<script lang="ts">
    import { enhance } from '$app/forms';
    import type { SubmitFunction } from '@sveltejs/kit';

    export let form;

    let loading = false;

    const handleSubmit: SubmitFunction = () => {
        loading = true;

        return async ({ update }) => {
            loading = false;
            await update();
        };
    };
</script>

<form action="?/login" method="post" use:enhance={handleSubmit}>
    <input type="text" name="username" />
    {#if form?.error?.username && form.error.username._errors.length >= 1}
        <p>{form.error.username._errors[0]}</p>
    {/if}
    <input type="password" name="password" />
    {#if form?.error?.password && form.error.password._errors.length >= 1}
        <p>{form.error.password._errors[0]}</p>
    {/if}

    <button>
        {#if loading}
            Loading...
        {:else}
            Submit
        {/if}
    </button>
</form>

Lines count

Of course lines does not show the complexity and nor show which one is better, but I guess for the record, it's great to see that Svelte has still less lines than React even when counting the line breaks of #if statements. So here is the final result without counting blank lines and comments.

React - 56
Svelte - 44

Wrapping up

And that's it, we wrapped up form submission, validation, errors, and loading states, hope you've learned something new or read something interesting today, see you on the next one!

>>learn svelte and learn web dev<<

How Svelte made me understand Web development better in general

Nicholas Costa — Fri, 13 Oct 2023 21:52:53 +0000

In this article I'm going to be talking a lot about Sveltekit when saying "svelte", since it's the way Svelte team advises building web apps with Svelte and it's the way that I now build my apps with it.
I also wanted to say that this post is about my experience, and I'm not going to talk only about Svelte specific things that I think made me a better developer, but things I learned during the process of learning svelte.

I wanted to share this with everyone that might be wondering if Svelte is the right choice for learning web, and I couldn't say anything less than yes by my experience. Of course I was and still am at the start of my career and I'm constantly learning new things but I guess it accelerated some knowledge that I didn't think I would catch that quick, only because on other frameworks, it wasn't needed.

Progressive Enhancement

For those who don't know, this is the wikipedia definition:

Progressive enhancement is a strategy in web design that puts emphasis on web content first, allowing everyone to access the basic content and functionality of a web page, whilst users with additional browser features or faster Internet access receive the enhanced version instead.

This is one thing that I didn't even think before learning Svelte, and I heard about that while learning through the learn.svelte.dev and other tutorials of Svelte, props to Joy of Code , Huntabyte and Svelte Society for always sharing valuable content that made me think about things I never thought before.

Before Svelte, I only worked with React, mainly using Nextjs(No app dir back then), and I never thought about making things work without javascript, and that thought suddenly got into my mind when I was exposed to form actions in Sveltekit. Sveltekit is thought of working without javascript, working always with server-side rendered pages, working with form actions(meaning no need for javascript to make your forms work as expected), fetching data with redirects instead of client-side fetch(this is relative, but in many cases you may not need client-side fetch). Almost anything can be done without client-side fetching.

Learn Javascript, not React

I'll probably still use React on some next projects, but even though I still find React pretty good, I can't say I prefer writing "Reacty" way of code instead of just javascript. React may only be javascript, but if you've worked with it, you know there are some caveats, making libraries not ported to React work in React, is hard, and at the end you are not learning javascript, you're React way of working with javascript.

With Svelte, you don't have to think about what you have to do to make your code work in Svelte, even though you can change things to use Svelte actions, you don't have to. Everything that works in javascript, works in Svelte out of the box, no overhead of converting packages.

Accessibility

That's not actually a Svelte specific topic, but more a Svelte community one, but either way, I wanted to share this one. The Svelte community is quite amazing, one of the most awesome things I see in it is the "This Week In Svelte" that the Svelte Society has every Friday by sharing new updates of Svelte, new packages made with svelte or made for Svelte, and not only Svelte specific topics, but also web related content in general.

There has been one episode that really changed my vision on accessibility(they have many episodes that tackle some parts of accessibility), that he was using voiceover to walk through the wikipedia page of Svelte and was showing how people using screen readers might navigate through your application, and even though I already knew people would use screen readers, before that, I didn't take time to understand how it worked, and nor used it on my day-to-day, and after that, I cannot build components without thinking about accessibility. Now every component that I build I run voiceover and check if there's anything that could be better, I'm not saying this should be top priority every time but I guess that if you can take some time to improve the accessibility of your websites, you should, it will be good for you, being able to reach more people than before, and of course, for people that now will be able to use your website.

Saving more state on URL than variables when applicable

Since Sveltekit encourages you to use your page handlers to fetch data instead of client-side, I ended up coming with more solutions that worked without javascript, sometimes using forms for redirecting to the page with the correct parameters or even with javascript, but saving the state on the URL enables you to save "sessions" for a user to share with someone.

I have to say that it's again not a specific thing that Sveltekit introduced, but a thing the environment encourages, and because I didn't feel the need for doing so and nor had the incentive to do so when using Nextjs, I did not learn those things the way I should.

By saying "I didn't feel the need for doing so" I mean that all tutorials I've watched and blog posts that talked about mutations and submitting forms, always were using something like this in React:

function ExampleForm() {
    function handleSubmit(e: FormEvent) {
        e.preventDefault()
        // ...
    }

    return (
        <form onSubmit={handleSubmit}>
            {/* ... */}
        </form>
    )
}

Doing something like this, is relying on the user having javascript enabled, why not teaching people to handle forms as they're natively built and handle form inputs as they were thought, by using native formData()?

I guess it is fair to say that almost all people will be using javascript nowadays, but having javascript enabled is not the only condition for the javascript to run, the user still has to download it. Maybe the user is with bad internet connection, working with forms and redirects will make everything work without having to download that extra bit of javascript.

Conclusion

I guess that's all I wanted to share, learning svelte made me learn more about web development and I'm grateful for it, If you didn't give svelte a chance yet, take a shot, you might love it ❤️.

How to integrate your blog with dev.to API Next.js 13

Nicholas Costa — Thu, 16 Feb 2023 22:12:47 +0000

If you're reading this at dev.to, you can also take a look at my own website at nicholascosta.dev/blog

Little recap of the situation I was on

I've been refactoring my portfolio website from the start these days and took a chance to make my blog better(both in styling and how it worked). If you want to take a look, it's public at github, but keep in mind it's still in progress.

I used to save my blog posts in a folder containing the markdown files(that may be what you're used to), but I wanted to post both on dev.to and my blog, then, a friend of mine gave me an idea

"Why don't you use dev.to's API to get all the posts?"

At this point I didn't even know dev.to had an open API, so after that, I couldn't agree more, then I started the journey.

Technologies I chose to build my blog

I'm using Next.js(version 13 with the experimental app dir), and for rendering markdown on React I'm going to use react-markdown.

Integrating an existing Markdown-rendered app

If you already have built your blog and it's already capable of rendering markdown as HTML, 90% of your work is done, all that's left is integrating with the API.

The dev.to API is hosted at https://dev.to/api/ and you can get your posts by reaching out to https://dev.to/api/articles/latest?username={your_username}. This request will return at max 30 posts and will be ordered by descending published dates, you can take a look at their own documentation

Rendering your Posts

With the data you get from the API, you can render your posts the way you want, using cards, lists, literally anything, that's up to you.

But let's go to the interesting part, rendering the actual single post.

Post

You can search for the specific post by its slug using your username at this endpoint: https://dev.to/api/articles/${your_username}/{article_slug}.

For rendering the actual post, we first need to make the request, to keep it simple, I'll be using the native fetch API from the browser.

// utils.ts

type Post = {
  title: string
  description: string
  published_at: string
  slug: string
  id: number
  user: {
    name: string
    profile_image: string
  }
}

interface SinglePostResponse extends Post {
  body_markdown: string
  status?: number
}

// Get post by slug
export const fetchPost = async (postSlug: string) => {
  const response = await fetch(
    `${process.env.DEVTO_URL}/nicholascostadev/${postSlug}`,
  )
  const post = await response.json()
  return post as SinglePostResponse
}

// Get all posts
export const fetchPosts = async () => {
  const response = await fetch(
    `${process.env.DEVTO_URL}/latest?username=nicholascostadev`,
  )
  const posts = await response.json()
  return posts as Post[]
}

Now an actual example with Next.js 13. I'm using the async component feature(a feature that's still under development at the React Team), if you're not familiar with it, it's basically used as replacement for getStaticProps and getServerSideProps and you can take a look at Next.js docs for it.

Now let's get into coding

OBS 1:The process.env.DEVTO_URL maps to "https://dev.to/api/articles".

On this function, we Have the page component, which I named BlogPost, in Next.js 13 we can access the page params via props, but unfortunately it can't infer it yet, so we have to type it manually.

type BlogPostProps = {
  params: {
    slug: string
  }
}

export default async function BlogPost({ params }: BlogPostProps) {
 ...
}

Now we need to make the request, on this example I'm searching for both the single post and for all other posts available, so I can show some recommendations at the end of the post page.

const [post, allPosts] = await Promise.all([
  fetchPost(params.slug),
  fetchPosts(),
])

I'm using Promise.all for making both requests at the same time.

Also, if you send a non-existing ID to the API, it will return something like this:

{
  "error": "not found",
  "status": 404
}

Because of that, before rendering the post, I'm also checking if there is a status on the post response and if it's 404(not found), I throw an error and redirect user to page not-found.tsx.

if (post.status && post.status === 404) {
  throw new Error('post not found')
}

Because I'm using Next.js 13 with the new app directory, I can create a not-found.tsx file and render the page when calling the function notFound() imported from next/navigation.

try {
  ...
  if (post.status && post.status === 404) {
    throw new Error('post not found')
  }
} catch (err) {
  notFound()
}

Now for the final part, the actual post.

All you have to do is use the react-markdown I specified earlier, with that, you can use its component simply as so

<ReactMarkdown>
  {post.body_markdown}
</ReactMarkdown>

That's all to render the post as HTML, there are lots of things you can do to customize the results, you can check the remark plugins and rehype plugins to pass as props to <ReactMarkdown /> and you can also take a look at some other bloggers if you're looking for different styles for example Lee Robinson's or if you liked mine.

Full Code

import { notFound } from 'next/navigation'

type BlogPostProps = {
  params: {
    slug: string
  }
}

export default async function BlogPost({ params }: BlogPostProps) {
  try {
    const [post, allPosts] = await Promise.all([
      fetchPost(params.slug),
      fetchPosts(),
    ])

    if (post.status && post.status === 404) {
      throw new Error('post not found')
    }

    return (
      <ReactMarkdown>
        {post.body_markdown}
      </ReactMarkdown>
    )
  } catch (err) {
    notFound()
  }
}

Hope you liked the post, it's been a while since I last been here and I don't think I'll be that active, who knows?

Thanks for reading, I hope it helped you in some way ❤️

Scrimba's Intruductory Course to TypeScript

Nicholas Costa — Mon, 14 Feb 2022 18:30:17 +0000

PS: All I talked about here and the points I gave are from the Scrimba's free TypeScript Introductory Course taught by Ania Kubów, this article is meant to give a quick explanation of the types of TypeScript and a quick review of the course. If you find any mistakes, feel free to correct me, it's my first time with TypeScript, I don't expect to be 100% correct on all my explanations.

Scheme of the course

The course works with a video playing in the background, as well as the actual live code, so you can stop the recording whenever you want, run the code for yourself, make your changes to see the outputs if you want to, and also take your notes. From my experience with a udemy web development course, this kind of way of teaching was better for me. If you're a developer like me that doesn't have two monitors, it won't be a problem for you since you don't have to change between tabs, it actually saves a lot of time.

What should I know before taking this course?

Intermediate knowledge in JavaScript and basic knowledge in HTML and CSS are great skills to have before starting, but if you're really interested in it and don't want to wait, this course is well planned to take you on an easy pace too.

Why TypeScript?

Types are useful for not having unnecessary mistakes when using for example a function, or passing a string to an integer, and so on. Errors are also more visible since you almost always declare the types allowed.

The first actual lesson is to show you the types and the "typeof" function from JavaScript and shows in a real simple code scenario what problems you could come to by not using TypeScript or defining the types using native JavaScript, the example given was a simple function

function addNumbers(a, b) {
  return a + b
}

But this function also accepts string-type values, which would go wrong since its expected result is for numbers and not for concatenating strings.

1st Section(Learn primitive types)

Comparison of Types with JavaScript and TypeScript:
JavaScript has those 5 main types

number
string
boolean
null
undefined

TypeScript, on the other hand, has its own types and all the native JavaScript types, for example:

tuple
enum
any
union
literal
function
unknown
never
custom types

Just by seeing that, we can assure TypeScript came to make our life as programmers, easier in terms of debugging and it's worth it giving it a go.

Some benefits of using TypeScript

Many errors that you might come through using JavaScript and you don't know the reason, might be easily addressed if you're using TypeScript, because of type definitions.
Type definitions do a kind of checking of the data received, and because of that, some times that you would get your function broken for receiving a unexpected input, you won't anymore.
Assigning variables with no value yet is a lot safer with TypeScript, since you can assign it an expected type before it has an initial value, like: let count : number, count has no initial value but only accepts numbers.

2nd Section(Learn structural types)

PS: I'm not going to talk about all types, but I'm gonna do a quick explanation of the main ones.

TypeScript's types:

objects:

They're slightly different from JavaScript.
A normal JavaScript object is written like so:

const you = {
   userName: 'Bobby',
   isReturning: true,
}

But TypeScript doesn't understand it, you have to tell TypeScript some things about the object by defining the types each property of the object receives and you can do it that way:

const you: {
   userName: string;
   isReturning: boolean;
// We also separate the object's property types with ";",
// not with "," like in a normal JavaScript object.
} = {
   userName: 'Bobby',
   isReturning: true,
}

And also, you cannot define more variables than the variables you defined:

const you: {
   userName: string;
   isReturning: boolean;
} = {
   userName: 'Bobby',
   isReturning: true,
   age: 18 // Error here
}

TypeScript sees an error because when we specified the type of the object's properties, we are specifying the things we must receive inside the object and the type of them, and age isn't one of the properties we can receive.

Arrays:

The arrays are defined with "[]" after a type, so you have to tell TypeScript the type of the content inside the array.
e.g:

const you: {
    firstName: string;
    lastName: string;
    isReturning: boolean;
    age: number;
    stayedAt: string[]; <----
} = {
    firstName: 'Bobby',
    lastName: 'Brown',
    isReturning: true,
    age: 35,
    stayedAt: ['florida-home', 'oman-flat', 'tokyo-bungalow'] 
}

When we add an array, we define its type, and since the array has only strings, we put "string" + "[]" to say it's an array of strings only.

Union:

The union makes possible to add types, so let's take the last example and make a slight change.

const you: {
    firstName: string;
    lastName: string;
    isReturning: boolean;
    age: number;
    stayedAt: (string | number)[];  <--
} = {
    firstName: 'Bobby',
    lastName: 'Brown',
    isReturning: true,
    age: 35,
    stayedAt: ['florida-home', 'oman-flat', 'tokyo-bungalow', 23] 
}

Now, the array can also accept numbers, by using the "|" with the other type((string | number))

Tuples:

Tuples are an Array-like type, but you have to specify each of the property's types with its correct position.
e.g:

let currentLocation: [string, string, number] = ['London', '11:35', 17]

currentLocation is defined to have a string on the index 0, a string on the index 1, and a number on the index 2.

Enum:

Enum creates a custom type, lets take this object for example:

const ADMIN = 'admin'
const READ_ONLY = 'read-only'

const you = {
    firstName: 'Bobby',
    lastName: 'Brown',
    permissions: ADMIN, 
    isReturning: true,
    age: 35,
    stayedAt: ['florida-home', 'oman-flat', 'tokyo-bungalow']
}

The permissions property is assigned to the variable ADMIN, and it makes it possible for permissions to accept any string, and that's not what we want to, we want to specify the possibilities so that it cannot be broken.

Solution:

enum Permissions {
    ADMIN,
    READ_ONLY
}

const you = {
    firstName: 'Bobby',
    lastName: 'Brown',
    permissions: Permissions.ADMIN, 
    isReturning: true,
    age: 35,
    stayedAt: ['florida-home', 'oman-flat', 'tokyo-bungalow']
}

Now it only accepts Permissions' properties, so it doesn't accept all strings, only the ones defined in the enum.

Any:

Whenever you don't want a particular value to cause type checking errors, you can use this type, but it's not really recommended because you're using TypeScript to narrow the possibilities and reduce errors.

Literal:

You define this type with the exact word "type" + the name of the variable.
e.g:

type Price = 100 | 75 | 50

What you're doing here is that you set the type alias "Price" to only accept numbers that are equal to the given numbers(100, 75, 50) PS: you separate the values with the "|"(union type).

So you have this block of code:

type Price = 100, 75, 50

const products : {
    price: Price
}[] = [
    {
        price: 100 <--
    }
]

This price is accepted because it's one of the values the type alias "Price" defined that was allowed, if the price was another number than 100, 75, 50, it would throw us an error.

Function and Void:

Functions can have different returns, so if you're working as a team or just want to make your code cleaner, you can define what type of return should the function have.

First example:
There is this function, that doesn't have an explicit type set:

function add( firstValue: number, secondValue: number ){
    return firstValue + secondValue
}

TypeScript has the knowledge to detect that the return value should be a number, but you can specify it if wanted, by adding ":" + the type, before the function's body:

function add( firstValue: number, secondValue: number ): number{
    return firstValue + secondValue
}

By defining explicitly, it can make your code a lot more understandable for other people(This is a simple example, but you can think about lots of other different cases).

void

If the function has nothing being returned, the type is declared as "Void".

Interfaces:

This type is useful because if you use many different times the same object structure, you would have to define the types every single time again, but with Interfaces, this effort is solved in a simple way, by just creating a "variable":

Instead of writing

const reviews: {
    // ... The structure of the object
}[] = [
    {
        // ... The values
    }
]

You can create an interface like that and use it

interface Review {
    name: string;
    stars: number;
    date: string;
}


const reviews: Review[] = [
    {
        // ... The values
    }
]

So now, the array of objects "reviews", takes the structure of "Review".

Classes:

Classes in TypeScript are a bit different, you need to specify the type of the variables you're going to assign inside the constructor:

class Car {
     make: string // Assign the type before
     year: number // Assign the type before
     color: string // Assign the type before
     constructor(make: string, year: number, color: string {
         this.make = make <--
         this.year = year <--
         this.color = color <--
     }
 }

Final Review

The entire course, the teaching of Ania Kubów was really great and all the exercises were focused on TypeScript like it was supposed to. And this course really taught me why should I use TypeScript, and that made me want to know more, I would really advise you to take it if you're a complete beginner in TypeScript like me, because it gives you a great kickstart.

I'm going to make more posts on what I'm currently learning and I hope you readers find it interesting, your feedback is always appreciated.

Hope you found this article useful, thanks for reading until the end =D.

Working on my portfolio

Nicholas Costa — Tue, 08 Feb 2022 20:57:22 +0000

Journey

It's been great doing my Portfolio from scratch with Reactjs, I've learned how to use react-router-dom properly, learned more about git, and got to know new technologies like an email sender used in the form area for Contact. It's a simple website yet, only to be able to show my previous projects and a little about me, but I have my ideas for the near future.

Plans

What I have in mind right now is about creating my blog inside this website, like for example nicholascosta.dev/blog or changing my portfolio URL to nicholascosta.dev/portfolio, which is being a difficult decision to make, having your reader's opinion would be very appreciated.

What I'm doing right now

I'm currently working on the blog part of the website(still didn't make up my mind on the URL) and thinking about the color palette of the website because I'm not 100% sure of the current one. I'm waiting for your feedback on my portfolio.

observation: I'm a beginner developer, started programming around 6 months ago, that's the reason for the lack of projects, I'm working right now on implementing the blog feature, but soon I'll focus more on different projects