DEV Community: Mayank Pathela

The Power of Console API

Mayank Pathela — Thu, 23 Sep 2021 13:22:40 +0000

When working with a JavaScript project, the most common debugging method we use is putting the console.log("Something happened here", {some_variable}) in between the lines of code and passing some irrelevant and relevant information respectively as parameters to identify where and when the problem occurred.

Have you ever wondered what the other methods supported by console except for console.log() are? Let's walk through some of those fantastic methods in this blog.

What is Console API used for?

Console API provides the functionality to allow the users to perform the debugging level tasks, like logging values of any variable, tracking execution time at different set points in the code.

The most common way to access it using the console object, which can be accessed from anywhere with global scope access. Also, it is supported by Web Workers that’s why it can be easily used in browsing scope without working about concurrency.

Now, let’s have a look over some of the methods provided by it

(Note: I will be using Chrome console, and the output format may differ for different browsers):

Outputting the values on the console:

Primarily there are four standard methods you can access to print a text on the console:

console.log() - This most popular method outputs a message to the console.

console.info() - This method outputs the value in the same way as the console.log(). Some browsers may add the info icon or may format the output differently. For, e.g., in the below image, you can see the console.log() is identified by my React Devtools extension and override it, but the console.info() is not recognized by it, so it is run by the native browser environment:

console.warn() - This method outputs a warning message to the Web console.

console.error() - This method outputs an error message to the Web console.

Apart from these four, there are other methods to output on the console like:

console.dir() - Displays an interactive listing of the properties of a specified JavaScript object. This listing lets you use disclosure triangles to examine the contents of child objects.

Key difference between console.log() and console.dir()-

Here, console.log() prints it HTML-like tree but console.dir() print it in a JSON-like tree.

Another similar method is the console.dirxml(), which displays an XML/HTML Element representation of the specified object if possible or the JavaScript Object view if it is not possible.

Printing the data in the tabular format:

We often have the tabular data that we got in the response from any SQL query or API response. Consider using the console.table(${data}, ${column}) method for the same. E.g.

Secret sauce: Try clicking on the column headings, and don’t get surprised if you see sorted values.

Applying CSS to the output values:

It’s pretty cool that we can format the text we want to print just by using the %c directive with the text we want to print. Let’s dive into the below example to have a close look:

Awesome! Isn’t it?

Let’s have a look at another example with different stylings in the same output:

Printing in the nested group level:

We can use console.group(), console.groupCollapsed(), and console.groupEnd() methods to log the values in a nested format.

In the above example, console.warn(), and console.error() has been used. That's why the final outputs are formatted. Also, the Second Inner level is in the collapsed form.

Tracking the time of any process:

Say we want to track how much time a function takes for the execution, so rather than using any external function we can use console.time(), console.timeLog(), and console.timeEnd().
For example:

Here, console.time("Task 1") started the timer, console.timeLog("Task 1") logs the time in between Task 1 and console.timeEnd("Task 1") ends the timer and prints the final value at the end. Once the timer is stopped, we cannot reaccess it.

Stack trace and conditional tracing of function execution:

console.trace() and console.assert() are practical methods that help trace back the stack of the execution. The difference between these methods is that the console.assert() will only print the stack trace if the first parameter is false and will also print in the same way console.error() method does.

E.g.

Count the number of times a line is being executed:

Suppose you want to track how many times a function has been called, say any recursive function, then console.count() and console.countReset() are a great help. For e.g.

In the above example, you can see it prints the value of how many times the label a has been called, and after calling reset, it goes back to 1 on the next call.

String Substitution using the directives:

You can format the string and substitute it using %s, %o or %O, and %d or %i, %f directives. (For showing a few examples, I am using Firefox console as Chrome console doesn’t support precision formatting)

These were the methods provided by the Console API to make life easier, but before wrapping up, it’s worth noting how Console API works in browsers vs. how it works in NodeJS stream.

It’s synchronous for browsers, but for NodeJS streams, it’s neither consistently synchronous nor consistently asynchronous like all other Node.js streams. In NodeJS, they internally use process.stdout and process.stderr, and these two streams write synchronous or asynchronous depending on what the stream is connected to and whether the system is Windows or POSIX. The following is the write operation behavior of these two NodeJS process streams:

Files: synchronous on Windows and POSIX
TTYs (Terminals): asynchronous on Windows, synchronous on POSIX
Pipes (and sockets): synchronous on Windows, asynchronous on POSIX

And that’s a wrap!

References:

MDN

NodeJS API Ref

Deep Dive into Front-End Accessibility Issues

Mayank Pathela — Fri, 21 May 2021 06:18:21 +0000

Looking into the complexity of the web-development one of the most common issue that arises in handling big websites is the accessibility issue. Let's deep dive into some common problems and learn how to avoid those.

The term "Accessibility" in front-end context

Accessibility for a web app aims to make it usable by as many people in as many contexts as possible, varying from low to high powered desktop users, and making it sensible for people with disability. We may be not able to achieve 100% of it but can develop a web app keeping our target audience in mind.
Before Jumping into the development it's better to have a User Persona and the limitations they have.

HTML you say? What possibly could go wrong with it?

Most people think that HTML is a piece of cake and underestimates the power it has. There are over 100 HTML5 tags that are supported by modern browsers (Find the whole list here). We don't use all the tags on day to day basis but it might come in handy to use them sometimes which can avoid the excess use of JS in your codebase.

Semantic Issues:
Always use proper HTML tags instead of implementing things just to make things work out the way you want.
Here are some of the key issues I notice very often:

Often use of <br> tag instead of wrapping up their content in the <p> tag.
Multiple <h1> tags on a single webpage. The title inside the <h1> is supposed to reflect the purpose of that very webpage. If you want to highlight any section of the page use different Heading tags and use only a single <h1> tag per page. Have proper signposts in the form of headings to help users find their concerned part of content quickly.
Unstructured Content flow on the Page. Either the CSS is being used or not the content of the page itself should make the sense. If you want to validate that then try disabling the CSS and check if it looks good(you can download Web Developer extension for your browser and Disable CSS). Don't use CSS to control fonts if it can be done by using different HTML tags.
No alt attribute for <img> tag. Always add this property to let the user know what was supposed to be there in case a broken image is loaded because of low network bandwidth.

Apart from semantic issues, there are few things worth noting to make your web page from better to best, Sometimes, users want more keyboard accessibility rather than using a mouse. They just use Tab and Shift + Tab to move around the webpage. So, try to ensure that the flow of the page is going in the right direction and it's easier for a user to navigate around. Always check for cross-browser compatibility of your elements, for example, IE9 behaves differently than most other browsers when a poster attribute is set in the <video> tag. Most browsers interpret the presence of a poster attribute to mean that the specified image is to be displayed until the user chooses to play the video. IE9 will only use the specified poster image in this way if preload="none" is set; otherwise, it will take the first still of the video and display that instead. Also, try using the <track> tag to add subtitles for your video to be understandable by people with disability.

Ah CSS! That's where everything goes wrong

It can be summarized in a simple sentence: Don't Overkill! There's a lot you can do with CSS but it doesn't mean to use it everywhere even when it's not needed. Pouring in the extra animations and transitions can be distracting. As a developer, we may appreciate the work and thought process you have put into it to make it happen but if it's distracting the target audience from focusing on the concerned content then it's of no use. Always keep it simple.
Adding extra colours never helps. Decide on a theme with the minimum set of colours. You are creating a web page, not a colour palate(unless you are). And always check if the different colours are in contrast and make the content more readable. You can use WebAIM to pick colours for better contrast.
On a side note check for cross-browser compatibility for CSS too.

For JS it's complicated

It always adds complexity to a webpage. Always be sure whether to use it or not. Sometimes it hard to decide whether to use repetitive <div> or simply put in a JS snippet. Try to optimize your code as much you can, because low-computation devices might not be able to render that and it's not scalable. There isn't much data you can store on the browser using cookies. Decide for yourself what's important data which user wants to quickly access first when visiting the webpage and compare trade-offs storing it on client-side or server-side.
Nowadays every other website has content dynamically loaded and JS is heavily used to fetch and update the data, to minimize the use of JS for controlling the data try using WAI-ARIA which provides semantics in the form of new HTML attributes. For example, if the content is regularly updated then use the aria-live attribute to decide when to update the data so that the user doesn't miss it depending on its importance. You can set its value to the following:

off: The default. Updates should not be announced
polite: Updates should be announced only if the user is idle
assertive: Updates should be announced to the user as soon as possible

That's a wrap! But there are many more things you can explore and do, and knowing your target audience always ends up creating a better web app.

References:

Tweets as an Image

Mayank Pathela — Mon, 17 Aug 2020 17:32:24 +0000

After GitHub allows us to use README.md to showcase our portfolio on our GitHub profile many cool README generator projects came up, and I thought of adding the latest Tweet of any User will be a nice addition to it, so I started figuring out multiple ways to do so, and developed the project using Canvas, Puppeteer, and Twitter API.

First Version:

How I made it:

I used Puppeteer to open a headless Chrome at the server-side, then I am creating a Canvas over which I will be writing down the Tweet's Text.
I used Tweet API: https://api.twitter.com/1.1/statuses/user_timeline.json?screen_name=, fed in the user's handle and a nice get request will simply deliver the user's activity info. By fetching the last Tweet's id I made another API call and gets a sweet response which I needed.
After getting the response I am simply putting the text response on the canvas I earlier and taking a snapshot of it and sending it back as an Image whenever you request to the API end-point this project provides you with a Twitter handle in the Query part.

API for Version 1:

https://tweets-as-an-image.herokuapp.com/?twitterHandle={your_twitter_handle_here}&count={number_of_tweets_you_want_to_fecth}

Sample Image from Version 1 response:

Since I have the text here, I can do a lot of things, changing fonts, colours, adding designs, borders. But then I ran into a problem. The response I was getting was not a complete text, it was adding ... at the end of the Tweet's text was long. Isn't it a bit weird? As the number of characters is already limited of a Tweet.

So, I started looking for a different way and came across the oEmbed format. It's a simple yet powerful API that allows a website to display embedded content (such as photos or videos) when a user posts a link to that resource, without having to parse the resource directly. And then there was a...

Version 2:

Steps are pretty much similar to Version 1, but here instead of creating a canvas I am feeding in the HTML file to the Puppeteer and taking the snapshot of it. Here's the oEmbed URL for Twitter which I used: https://publish.twitter.com/oembed?url=https://twitter.com/

API for version 2:

https://tweets-as-an-image.herokuapp.com/tweet?twitterHandle={your_twitter_handle}&id={your_tweet_id}&theme={light_or_dark}&maxwidth={max_width_of_your_tweet_image}&height={height_of_the_image}&lang={language}

Sample Image from Version 2 response:

There are many other query params that you can include like language, width, height, etc.

You can find the details for the same along with the steps to deploy your version of this project here in my GitHub repository REAMDE.md.

Also, this one's worth noting that I am keeping the browser open at the top to reduce the response time(it will take time at the first call but the consecutive calls will have less response time):

Since I am using a free version of Heroku Dyno, so it might in sleep mode and you may not get any response on the first try, so please try again after a few minutes when you make your first call. Everything should work fine :)

P.S. Cheers! Keep Learning!

GitHub Profile Stalker

Mayank Pathela — Wed, 20 May 2020 08:02:11 +0000

Finally my first Blog here and a tribute to GitHub Student Developer Pack which helped me throughout my college life by providing awesome helpful resources to enhance my skills and gave me a great learning curve.

In this blog, I will be discussing my GitHub Profile Stalker project in brief and will be more of what I did rather than how I did.

P.S. Feel free to reach me out in case you face a problem in understanding the how part after looking at the code ;)

Click here to check Deployed build

starkblaze01 / git-stalk

Love stalking GitHub Profile. Then try this out!!

git-stalk

Love stalking GitHub Profile? Check what your peers are upto😈

Build

Blog

How to Start the Project

npm i
Create a .env in the root folder and Set Environment Variable: REACT_APP_OAUTH_TOKEN = Your GitHub OAUTH Token
npm start
Note: You can still run the project without setting the environment varibale. It's just to increase Rate Limit

To Create Optimized Build

npm run build

Why I made this?

Because I wanted to explore GitHub API and have fun with it. And also I was inspired by this awesome telegram bot made by Aashutosh Rathi for which he had to pay monthly bill of 1 INR because of me😓.

Special Thanks

GitHub API

Author:

Mayank Pathela - Website

Liked the project? Hit the star button to support!

What to Contribute?

Create an Issue here

View on GitHub

Technologies used in this project: React-ts, Ant Design, GitHub API, JSS, Redux, Netlify, and ....nah, let's keep it to this only.

I love stalking GitHub profiles and check the activity of awesome developers out there. Yep, you got that right, why not simply go to their GitHub profile check that, ...or maybe recreate something of my own which might help me learn something new along the way.
The first thought that came to my mind was to create a scraper to get the desired content, but the profile page on GitHub wouldn't have given me all the information I needed and will need to make multiple calls, and eventually, this would have decreased the performance of the desired application. So, then I thought why not use GitHub API, it might be fun exploring it. Hell yeah! it was! You can do a lot of kinds of stuff using it, automate many things and create many applications around it. Now I have the API end-point which will give me desired data, let's work on displaying the data in some manner that will be less criticised by developers out there.
So, which one's the most famous Frontend technology to use for displaying the data, any guesses? yeah, you guessed it right! it's React(no not you Angular, please be seated. P.S. apologies to Angular lovers)

But why just simply use React, maybe something different this time, so to cover up that different part I used React Typescript.

The majority of the tech industry believes in using ReactTS over ReactJS, but it's a very subjective topic which one's better to use, so let's save this controversy for some other time.

Next up I added a flavour of CSS in JS style. There are many libraries out there: JSS, Styled Components, Emotion, Styled-JSX... I picked JSS for my project and Ant Design for basic UI components. Then simply mix it up, wrap it up in the Redux store for easy state management and your project is ready.
For deploying I prefer Netlify, it's really easy to set up, though I would point of that I forgot to add History API fallback so whenever I was clicking the back button after searching for a User's profile it was throwing Not Found Error for Netlify Deploy but working fine locally, so, I have to add _redirects file in the root of my project folder and the problem solved.

That's all folks, and if you are in college go grab your GitHub Student Developer Pack and learn about these awesome technologies with the subscriptions that you can claim along with it.

Cheers! Keep Learning!