DEV Community: Hector Osuna

Vanilla Use Reducer with TypeScript

Hector Osuna — Wed, 16 Jun 2021 20:11:22 +0000

Hi, I was recently doing a project for my portfolio, a React Project with a slightly complex state. Personally, I really love TypeScript and the Redux/Reducer patterns, because they give me a great Developer Experience with TypeScript and a lot of autocompletion available, quite useful in order to not get bit by a bug caused by a typo, and really convenient as I don't have to explore files constantly in order to know what are the properties that a certain object should have.

I always prefer to use TS over vanilla JS, so, it makes a lot of sense to try to make use of strict typing, even in a concept app. Also, while vanilla useReducer might not be what most projects use, I still want to share how I found it to be pretty useful in this context.

The problem

My application is a Social Media-like platform, so a very important part is the use of a user, whose information lives in the global state, that I'm going to access constantly for making requests to the server and other stuff. In order to keep my Client-Side code tidy and predictable, I built a state into a UserReducer which is going to store the user info and make changes, this is then exposed in an almost global context in order to be accessible anywhere in the frontend.

So, my goals in typing the Reducer, are quite simple:

Get better intellisense whenever I need to dispatch an action.
Make quite simple the construction of an Action Creator.
Having appropriate intellisense in the action.payload inside the reducer.

The solution

Typing the state

More often than not, the initial state isn't going to be a great example of how the usual state will look like, so it's pretty important to declare a State Type, in my particular use case, I'm going to propose the following typing:

interface UserState {
    isLogged: boolean;
    userID: string | null;
    username: string | null;
}

I must type userID and username as string or null, as null it's my default state whenever I have no user. However, it's pretty important to type it as string, If I were to not define this interface, useReducer would infer my State type from the following initial state

const initialState = {
    isLogged: false,
    userID: null,
    username: null,
}

// typeof initialState = {
//  isLogged: boolean;
//  userID: never;
//  username: never;
// }

And would make the TS compiler complain whenever I try to set a valid userID as a string.

Typing the actions

The first step in order for this to be successful, is to type adequately all the actions that the reducer might consume. This is pretty important, as using string literals (specifically in action.type) will help the TS to narrow down the needed payload. In the end, it's only a matter of making a union type between the individual interfaces.


interface UserLoginAction {
    type: "LOGIN";
    payload: yourPayload;
}

interface UserLogoutAction {
    type: "LOGOUT";
}

type UserReducerAction = UserLoginAction | UserLogoutAction;

Writing the reducer

The last part of making this cohesive, is to correctly type the reducer function

const userReducer = (
    state = initialState, 
    // initialState must be explicitly typed as UserState, 
    // in order to state be correctly typed
    action: UserReducerAction
): UserState => {
    switch (action.type) {
        // We get nice intellisense in the case statement too, 
        // which shows us an error if we don't type the type correctly
        case "login":
        // Action gets typed as a UserLoginAction type, 
        // which helps us having the appropriate payload
            return {
                ...state,
                isLogged: true,
                userID: action.payload.id,
                username: action.payload.username,
            };
        case "logout":
        // trying to use action.payload will result in an error
            return {
                ...state,
                isLogged: false,
                userID: null,
                username: null,
            };
        default:
            return state;
    }
};

Conclusion

And there it is, now we have a correctly typed useReducer pattern, which can be extended to, maybe creating Action Creators, or whatever you may like.

First Steps on the research of Web Hosting

Hector Osuna — Thu, 10 Jun 2021 22:33:07 +0000

One of the more daunting thing of developing, is to get to know how to deploy, as it's almost guaranteed that you will incur in some kind of cost, so before doing the big jump to trying a VPS (as a service), I decided to make a local Virtual Server to do some testing in setting up server environments.

A what?

Well, to give a little explanation of what I was doing, I need to explain how to web works.

Now and then I have been mentioning about Front-end and Back-end, in some way, you can rename both to Client-Side and Server-Side. The Client is often you, the end-user, whoever visits the web app or webpage, technically the client-side code is executed by the browser and do whatever needs to be done. Typically, it means to fetch, display, and update data.

Think of Facebook, for example, the posts, user info, comments, pages are the data, clients can see it, interact with it, update the info, and all kind of different tasks. This data is stored in wherever Facebook servers are, The Servers are a crucial part in web apps development, as it allows the client to not receive all the data on start, brings authentication and security in place, and allows for interaction between users in an efficient and secure way.

Personally, I have seen a lot the analogy of a restaurant, The customers are clients, that in a way, do something with the resources of the restaurant, but they have to be manipulated (in a no-negative way) before they are consumed by the end users. Ingredients could be understood as the raw data, either from a database, public API, or collected on the go, while these are cooked (prepared) by the chefs (the server), then the waiters deliver whatever gets out of the kitchen to the customers (the client).

Obviously, I think this is a great oversimplification for a lot of parts, but you get the idea. Whenever I develop something, I usually feel pretty comfortable setting my local development environment, one port of my laptop to get the server code running, connecting to a local database on another port, and a client server on another (usually liveserver or webpack). But, I started asking the questions, when I get to deploy full web apps, how I should go around hosting?, so far in my journey, I only needed to host static (front end) sites, so I got to get away with netlify, github pages, etc, with only one exception, a Wordpress page I needed to get done, however, to this day, I don't know where is hosted, so I don't worry too much about it.

Some types of hosting

There are quite a lot options you can go around with hosting, which, If I am completely honest, it gets really overwhelming. In a simple way, your application NEEDS to be running in a computer somewhere in the internet, so hosting is mostly about deciding how and where your application will live.

You could use a Shared Hosting, which basically means that there are a bunch of applications living within the same computer, the number can't be determined as it varies with the amount of resources that the host has, there are clearly downsides of this, such as the CPU and memory never being guaranteed for you, and lack of configuration options, since the machine HAS to support multiple apps. On upsides, it can get REALLY cheap.

You could instead prefer a Virtual Machine, which basically is an emulator of another computer within a Host machine (a real computer), this reduces a lot of the downsides of shared hosting, as you basically rent a computer with dedicated resources, ability to configure it however you like. HOWEVER, it has downsides too, as it becomes a little pricier (and can get expensive pretty fast), and the most daunting part, unless you are willing to pay extra for someone to setup, maintain, secure and deploy, you will have to do it yourself, and if you haven't touched a Linux OS (while technically Windows CLI works too, it's not a popular choice), it gets pretty weird.

Another option would be to rent a physical server for yourself, but to be honest, unless I find myself working in a very big company, I don't see me setting something like that anytime soon (although, a dream of mine is to set my own server in my house), it has expanded benefits over virtual machines, but it also gets VERY expensive, which I find understandable, but I have no way/interest of exploring it further to say much else.

Sure, I am getting over some other options, like Heroku and other PaaS (Platform as a Service), but, they are quite straightforward to set up and for the most part, you are limited to paying for more things in the setup (like the database, or other services), so they are most likely not the most cost-effective solution.

So, after thinking a while, that If I wanted to give confidence, and not raise expenses of projects just in ¿irresponsible? hosting, I decided that I wanted to learn how to setup a VPS (virtual private server), however, to be really honest, I am generally scared of things that could incur in a cost, which it gets worse with the generally non-transparent pricing on cloud services (like Amazon Web Services, for example), so I searched for an alternative to ¿locally test? a production server environment.

Just like that, along with getting to know and develop some projects, I added a tiny bit of DevOps to my to-learn list. This week has been pretty fun learning to set up Node Apps on Ubuntu-Server plus Nginx, I still have a lot to learn (like Docker, Vagrant and other tools), but, I think I will get there, pretty sure that it's not going to be soon, but someday I'll be able to be more confident on it.

To be honest, I wanted to write a little about the setup process, but this post has already become too long to my taste. So, If you want to keep up, you should definitely follow me here, or on twitter or visit my site: fangoh.dev

The first Open Source contribution, a beginner perspective

Hector Osuna — Sat, 06 Feb 2021 06:09:59 +0000

Developers are no strangers to using open source code, it's something normal. As a beginner, it's natural to think that the people behind it have years of experience doing so, I certainly did. If you asked me last week I wouldn't never imagined that I would make my first successful PR. But hey, here we are.

The motive

My journey began a few days ago when I wanted to learn the gist of JSON Web Tokens for user authentication, but didn't felt like messing with an existing project. So I decided to set up a quick server using Express with Typescript, after all, this practice was meant for one and one purpose only (Oh boy, I was wrong).

Problems arised when I decided that I needed Browser Hot Reload, and since I wanted to do Vanilla FrontEnd, I wouldn't set up a tool like webpack. So I decided to go with a lightweight solution, the node-liverload package, it gets the job done, but since it isn't as popular as a dedicated bundler I couldn't find a .d.ts file anywhere, as a result, the TS Compiler wasn't very happy about it.

The determination

After Googling for a bit, I found the usual way to solve the problem, create a local directory to store custom declaration files for existing npm packages. To be honest, that solution would have been enough for my use case, since livereload normal usage requires only 2 lines of code in the app.js file. However, I have been playing with TS for a bit, so it was natural to wonder Wouldn't be nice to have an npm install @types/livereload? (little spoiler, it's available now).

I thought that maybe I would want to use livereload with TS again in the future, and it wouldn't be practical to redo the declaration file, or maybe I was getting ambitious with TS and wanted the full intellisense on the methods. Whatever the case was, I must admit that I was inspired by this article about the process of contribuiting to DefinitelyTyped. It can't be that difficult, right? (For once, I was right here).

Photo by Hannah Busing on Unsplash

The process

Specifically for adding a type for Definitely Typed, the task needed pretty much these steps:

Write the required file.
Test.
Make sure you follow the guidelines.
Open the Pull Request.

Write the required file.

This part is pretty interesting, I feel pretty much like a beginner in the whole WebDev ecosystem, I had never worked before on someone else's code, as a result, at first it felt pretty daunting What if I'm not ready?, well you got to start somewhere.

In order to make useful Type Definitions, I had to dive in livereload source code, which is written in CoffeeScript (I haven't had the pleasure to learn it neither), therefore, I spent some quality time re-writting it in TypeScript in order to make the appropiate parameters and such.

During this quality time, I learned 3 very importante things:

How the library works (pretty interesting stuff, to be honest)
The importance of writing good, clean code (I'm very grateful to the author)
Coding anything is like building Legos, with the difference that the pieces are huge, and more often than not, you find yourself within a very big community (More on this later).

Test your files

Definitely Typed (DT) (and most if not all open source repos), has a solid guideline in order to make the repo mantainable. One of the principles to make a Pull Request, is to write the appropiate test files and pass them with their configuration.

Specifically in this case, the test is a file that uses the interface/type that you worked on, the suggested way to do this, is to adapt the original library example code to TS, if the compiler finds no problems with it, then you are good to go. I want to notice, that DT have a specific linter for their packages, so some things that would normally run without issues with TSC, don't work here.

As a solo-developer for the last year, I could see that tests may seem something that we could overlook, however, if someone where to modify one file to add functionality, tests are an amazing way to verify if a bug or some breaking changes where made, in order to fix them. In this case, tests where required, but I have seen a lot of pull requests being delayed in order to request tests.

Make sure you follow the guidelines

The main point of this part, is that you will definitely need to address all the guidelines of the specific project you want to work on, that's normal, and it may seem daunting at first, however, stricter requirements usually have very clear instructions.

In DT, the packages must have a tsconfig.json, a tslint.json with the appropiate configuration, otherwise, the PR's aren't merged. Luckily, a tool is given to help with this part.

Open the Pull Request

This is possibly the most nerve-wracking part, I can't exactly pinpoint why. Maybe is the feeling of exposing your code to the world to see, as an aspiring Full Stack Developer, I'm used to show what my code can do, not what my code is, it could be the feeling that I am a rookie who it's about to be judged by the pros.

Whatever it is, I also became more and more excited while this was happening. My first reviewer was a bot, it automates a lot of parts of the process and makes the merging process even more seamless (Definitely Typed contains definitions for about 6000+ packages, it's natural to have a bot there).

Before I realized, the PR tests passed, and a mantainer gave my package the green flag, so, in a couple of hours I received this notification:

Yay, I did it!

What I learned

Never it's to early to give open source a try, this is a small contribution, but I believe that it could help a fellow developer (maybe myself) in the near future. After all, open source is about little building blocks to make great things.

Now I have the confidence to dive in other people source codes, they won't eat me. This kind of collaboration is a great experience that I definitely recommend and expect to live again in the near future.

Consider following me on Twitter, I try to share a little bit of my coding adventure there.