DEV Community: samuel-casey

Learning TypeScript: Part II

samuel-casey — Sun, 06 Dec 2020 18:29:01 +0000

This is blog #2 in my series on how I'm teaching myself TypeScript. I cover things I've learned, provide links to resources I've found helpful, and share some personal best practices I've developed over the course of the past 3 months. The blogs make will make sense whether you read them in order or out of order, but if you're completely new to TypeScript, I suggest you start with Part I.

Intro

After playing around in the TypeScript Playground and docs, refactoring some of my old JavaScript code into TypeScript, and building my portfolio with TypeScript + jQuery, the next steps in my journey were to create some very basic apps with TypeScript + React and develop my first TypeScript APIs.

In this blog I cover things I've learned about:

TypeScript's features
Navigating the TypeScript ecosystem and configuring projects
Developing personal best practices for working with TypeScript
How I plan to continue furthering my TypeScript skills

TypeScript's Features

Being a superset JavaScript, TypeScript has a lot of additional features that can be overwhelming at first for JavaScript developers when first going through the TypeScript docs. For me, reading about things like Interfaces, Types, and Tuples lead to a lot of confusion about when I would use these features and why they are valuable.

h/t to this blog for the original image used as the base for this graphic

Two YouTubers that do a great job of showing real-world examples of when it makes sense to use various TypeScript features are Harry Wolff and Ben Awad. They both have multiple videos on specific TypeScript features where they walk through realistic code-snippets that show when it does and does not make sense to use certain features of the language.

That being said, watching a YouTube video or reading a code-snippet from documentation is not enough to fully grasp and internalize any given TypeScript feature and its utility. In order to really make the language work for you, it's important to experiment and build your own on projects, even if very simple. Projects will allow you to develop your own style, build confidence, and start to see firsthand the benefits of Typescript's extra features. That being said, it's not necessary to use all of a language's features in every project just because they exist. The only way to figure out which features make sense for the problem you're trying to solve is by building projects.

For example, TypeScript has a lot of features that make it a better OOP language than JavaScript, but it can also be used for Functional Programming. This video by Fireship helped me understand that just because TypeScript has great OOP tooling, doesn't mean I have to use OOP for every single TypeScript project if it doesn't make sense or if it will slow me down.

So far, I've found myself using Static Typing and Interfaces in every project, Declaration Files and Generics in some projects, and rarely Enums or Tuples.

I'm certain there are some things I'm missing right now, but that's OK. The important thing for me is that I'm seeing benefits from using TypeScript, especially in my Node projects. I'm also learning more about computer science concepts and writing cleaner code as a result of working in TypeScript. So far I've only developed small solo projects, so I look forward to learning more about TypeScript's features as I begin to work on larger projects with other developers.

Navigating the the TypeScript Ecosystem and Configuring TypeScript Projects

TypeScript is a compiled language, and can take some configuration before starting development on any given project. Depending on which packages you are trying to use in your project, you may need to set up Declaration Files or install pre-existing type declarations from npm. For example, if working with TypeScript and jQuery, you'll need to install @types/jquery, and choose a JavaScript compiler like parcel bundler, Webpack, etc.

Sometimes, you may also need to change your ts-config based on which packages and frameworks you're using. I suggest googling the name of the tech you want to use with "TypeScript + ts-config file" (e.g TypeScript and jQuery ts-config file) to find some settings that will work for your project rather than learning what each and every one of the options does when first getting started.

Though you can customize your ts-config file and install additional packages/compilers for your projects, there are also a lot of tools/frameworks that come with TypeScript support built in. If you're like me, you would rather spend your time writing code than configuring and customizing your project's setup, using solutions with great TypeScript support already built in is the way to go. I personally have found create-react-app and (for frontend projects) and Google Firebase (for building APIs) to be great solutions for simple TypeScript projects.

Developing Personal Best Practices

The most important thing I've learned so far while working with TypeScript, is that programming languages are just problem solving tools and that no one language or paradigm is inherently better than another. I have heard this point from more seasoned devs before, and have been able to see the strengths and weaknesses of different languages by building projects in JavaScript, Python, and Ruby, but working with TypeScript has really driven this point home for me because it is so similar to JavaScript. I personally like using TypeScript for backend development more than frontend development.

h/t Mark Pollman for this image

When building an API I want to make it as clean and foolproof as possible. When creating frontends, I like to have more room for creativity and the ability to iterate quickly. TypeScript is more deliberate than JavaScript, and often requires more keystrokes/steps to accomplish the same outcome. At the risk of sounding naive, I don't see much benefit in statically typing things like event handlers in my React code. It feels like an extra step to me that just slows me down. Statically typing function parameters for my API makes complete sense to me, however, because a user could easily input a number into a field that the database expects to be a string, which could cause problems.

In the spirit of making the language work for me, I've become more comfortable with using the any type at times as long as I use it sparingly and avoid using it for primitive types. Using the any everywhere in your TypeScript code kinda defeats the whole purpose of the language, but using it once in a while in the interest of getting your program to "just work" is not a cardinal sin in my opinion.

There's no such thing as perfect code, and as long as you aren't writing software that requires extreme precision for something like a self-driving car or a medical device, attempting to write the most perfect code possible all the time can cause more harm than good and stifle progress. Your future-self will thank you for writing the cleanest code possible, but your future self will also never exist if you spend the rest of your life trying to debug an error that could be solved just by declaring an any type.

Conclusion and What's Next

I've been enjoying using TypeScript so far, and I'm excited to continue working with it and improving my skills. So far, I've learned about a lot of its features and using some of them even feels second nature at this point. If you're just getting your toes wet with TypeScript, or feel intimidated by it at all (like I was at first), then I encourage you to keep going because it gets easier with time and ultimately will improve aspects of your code and programming experience dramatically.

My next steps are:

Learn typeORM and build an API that takes advantage of TypeScript's OOP features
Build a project with Next.js + TypeScript

If you're also learning TypeScript I hope you found reading about my experience helpful. If you have any questions, suggestions for how to improve this blog, or if you feel I have gotten anything wrong please do not hesitate to leave a comment below or reach out to me via Twitter DM!

Learning TypeScript: Part I

samuel-casey — Fri, 04 Dec 2020 01:22:33 +0000

This is a repost of a Medium article I wrote a few months ago. I decided it makes sense to share here too in case anyone in the dev.to community is experienced with JavaScript and trying to teach themselves TypeScript for the first time. I have written a lot more TypeScript since publishing this article, and plan on posting Part II of this blog this weekend in which I'll go over some lessons learned from building and deploying my first React and API builds written in TypeScript.

This week, I built and deployed my first TypeScript project: a new portfolio site. Up until two weeks ago, I had only used JavaScript, JQuery, and React for web-development, but after watching this video by Ben Awad where he mentions that after you learn TypeScript, developing in JavaScript will feel like "playing web-dev on hardcore mode", I decided it was worth learning. This blog covers how I've been teaching myself, what I've learned so far, and how I'm going to continue learning TypeScript

How I've been learning

I'm currently enrolled in a General Assembly (GA) Software Engineering Bootcamp. The focus of Unit 1 was HTML, CSS, and JavaScript. Given that I have a fair amount of experience with JavaScript, I decided to teach myself TypeScript alongside our JavaScript lessons. My workflow for teaching myself had four steps:

1. Take notes during my GA lectures focused on the fundamentals data types of JavaScript, Object Oriented Programming, and ES6 syntax.

While I was doing this, I also had the TypeScript docs open on my other monitor so I could compare how data types work in JavaScript with how they work in TypeScript

Here's a snippet from my lecture notes on Arrays:

2. Do my homework assignments in JavaScript first to think through the logic of the assignments.

I find it easier to focus on learning the idiosyncrasies of a new language or library when I don't have to think about both the new syntax and the actual application logic

3. Refactor my homeworks into TypeScript

When I was first learning React, I started by rebuilding a tic-tac-toe game that I originally had built in JQuery, and found that process to be a great way of learning. This homework, a random tarot card generator, is an example of one of the homeworks I refactored.

4. Google every single error I get and allow myself to go deep down rabbit holes while exploring solutions

Usually when I come across errors while developing, I look to find the quickest fix to my errors and keep moving forward once I find a fix. While learning TypeScript, however, I've been exploring multiple possible fixes, testing them more thoroughly, and making sure that I understand why the solutions I find are fixing my errors, not just considering it "good enough" when I stop seeing error messages.

What I've learned so far

The main things I've learned about TypeScript so far is how beneficial it will be for building larger scale applications, and that I'm a fan. My portfolio site is built with TypeScript, Sass, JQuery, and a Google Sheets API, but even though it's small and serverless, building it with TypeScript allowed me to see some of the benefits of a strongly-typed language. Below are two examples of things I learned about TypeScript while building my portfolio site, and the issues I faced that led to me learning them.

1. Type-checking is about more than just checking primitive data types (interfaces are a wonderful thing)

The projects and blogs listed on my portfolio site are stored in a Google Sheet, per the requirements of my GA assignment. When first making AJAX requests to the Sheets API, I attempted to assign object properties for each project/blog to a new object without defining an Interface for what a Project or Blog object should look like. This resulted in a series of errors as I got further in my code, and helped me fully understand the purpose and benefits of Interfaces.

2. Functions in TypeScript should to have an explicitly defined return type in order to harness the full benefits of using TypeScript

On my second go around with AJAX, after I had defined Interfaces for my Projects and Blog objects, I kept getting the error: TS2355: A function whose declared type is neither 'void' nor 'any' must return a value. The error arose when I tried to map the Array of entries in my Google Sheet to an array of ProjectSheetRow/BlogSheetRow objects. I originally solved the bug by setting the return type for my .map() callback to any, but after reading some Stack Overflow articles and the TypeScript docs, I realized that returning any from a function in my situation was a cop-out. You might as well use JavaScript if you're going to just return any from all of your functions. To fix this error, I returned {object properties} as ProjectSheetRow or BlogSheetRow, which were the names of my Interfaces

Next steps in my TypeScript education

1. Build a project with TypeScript + React

I was required to use JQuery for my portfolio site because of my GA assignment, but I don't think I'll ever use JQuery + TypeScript ever again, as React is my favorite front-end tool and it seems to have good support for TypeScript.

2. Build a fullstack project using TypeScript

TypeScript is great for front-end development, but I'm most excited to start using it for the backend. A few months ago, I built an app to help visualize realtime tide-levels at any beach around the United States which probably would have been easier to debug in TypeScript. When writing the function to compare the timezone from the user's inputted location to the list of tide stations in my database, I spent hours debugging an issue that stemmed from me trying to compare a number to a string. If I had been using TypeScript for this project, I probably would have discovered this error sooner and saved myself a lot of time and a major headache.

3. Get involved in the TypeScript community online

I'm certain there are still things I do not fully understand about TypeScript yet, and while I'm confident in my abilities to teach myself new concepts, I think I'll learn much faster with help from others. I plan on posting StackOverflow questions, commenting on some Dev.to blogs about TypeScript, and eventually contributing to an open-source TypeScript project.

In conclusion, if you're reading this blog and have any suggestions for how to become a TypeScript pro, or want to hear more about my TypeScript journey, please reach out! My dms are open on twitter @_samcasey, and I welcome any comments on this blog as well.

Creating Demo Accounts for Web Apps: Learnings from My Two Last Projects

samuel-casey — Thu, 03 Dec 2020 02:54:11 +0000

Creating Demo Accounts for Web Apps: Learnings from My Two Last Projects

Intro

I recently built two projects to learn new skills and bolster my portfolio, both of which include Demo User accounts.

The first project, pause.app is a journaling app to help people keep track of their self-care activities and to-dos. It was a week-long group project built with 3 other developers using the MERN stack and JWT Authentication.

The second was red ink, a platform for connecting writers and editors with specific subject-matter expertise. It was built in 10-days with TypeScript, React, Node and Google Cloud Firestore, and Firebase Authentication.

In this blog I cover:

why demo accounts were necessary for these apps
the initial requirements for the demo accounts
challenges that arose during the development process for pause.app and how we tackled them
what I'll do differently next time based on learnings from red ink

Why Demo Accounts?

Both of these apps are portfolio projects, so requiring someone to create an account in order to see the full functionality is a bad idea. A portfolio is designed to showcase your best work, so introducing friction between your portfolio site's visitors and your apps' coolest features makes it more likely for someone to leave your app before getting to see your best work.

Requirements for the Demo Accounts

The core requirements for the demo accounts of both pause.app and red ink were the same:

1) Demo Users can access all of the same features as a normal user, given that neither app has any paid features yet.

1) Demo Users must have sample data seeded for them for each demo so that they can get an idea of what typical user data looks like without having to create it all themselves.

3) Demo Users will not be able to see data created during previous demos.

4) Accounts can be created with one click.

In order to fulfill all of these requirements, my pause.app teammates and I came up with an initial solution outlined in the diagram below ⬇️

pause.app Challenges

Our original design assumed that it would be O.K. for each demo user to use the same account. This was a naive assumption, and could lead to problems in the event that two people tried to log in to the demo at once. Once we realized this we made a few changes to our design ⬇️

In our new design, each user gets their own account, and each new demo account is seeded with the same data. This ensures that each Demo User will have the same experience, and won't be able to edit anyone else's data.

Thankfully we realized the flaw in our initial design early on, and were able to change our plan before tying together the frontend and backend.

red ink Challenges

Given that pause.app is a journaling app designed for solo use, and red ink is a platform to connect two different types of users, creating Demo Accounts for red ink presented its own unique set of challenges.

A core feature of red ink is that both Writers and Editors receive email notifications when certain events occur in the app. Writers receive notifications when an Editor has finished making edits on the writing they submitted, and Editors receive emails when Writers submit a piece of writing to them, and also when a Writer presses the "remind" button for a given assignment.

Given that Writers receive fewer email notifications, I decided to make the Demo User a Writer account, as that will allow for a Demo User to experience a higher percentage of the app's functionality than if the Demo User were an Editor.

I also had to ensure that Demo Users are not able to actually trigger emails to Editors on the platform so that Editors aren't flooded with emails asking them to Edit documents sent from Demo accounts. This change was simple, requiring only a few extra lines of code for some conditional logic on the server so that the function that sends emails to editors is never called if the Writer submitting a document is a Demo account.

After seeing how simple it was to alter the Demo User's capabilities without changing the experience they see on the frontend, I realized that I can use some more simple conditional logic to clean up my database the next time I create Demo Accounts or if I spend time refactoring the backend of either of these two apps.

For both pause.app and red ink, when new demo data gets seeded, it is stored in the same table / collection as normal user data. This works fine from the user's perspective, but results in records getting added to the database that are identical apart from the timestamp assigned to them. This can make analyzing user data more difficult, as it adds the extra step of having to cut out all of the demo data from the database before being able to analyze the actual user data.

Going forward, I'll make a separate collection/table for demo user data so that to avoid this issue.

Conclusion

Creating Demo Users presents unique challenges for every single app, and there are a lot of approaches one can take to create a rich demo experience for users. It's important to spend time thinking through your desired demo experience before starting to code, and it's also important to think about what may happen if your app is successful in attracting users and you end up having a lot of demo and real user data to deal with.

If you're considering creating a demo experience for your app, I hope this blog helps in some way! If you have any questions or suggestions on how to create better demo experiences, please reach out via Twitter or through my personal site.

Pros and Cons of Building your TypeScript Express API with Firebase

samuel-casey — Wed, 02 Dec 2020 01:53:08 +0000

Intro

In this blog I will share some thoughts about my experience building an Express API with TypeScript using Firebase. I'll go over why I chose Firebase for my project, pros and cons I noticed while using it, and my overall review of my development experience.

The API I was building was for red ink, a platform to connect writers and editors with specific subject matter expertise.

I built the first version of red ink (both frontend and backend) in ten days. The bulk of the API development occurred during the first three days of the build.

Why Firebase?

I initially chose to build with Firebase primarily because of its authentication module. Firebase Authentication offers multiple methods for creating an account, including GMail, Facebook, and Twitter, so it was an ideal solution. An editing platform is not useful without editors, so making it as easy as possible to get editors on board was a key concern of mine.

Given that I was using Firebase Authentication, I thought that using Firestore (Firebase's NoSQL database solution would allow for easy integration of the user data provided by Firebase Authentication, although I learned a full day into my project that this is not the case. Even though there is no intrinsic link between Firebase Authentication and Firestore, it's pretty simple to combine the two.

Functionality of my TypeScript + Express API

The API I built is fairly basic for now. It allows a user to send requests to Create, Read, Update and Delete data from the Firestore database, and also has some routes for sending email notifications to users when certain events occur in the app.

I did not technically need to create an Express server for my app, since Firebase allows you to make calls straight to Firestore from the browser, but I chose to include one in my project for two reasons: to hide API keys used for the email feature of my app, and because I wanted to manipulate the data sent back from Firestore before using it on my frontend.

Pros of building an Express API as a Firebase project

Easy configuration and Deployment

Firebase has a great command line interface that makes it easy to initialize your project and get it deployed quickly. This makes it easy to ensure that the code you write in development will also work in production.

I have had problems in the past with deploying TypeScript APIs to Heroku that have led required lots of Stack Overflow searches and tinkering with the ts-config file to resolve. This was not the case with Firebase at all. Firebase provides a standard ts-config file that required no changes for my project. There are few things more frustrating to me than wasting time on configuration and deployment at the start of a project, especially when working on a tight timeline.

Documentation, Tutorials, and the Community

Firebase has a very thorough documentation, and a great set of tutorials for pretty much everything on the platform. The Google Developer Advocates that lead the tutorials are great communicators and the videos have very high production quality. The series on data modeling for Firestore was particularly useful during this project when designing my database.

Though Firestore is a NoSQL database and very similar to MongoDB (with which I've worked many times), there are some differences with how Firestore and MongoDB perform queries that may effect how you model your data for some projects. The Firestore data modeling series provides many realistic examples for how to model data effectively, which was extremely helpful.

In addition to the Google documentation and Tutorials, there is a vibrant community of Firebase users online, many of whom create tutorials on YouTube and write blogs about common Firebase use cases and problems. Given that not all of the Google videos are up to date with the latest versions of various Firebase products, these can come in handy.

Ease of adding in new tools incrementally

Firebase offers many products -- not just Authentication and a NoSQL database. It can be used for anything from hosting a static site to building a full-fledged web app equipped with analytics that incorporates machine learning. Integrating new tools as they become needed in your app is straightforward and only requires a few changes to your configuration.

I plan on adding cloud storage to red ink in my next sprint in order to allow editors to upload profile photos, pdfs, and word documents to the app with the help of this video.

Cons of building an Express API as a Firebase project

Workflow

When building an Express API on Firebase, your controllers will be used to call cloud functions. Whenever you write make a change to your API you need to deploy your cloud functions again in order for those changes take place. This can take anywhere from 1-3 minutes each time and can seriously slow down your development process. An Express API without cloud functions is much faster to iterate on, even with a database deployed via Heroku. If you plan on building an Express API as a Firebase project, I definitely recommend using TypeScript over JavaScript as it will help you catch errors more quickly which can reduce the amount of times you have to deploy your cloud functions and wait a few minutes to test them.

There may be solutions or workarounds to reduce the amount of time you spend waiting for deployments, but I was unable to find any that worked for me during this 10 day sprint. Please let me know if I'm missing something obvious!

Firestore is not always developer-friendly

When it comes to NoSQL databases, Firestore is pretty good and can get the job done for basic applications, but it is not as robust as MongoDB and can be harder to work with at times.

One example from red ink of how working with Mongoose + MongoDB is easier than working with Firestore is when attempting to create or update multiple documents at once. Mongoose makes it incredibly easy to create or update multiple documents at once, but Firestore requires that you use batching and a loop in order to create multiple documents at once.

While I'm not sure which option is more efficient under the hood, the code required for creating and updating multiple documents at once with MongoDB is much simpler than the code used for the exact same operations with Firestore.

Here's a microcosmic example of how much simpler it can be to work with Mongoose + MongoDB than Firestore

  //// Mongoose + MongoDB ////

  const createManyDocumentsMongo = async (req: Express.request, res: Express.response) : void => {
      try {
        const data: SomeInterface[] = req.body
        const created = await db.create(data)

        // MongoDB returns the newly created data from the .create method if data successfully added to db
        res.status(201).json({status: 201, message: 'created new documents from array', data: created})
      } catch (error) {
        console.log(error)
        res.status(400).json({status: 400, message: 'error trying to create new documents from array'})
      }
  }

  //// Firestore ////

  const createManyDocumentsFirestore = async (req: Express.request, res: Express.response) : void => {
      try {
        const dataArray: SomeInterface[] = req.body
        const batch = db.batch()
        dataArray.forEach((object) => {
            const newDoc = db.collection('someCollection').doc()
            await newDoc.set(object)
        })
        batch.commit()

        // Firestore does not return the newly created data from the .set method if data successfully added to db
        // In this instance, we're just sending back the dataArray
        res.status(201).json({status: 201, message: 'created new documents from array', data: dataArray})
      } catch (error) {
        console.log(error)
        res.status(400).json({status: 400, message: 'error trying to create new documents from array'})
      }
  }

Conclusion

Overall, I enjoyed working with Firebase. Despite its flaws, the ease of getting up and running quickly and the documentation make me likely to use Firebase again for small projects.

I'm very happy with my decision to use Firebase for red ink because I had a limited amount of time to build a prototype and the API's requirements were not very complex. I may end up replacing elements of my backend in the future if I spend a lot of time improving red ink, but for now most of the planned improvements are on the frontend so I will stick with Firebase and Firestore.

If you have any questions about building an Express API as a Firebase project, or feel I have missed anything in this article, please reach out to me via Twitter or through my personal site.