Forem: Benedict Nkeonye

Building TVFlixx

Benedict Nkeonye — Sat, 13 Aug 2022 10:49:21 +0000

Hiya!

A little over two years ago, I started my journey into the world of Vue.js after a long and probably-never-ending stint with Angular. Working with Vue.js has been rewarding and there are more things to uncover even as work continues on the amazing framework and its libraries, e.g Nuxt.js.

Working with Angular gave me working TypeScript knowledge, but I (have) never tried to build anything with TypeScript outside Angular. I had to do a quick refresh on TypeScript with a scrimba course and toe-dipping into the Vue.js<>TypeScript world with this amazing YouTube playlist.

I am a huge TV shows fan, and I tweet a lot about my current favorites (follow me 🤩!), but I never thought about building an app to play around with TV shows data until now.
I built Moflixx with Angular sometime in 2019 but It was based on a Movies API. I wanted to build an application that would help me work with Vue.js (Composition API) and TypeScript and now felt like a great time to play around with some TV shows data.

The User Interface

Like Moflixx, I needed an API to fetch TV shows data from. It took a few days, but I found Episodate surprisingly off a series of GitHub search. I explored the data, it wasn't super robust in terms of endpoints available but It had everything I needed for TVFlixx.

I needed some inspiration for the UI, but I did not also want to stray too far away from what my datasource website looked like, Episodate's interface pretty much did it for me, so I borrowed a few UI tips.

Next, I needed a structure for TVFlixx. I wrote down a list of components and pages I felt I would need and sketched a few things as well for the components. A regular for me in this type of application is the Favorites page.

Pages	Components
- `TVShows`	- `Episodes`
- `NotFound` / `404`	- `Pagination`
- `TVShowDetails`	- `Header`
- `Favorites`	- `TVShow`
	- `TVShowList`
	- `Loading` component
	- `Carousel`
	- `CarouselItem` component

With the help of a few resources, I built some components I could have easily installed a few packages for.
For the next few paragraphs, I will explain the reasoning behind the choice of some components.

The TVShows page is a simple page that shows a paginated list of TV shows from the API, 20 items are shown on each page depending on the items available from the API.

The TVShowDetails page employs more of the other components.
For instance, I use the Carousel and CarouselItem components to show a list of images that comes with each TV show item - this helps any prospective user view the images one at a time or select any image from the preview.

I also use the Episodes component in the TVShowDetails page, the component takes an episodes prop which is an array of all the episodes contained in objects for a particular TV show. This component filters each item in the array by their season and creates a view that enable users view list of episodes per season by selecting a button showing the season they are interested in.

The TVShow component needed a few iterations before I could get what I wanted.

I wanted an hover effect to cause the card to flip to the other side to show some details and allow a user "see more details" about the TV show, took a while but I achieved it.

Front of card	Flip side

The other components are pretty much self-explanatory.

The TypeScript Part

I use the Volar extension in my VS Code, so I had to enable the Template Interpolation Service to do some validation and code completion in the template. I also wanted to explore the Composition API more and using the defineComponent method from vue was a good decision.

First, I knew I had to define the structure for the objects I would be using within the app. I created some interfaces to handle the data coming into each page and component and tried really hard to avoid the any type 😅.

The Episodes component required a special custom type different from the other interfaces I created, because it eventually provided an object of arrays and the type for the key for the items in the object weren't exactly known or constant before runtime as they were the values of the season field for the episodes.
This extract from the TypeScript docs came in handy:

import Episode from "./Episode"

interface SeasonEpisodes { 
    [index: string]: Episode[]
}

export default SeasonEpisodes;

I also needed to handle issues around passing props to the components and ensuring the right type was enforced for the objects using type assertion with PropType imported from vue.

Conclusion

I use the composition API extensively at work, but using it with TypeScript encourages a bit more sanity within the codebase and data flow across components.
I will probably do some tweaks in the application (especially the UI) in the future but I really just wanted to focus on how I could work with the composition API and TypeScript.

I wanted to share my thoughts around working with TypeScript and Vue.js, this article mostly captures the parts I thought were worth talking about.

The Repository on GitHub - star the repo if you enjoyed this!

Thank you for reading.

References

Learning Vue.js

Benedict Nkeonye — Sat, 16 May 2020 00:54:41 +0000

Hello there!

My first introduction to JavaScript frameworks and libraries was sometime in October 2018 and the framework was Angular. Almost two years down the line, I have relatively tried nothing else, Apart from some contributions I made to a friend's React project very recently, I only have a ToDo application written in React and that's all, however, most of my projects, both work, and side projects are/were created using Angular.

I recently built the back-end for my personal website using Node.js and Express, this comes off the heels of taking some months to dive into another JavaScript framework and the Back-end as I've been a Front-end developer all my dev-life. I wanted to understand the MEAN Stack, so Node.js made sense at the time. I wrote about that journey here, it also involved an open-source contribution to MDN's Tutorial on Node.js and Express. 🙌

I recently started learning Vue. I am currently using Vuemastery and I have so far enjoyed the simplicity of the beginner track course and the method they have adopted. As some of you would expect, I went into the course looking for similarities and differences between my comfort zone, Angular, and Vue.js, this is partly due to statements I have heard and read about Vue.js in the past. One of them is Vue.js takes the best parts of Angular and React.

I am still very much a beginner in Vue.js, I have not even used the Vue CLI as I am thoroughly enjoying the script tag for now, but I have so far been able to draw up a few points of similarities or differences between Angular and Vue.js.

Disclaimer: I still have not used the Vue CLI, the next set of points are from my experience using the Vue.js starter script tag.

I immediately understood the Vue Instance as the heart of the Vue application, this was easily comparable to the app-component in an Angular application. My views on this particular point might change when I have to create a Vue.js project with its CLI.
We have structural directives in Angular, three of the common ones are NgIf, NgFor, and NgSwitch. Vue.js has v-if, v-for, and v-else, e.t.c. I like how v-show is present in Vue.js, we had NgShow in AngularJS, but NgIf in Angular2++ has us covered to a good extent, even though it has its quirks (like using the NgIf directive when working with ChartJS in Angular), you are better off using the 'hidden' attribute instead.

Part of the things I had to pick up early in Angular was communication between components and events played a major part in this aspect. I am yet to find the equivalent of Angular's Input and Output in Vue.js, however, in the case of events, it is pretty straightforward to understand it the way I understood events and property binding in Angular. I would say 'v-on' or '@' for event binding in Vue.js, round brackets, '()' for event binding in Angular. I would also say 'v-bind' or ':' for property binding in Vue.js, square brackets, '[]', for property binding in Angular.

For transmission of events in Angular, we use the EventEmitter and its emit method, while in Vue.js, there is the component's $emit method. I also like how flexible it is to use the $emit method, especially how you can pass arguments to it in the process, two arguments - the event and perhaps, if needed, an ID. In Angular, we pass the $event as a parameter.

I have also seen the presence of props in Vue.js as I created my first Vue.js component last night ☺️, this is a similarity with React, if it is used in the same way, that's still something I will have to discover as I continue the journey.

I hope to turn this into a series and I am looking forward to more similarities or differences as these comparisons help me understand Vue.js even better, with my background as an Angular developer playing a huge role.

Kindly drop comments if I missed out anything, no spoilers please, thank you.

Creating A Show-or-Hide-Password Feature For Angular Forms

Benedict Nkeonye — Sat, 15 Feb 2020 03:22:56 +0000

Hello there!

A few days ago, I had to help our users on one of our products get their password right on the first try and some people, as I have observed, do not like not being able to see what they are typing, hence the need for this feature.

In this write-up, I hope to show you how to create a show or hide feature in your password input in Angular forms.

Our arsenal for the adventure

The wonderful Angular Reactive forms
The ngClass directive
A bit of Bootstrap's beauty
Awesome Fontawesome icons

Ok, let's get serious...

First, we create a new angular project. I have angular version 8 installed globally in my machine, but you can still follow along.

                           ng new show-hide-password

You'd get a few prompts about routing, stylesheets and git initialization, you can do as you please.

Installation of packages

After the creation process was completed, I opened the project in my text editor to begin the necessary installations, starting with Bootstrap using npm. This repository branch has the necessary information for the Bootstrap version installed. I installed Fontawesome as well since we will be using the icons available. The command below would suffice.

                            npm i bootstrap font-awesome

Note: please check the project's package.json for any other dependency installed. These include jquery, popper and angular-font-awesome, now, let's go back to the article.

Creating The Form

I created a new component called 'sample-form', this component is to hold our form.
I replaced the content of the app.component.html file with a navbar markup and the selector for the sample-form component.

Our form looks like this now:

Of course, It is a reactive form and I'll share the code as well.
The component:

The template:

Here's the repository branch concerned with this section for your perusal.

The Fun Part

So far, we have created the form and given it some basic styling, now we need to bring in the fontawesome icons and introduce the logic to show or hide the password.
Firstly, we have to edit our markup to accommodate the icons. Bootstrap has a very useful class called the input-group in the forms category, within the input group class, we have the 'input-group-append' and 'input-group-prepend' classes.
These classes position the icons for us just on the ends of the input, neatly as well. We use 'prepend' for our email input and 'append' for the password inputs. See the extracts of the markup below.

The form looks like this now:

Here's the repository branch for this section for your perusal.

The Serious Fun Part, seriously :)

We are eighty percent done with our form, now we just need to add that logic to show or hide the password. We employ the ngClass directive, a one-liner from the official angular docs says 'NgClass adds and removes CSS classes on an HTML element'. Now, that's cool but there's something even way cooler, we can use NgClass with conditionals, here's a small explanation with code.

Now, because of this amazing ngClass property, we can create a condition for when we want to show our password or hide it. The most popular trick about 'show or hide password' is to convert the form input type from 'password' to 'text' and that is exactly what we do here. We do have to declare the property 'fieldTextType' in our component first.

Next, we bring in ngClass for the action part.

In the component, we have a toggleFieldType method doing the switch.

Here is the repository branch concerned with this section.

Our form finally works like this:

Conclusion

In this article, we have seen how to use the ngClass directive to create a 'show-or-hide' feature for our password input in angular forms.
The project is hosted here
Find the full code in the repo linked below, the master branch is updated.

Benneee / show-hide-password

The repository for my dev.to post (https://bit.ly/2SGChq0) on show/hide password feature using features in Angular.

ShowHidePassword

This is the repository for my article on creating a show or hide password feature up on dev.to.

The article explains how we use ngClass, angular forms, bootstrap 4 and fontawesome icons to create such a helpful feature, enjoy the post! I hope you find it useful someday.

View on GitHub

Thank you for reading, I hope you find this useful someday.
Kindly drop your comments or feedback, I'll be grateful.

Cheers!

Learning Node.js & Express (4)

Benedict Nkeonye — Wed, 20 Nov 2019 22:30:42 +0000

Hiya! It is wonderful to be back with you again today.

In our previous meeting, I talked about hooking Local Library up with a MongoDB database, I mentioned a few tips that helped me avoid the pitfalls during the configuration of the database. I also talked about models, routes and controllers and explained their relative duties as far as our project is concerned.

A quick reminder that this series is based on my learnings from MDN.

Today, I will be talking to us about "Displaying the Local Library Data", there will be two main talking points:

Asynchronous Flow Using the 'Async' Module
Templates

Let's get to it then!

Asynchronous Flow Using the 'Async' Module
Due to the asynchronous nature of our requests for data from the database, we need to be able to control the flow of the data. Node.js provides the 'async' module for this reason. Three important methods of the async module are 'async.parallel', 'async.series' and 'async.waterfall'.

async.parallel is used when requests must be made in parallel.
async.series is used to handle requests that must be made in series and each subsequent request is not dependent on the previous request's result. So, in a way, this does work like async.parallel.
async.waterfall handles requests that must be made in series and where the next request is dependent on the result of the current request.

Templates
A template is a text file defining the structure or layout of an output file, with placeholders used to represent where data will be inserted when the template is rendered.

It is worthy to note that different template languages use different approaches for defining the layout and marking placeholders for data in the template.

Some use HTML to define the layout
Some use markup format that can be compiled to HTML (e.g pug)

Pug is a clean and white-space sensitive template language. It reminded me a bit of Python at first glance. Pug has some attributes that will help one create amazing pages, the drawback, however, is that the error messages generated are not the most helpful, plus its white-space sensitivity is very important to remember when creating markup with it.

Some features of Pug

Element attributes are defined in parentheses after their associated element. Inside the parentheses, the attributes are defined in the comma-separated list of pairs of attribute name and attribute values.
If a tag is followed by the equals sign, the following text is treated as a JavaScript expression (read variable).
You can also concatenate variables with plain text in the template. The plain text has to be in quotes.
e.g p='Evaluated expression: ' + title
title above is a variable.
You can also extend templates. In a large site where you have different pages, you are bound to have, at least, the starter template of any HTML file - the head section - in all the pages. A base template can be defined to hold the boilerplate markup and on the other pages, the extends keyword is used to reference this base template.
See here for more details on templates.

Now, let us see the improvements the async module and templates have brought to the Local Library project.

The first template created was the layout.pug file, this file represents our base template for the Local Library project. The design for the local library user interface is such that it has a sidebar for navigation and because this is expected to be seen in all the different pages, we place the markup in layout.pug. We use Bootstrap 3.3.7 for styling in this project
For cognisance, the pages that will be seen in the Local Library project include
Book, Author, Book instance (copies of books), Genre.
On the homepage of the project, we show a list of all records and the count for each of them.
We update the bookController.js file to return the count of each of our records using the countDocument method provided by mongoose. We use the async.parallel method to handle the request to get the data from our database. The models for the other resources are first imported into the bookController.js file so that their data can be accessed.

We update the view (index.pug) with dynamic content generated after the results are received from the controller. The snapshot below shows this process.

Here's what our Local Library looks like for now:

P.S Content for the other pages will be generated later in subsequent articles.

Thank you for joining me today, I do hope you learnt a thing or two.

Happy Coding!!

Learning Node.js & Express (3)

Benedict Nkeonye — Tue, 19 Nov 2019 22:17:24 +0000

Hiya everyone!

A quick recap of what was discussed in the previous part of this series:
I talked about View Engines and Database. I also shared links to the MDN articles that will help you make decisions when selecting a View Engine or Database. I also mentioned ORMs and ODMs which are one of the two ways we can communicate with the preferred database, the other way is using the database native query language.

Today, I want to talk about Models ==> Controllers ==> Routes and how I created them for the local library project following the Mozilla Development Network Node.js & Express Tutorials.

Before we dive in, I had to set up the database. The database adopted for the Local Library project is MongoDB, hence, we use the Mongoose ORM to communicate with the Database; creating, listing, updating and deleting files are done using the Mongoose methods. As I mentioned in the previous part of this write-up, using an ORM such as Mongoose helps us to continue thinking in terms of Javascript objects and avoid database semantics.

I already have an account on MongoDB cloud facility, all I needed to do was to create a new database and cluster. The process is well explained in the Mongoose section of the MDN tutorial.
However, here are some tips that would save you some time and headache:

In the "Connect to Cluster" section, you need to add an IP address that will allow you connect to the database from anywhere. The address given in the tutorial, '0.0.0.0/0', will not work as at the time of writing this post, what you want to type in there is '127.0.0.0.1'.
When you copy the connection string according to the last part of the instructions for setting up the MongoDB database, change 'test' in the connection string to 'local_library' as this is what you titled your database and you'd most likely be looking for your data after populating the database in the wrong place if you do not make this change.
After setting up the cluster and database completely, you now want to go back to edit the IP address you entered, the page will be opened up on another tab and as at that time, you'll be able to type in '0.0.0.0/0'.

Mongoose is then installed and the script to connect to the database is seen in this section of the MDN tutorial.
Another serious tip:

Mongoose.connect returns a promise, please remember to handle this by calling the .then and .catch or however you choose to handle the promise. The code linked above did not include this part.
You also want to add another option inside the connect object other than useNewUrlParser, useUnifiedTopology, this should also be given a value of true just like the useNewUrlParser, see the snapshot below.

At this point, we can now talk about Models ==> Routes ==> Controllers.

Models
Models help us define a structure for our data. We can however not create models if we have not designed a relationship between the different parts of our application. For our models, Mongoose provides the 'Schema' interface. This interface helps us define the models we need for Local Library.
When designing models, it makes sense to have separate models for every object - a group of related information, e.g select-list options
The Schema describes the value type expected for a particular item.
examples of the models for Local Library includes:

author.js
book.js Mongoose also provides the 'virtual' interface. A virtual is created in a model and it can be used to get the named URL required to get an instance of a model. We can use this property within the template when we need a link to a particular author, for instance.

Controllers
Controllers are basically functions that separate out the code to route the request from the code that processes the request. Mindboggling, yes? worry not, I will explain.
Basically, what the controller does is that it provides the data required when the route linked to the model property it is attached to. For instance, under the authors model, we have a property in our controller linked to this model called the author_list, this controller property displays a list of authors. Eventually, the route linked to this author_list calls the controller which in turn calls the model and a call is made to the database which provides the list of authors.

Routes
A route is a section of express code that associates an HTTP verb (GET, POST, PUT, DELETE), a URL path/pattern and a function (controller) that is called to handle the path/pattern.
Routes can be considered to be the URL handling code. The Express Router is required and used within the module. The controller files are also required so that the different parts for each model can be routed to if they have some data to be displayed.
Basically, the route calls the controller, the controller calls the model and the model calls the database, once there is a response, the data is sent back all the way to the controller which provides an HTTP response and/or provides the content for the template.

Conclusion
In this article, I talked about setting up the database and clusters needed for the Local Library project, I also talked about Models, Controllers and Routes and how they work together to present data to the View or as an HTTP Response.
In the next write-up, I will be talking about Displaying the Library Data to the view and other related topics.

P.S. Some data was used to populate the DB using a populatedb.js file which contained scripts pushing the data to our MongoDB database. Inside the populatedb.js file, you also want to handle the promise that mongoose.connect method returns as it was not also handled in the script.

Follow my progress on Local Library

See you next time!

Happy Coding!!

Learning Node.js & Express (2)

Benedict Nkeonye — Mon, 18 Nov 2019 20:40:27 +0000

Hello once again!

Yesterday, I wrote briefly about how I have started learning Node.js and Express. I mentioned I would be sticking with the tutorial on Mozilla Development Network for Node.js and Express. I also talked about other supporting materials such as Beginning Node.js and Learn NodeJS in One Day.

Today, I want to run through my progress so far and share a few things I have come to understand so far. The first thing I created after going through the theoretical parts of Node.js from the 'Learn Node.js in One Day' book was this simple server, all it did was print "Hello World" on the screen when you navigate to port 8000 while the code is running in the terminal. This made me smile.

I dove deeper into the MDN tutorials in the next few days, then I got introduced to the minimalist and unopinionated Node.js web framework called Express. One of the things I like about Express is the Express Generator, simply because of the ease to generate a project by using express name-of-app/project. On running this command, the following will be generated:

I will talk about these files in a later article.

View Engines
The MDN tutorial's first project endeavour is to build a local library website, now, you would expect a website to have actual pages we can see stuff like 'books', right? Node.js does provide us with view options made possible by something called 'Template Engines'. These Template Engines help us to present data on the client-side. Ordinarily, the default template engine provided if you run express hello-world would be the engine called Pug (formerly Jade).

MDN does a good job of explaining consideration points before selecting a template, some of them include:

Time to productivity
Popularity and activity

See the write-up here

Database
When building APIs, you will most likely want to save data somewhere, persist whatever is created or edited on the client, this is where the database comes in. Node.js works with various types of database, SQL or NoSQL and Express works with the databases Node.js supports as it does not have any specifics when it comes to Databases.
MDN describes how you can communicate with your preferred database in two ways.

Using the database's native query language
Using an Object Data Model or Object Relational Model

A good example of the second option is Mongoose, the ORM/ODM used to communicate with a MongoDB database. Choosing an ORM like Mongoose is advantageous because we can avoid the use of database semantics and continue thinking in terms of JavaScript objects. These points from MDN can help you make a decision when selecting an ORM or ODM.

Conclusion
In this article, I talked about the Express Generator, View engines and Database. In the next set of articles, I will talk about the Local Library project and my progress in it so far. As always, the code for this journey lives here

Thank you for sticking with me to this point.
Happy Building!

Learning Node.js & Express (1)

Benedict Nkeonye — Sun, 17 Nov 2019 22:55:25 +0000

I have been a front-end developer since my break into the technology industry, a little over a year now. My first programming language was actually Python, but that relationship was a bit too short and an internship opportunity came for me which entailed learning JavaScript and subsequently, Angular, I immediately grabbed it.

I, however, have a goal to understand the MEAN Stack before the end of 2019. This meant I had to learn Node.js, Express and MongoDB (not in its entirety since there's mongoose).

A friend told me about the MongoDB University courses, I thought it would be a great place to start since it was learning directly from the source. I had to take the basic level thrice because I failed once and could not meet up the timeline for the tests in the first attempt. I was third time lucky. This happened in September.

In the first week of October, I decided it was time to start learning Node.js. I decided to scour UDEMY and other similar places for courses on Node.js but they all looked really long for the moment and I really wanted to read this time, I was fed up with the video tutorials.

I settled for two books; Beginning Node.js and Learn NodeJS in One Day. I consulted a friend who recommended MDN's Node.js & Express Tutorial because he used it.

I created a GitHub repository to track my progress and store all the code that would be generated during the next few months. I read on transit to and from the office, so I quickly wrapped up the #TransitRead that spilt into October from September just so that I could begin Learn NodeJS in One Day, of course, I couldn't finish the book in one day, heck!, I'm still reading it.

So far, I have created my first server, writing and rewriting and then understanding what was done in the book, and pushed the code to GitHub. I have read about how Node.js ensures a non-blocking process in its operations and the suitable applications one can adopt a Node.js back-end. Following the MDN tutorial, I've been introduced to Express, a minimalist unopinionated web framework for Node.js and the Express App Generator, a wonderful tool, along with a host of middleware and libraries, if you will.

I am currently more into the MDN tutorial because of the insight it provides and the things I get to build, although, I really want to understand Node.js in itself before diving into any of its frameworks, fortunately, and unfortunately, MDN dives into Express before I knew what was happening. I did find a Node.js course on UDEMY that dives deep into Node.js before moving on to Express and other frameworks, I'll probably take that after I am done with MDN. For now, it's the book and MDN.

As I continue this journey, I want to document my experience here, I might mostly talk about my understanding - so more theory and less code. I have learnt quite a lot already, I will write a second part to this article tomorrow to talk about all I have learnt this weekend.

I'm so excited for what lies ahead!