Forem: Aditya Tyagi

Logical CSS: Padding And Margins In Multi-lingual Web-Apps

Aditya Tyagi — Fri, 14 Apr 2023 11:02:21 +0000

There are two modules of CSS properties — Logical and Physical. If you are working on a multi-lingual web-app, then logical CSS properties will come real handy.

Physical properties refer to the physical aspects of the viewports — height/width of the viewport.

On the other hand, logical CSS properties works according to the flow of content. The values of such properties change with the change of:

The Need For Logical CSS

Consider this example of a button with an icon on the left. Sample button with an icon and a margin between the icon and button text is shown below.

All is good till we are dealing with languages that are left-to-right. With languages like Arabic/Hebrew, which are right-to-left, the button will look something like this (Button with language right-to-left):

Here, the icon has the margin on the wrong side. If you want to check, you can use the dir attribute for <p> tag to change the writing direction.

<button dir="rtl">  
    <svg></svg>  
    <span>Sample Button</span>  
</button>

To fix this, in addition to providing automatic support for internationalization, and creating a more robust front-end, we have CSS Logical Properties.

Defination

CSS Logical Properties and Values is a module of CSS introducing logical properties and values that provide the ability to control layout through logical, rather than physical, direction and dimension mappings.

The module also defines logical properties and values for properties previously defined in CSS 2.1. Logical properties define direction‐relative equivalents of their corresponding physical properties.

- MDN Web Docs

The thing to note in the above detailed (also verbose) defination is: Logical properties define direction‐relative equivalents of their corresponding physical properties.

Some of the Logical CSS properties are:

margin-block
margin-block-start
margin-block-end
margin-inline
margin-inline-start
margin-inline-end

The above combination exists for padding too. To go through a complete list of these Logical CSS properties, explore here.

Physical CSS Properties: Rewind

If you are fimiliar with the workings and short-hands for margin and padding , then you know that the values go clockwise. For example:

margin: 1px 2px 3px 4px;

sets position 1, 2, 3 and 4 in clock-wise direction.

Clockswise positions to explain shorthands for margin and padding

Understanding The Basics Of Logical CSS Properties

For this, we’ll consider going over the 4 basic properties:

padding-inline and padding-block
margin-inline and margin-block

The margin and padding here are “flow relative” and not “direction relative”. This means, historically when we appliedmargin-top to a block, it added margin-top according to the physical aspect of the viewport — irrespective of the language direction/writing-mode. This causes an issue like:

But what should actually happen when the direction or writing-mode changes:

Understanding Block Flow

The block flow is the direction in which the next “block” element will be placed. For example, if there are two <div> tags, so where the adjacent <div> will be placed is determined by the block flow.

Understanding Inline Flow

The inline flow is the direction in which the next “inline” element will be placed. i.e. how the words flow in a sentence. For example, if there are two <span> tags, so where the adjacent <span> will be placed is determined by the inline flow.

With logical properties, margin-top becomes margin-block-start , irrespective of the writing mode or direction. This helps to create a more inclusive front-end and hence the block flow has appropriate margins.

Box Model for Logical CSS Properties

Image Credits: Box-model for logical CSS properties:

Smart readers must have accounted for similarities with inline as well:

text-align: right; becomes text-align:end

This helps us to align the text on the basis of “reading direction” and not to the physical right of the viewport.

For direction: ltr and text-align: end

For direction:rtl and and text-align: end

Support

The properties having a suffix of start and end (margin-block-start and margin-block-end) have strong compatibility and are a good choice for desktop and mobile both. But the properties which lack the suffix like margin-block and margin-inline are good for desktop but not for mobile.

You can explore CANIUSE.COM to check complete support.

Thanks for reading ❤

Want to connect?

Follow me on Twitter and LinkedIn or reach out in the comments below!

Code Reviews Should Not Suck!

Aditya Tyagi — Thu, 21 Jul 2022 07:10:50 +0000

How to raise a pull request (PR) as a beginner

Code Reviews are one of the major things that a developer has to do on a daily basis. For some, the experience of reviewing code can be delightful but for others it can be quite stressful!

According to Stack Overflow, the number one cause of stress in a developer’s life is code reviews.

- Just Kidding!

Code reviews or Pull Requests (PR) reviews is the process of collaborating on a piece of code to:

Approve changes
Request changes
Comment on the changes

The process is important to ensure a healthy codebase. Without a formal PR review process, you’ll end up with a pandora box of surprises! Sometimes these surprises makes to production!

There are certain things that make the PR reviewing process difficult. Let’s go into detail about some prominent issues and how to avoid them.

No Clear Reviewer or Assignee or Title

Whenever you receive a PR to review and there is no assignee/reviewer added, it becomes difficult to track all the updates and changes to the PR. Therefore before opening a PR, always add details of the reviewer and assignee.

Check out the official docs to understand how to add reviewer and assignee to your PR.

Ensure the title of your PR is self-explanatory as this will appear in git history when the PR is merged. Do not add vague and gibberish things that make sense to you, but not others!

Delayed Reviews

Everybody is busy with their work. Understandable. But we need to understand our position when we are a reviewer for a PR. The assignee might be waiting for a review/go-ahead on a PR so that they can continue with their work.

In bigger teams, it is often seen that PRs are in review for far too long. Not hours, but days. Teams must come to a Service Level Agreement (SLA) for reviewing PRs. This is the time elapsed between a PR is raised and it is reviewed. For some it can be 1 hour, but for other it can be 5. This sets the right expectations for all stakeholders.

One of the major tools that I am a fan of is Slack Reminders. You can set alerts for all your PRs and it will send little reminders on a slack channel. You can read more about it here: Managing scheduled reminders for your team.

Missing Details — Pull Request Templates

In this remote-first world, the conversations and the work happen asynchronously. Thus, it is highly possible that the reviewer of your PR is sitting in a different time-zone.

Now, if your PR has inadequate information, then the PR review will get delayed by minimum 24 hours. Hence, your PR needs to have all the necessary information.

If you are confused and do not know what a PR template should entail, check this little take on pull requests:

Bad pull requests are unclear. They don’t have clear answers to “why are we doing this?” and “why are we doing it like this?”. They are usually unreasonable in size and include multiple changes to multiple subsystems. The reader is typically unsure if the pull request is mergeable, nor does he have any metric to help answer this question.

- Igor Šarčević

By “necessary information” I mean all the details the reviewer of the PR will need to test out the PR. This can be:

Module for which the PR makes changes to
Some background — Why and How
JIRA Ticket attached to the PR
Necessary testing steps
Any specific environment changes the reviewer should do to review the PR

It is difficult and an unrealistic expectation to have from developers adding these details every-time they raise a PR. Hence, use another feature — PR Templates.

Pull Request Templates are helpful in reminding developers to fill the necessary details before submitting the PR. It can be as simple as having a reminder to “self-review” the PR and as complex as adding an .env file and testing steps.

This small template can save you hours of back-and-forth with the assignee of the PR and hence speed up the process. To see how it changes the whole experience of PR reviewing, I have filled a PR template below.

See how easy it becomes to review the PR now. At least, start with the review.

Repeated/Skipped/Ignored Reviews

This happens majorly with the developers who have just joined the workforce and hence tend to repeat the same mistakes they have already been pointed out. This makes PR reviewing a task and a bad one!

So, if you are a newbie and are getting review fixes around best practices or logic in one of your PRs, please ensure the subsequent PRs do not have the same mistakes. This point can be eliminated by a simple but thorough self-review.

The other side of this is when the reviewer gave you a substantial number of reviews and you skip them. Skipping them is still an honest mistake, but if you ignored it on purpose, that is just not acceptable. You need to understand and acknowledge the amount of time and hard-work the reviewer has invested. The reviewer wants to learn. Ignoring the ones you think are not substantial is just not cool!

The remedy to this is having an “acknowledgement system” for all the reviews. Whenever you fix the PR reviews and comments given, just leave a 👍 (thumbs-up emoji) or “Done” on that conversation. It won’t take more than a minute, but will go a long way in this two-way communication.

Singleton Purpose Of The Pull Request

One of the thumb rules that you have to follow is not to cover too many fixes and random things in a single pull request. Keep the work in the PR scoped to what the PR was intended for.

There are times when the perfectionist developer with ADHD in you cannot stand code smells. Just because it’s a minor fix, you try to squeeze those fixes in your PR too. Yes, you did a great job, but that was not the job you were given. The PR should be precise.

These little things (a.k.a habits) do improve the code base but at the cost of increased time of PR reviews. You can inform your reviewer about these code-smells. Do not increase the scope of the PR unnecessarily.

No PR Should Be More Than 400 Lines Of Code — Scientifically Backed

There are companies who instantly reject PRs if it has more than 500 lines of code. Igor Šarčević very beautifully puts this point across with his take on Pull Requests are a reflection of your engineering culture.

The longer we stare at something, the more blind to it we become. After an hour of looking at the same thing our brain becomes saturated and less effective at spotting issues.

Based on this data and the finding that review efficiency falls after 90 minutes, they concluded that a reviewer will be most effective reviewing no more than 400 lines of code in one go.

- Proof your thousand-line pull requests result in more bugs

Yes, there can be instances where you would not be able to follow this cardinal rule of 400 lines of code. But believe me, you can. Proof your thousand-line pull requests result in more bugs post underlines the ways we can spilt the PR with more than 400 lines of code and still not break the PRs.

In brief:

Separate out refactoring
Lay out the foundation of PR in 1 part
Use feature flags
Commit by portion of code and not based on time is another analogy by Pauline Vos in her talk Git Legit (Atomic commits will help you git legit). If you are interested in reading more on Atomic Commits, check this out.

Mind Your Tone Of Writing

Be polite. Be respectful. Be mindful. Everyone is learning here and everyone commits mistakes (pun intended). Hence, mind your tone of writing while you are giving out reviews or you are replying on the given review.

DO NOT USE ALL CAPS to show you are frustrated and are shouting (imaginary)

Give compliments wherever it’s due.

Thank your reviewer once a long PR is getting merged after 3–4 back and forth. Thank the reviewer if you have learnt anything new.

Thanks for reading ❤

If this blog was able to bring value, please follow me here! Your support keeps me driven!

Originally published on adityatyagi.com

Want to connect?
Follow me on Twitter and LinkedIn or reach out in the comments below!

Responsive Font-Sizes In React Apps

Aditya Tyagi — Sun, 03 Jul 2022 08:05:33 +0000

Best CSS practice to ensure consistent styling in web applications

We live in a mobile-first world and hence as a front-end developer it is our job to ensure that the web-apps we are building are mobile-friendly. With the rise of hybrid frameworks, things that are developed for web are easily translated to Android and iOS applications.

This shift in the development community has not only reduced the cost of shipping products but has also increased the speed at which these products are being shipped. Having responsive apps thus becomes far more important today. There are a ton of ways to style your react apps but for making your web apps responsive, you need to have your fundamentals clear!

Pre-requisite to understanding responsive layouts

Copy-pasting this little hack will serve the purpose but that is not how true developers work, and if you are reading this, I know you are are legit developer! So, please understand the underlying principles first and then implement it.

With this little hack, you can ensure consistent:

Spacing
Fonts
Image sizes

across your web app. This one little hack will require you to use a CSS pre-processor like SCSS or SASS.

As a pre-requisite, you need to understand relative CSS length units

px
em
rem
vh / vw
vmin / vmax

Relative length units are relative to something else, perhaps the size of the parent element’s font, or the size of the viewport. The benefit of using relative units is that with some careful planning you can make it so the size of text or other elements scales relative to everything else on the page.

- MDN Web Docs

There are 18 relative CSS length units and you can read about them here. But for this little hack, all we need to understand rem .

CSS REM — What is REM in CSS?

Any CSS value that is measured in rem is measured relative to font-size of the root element.

TLDR: Using rem and em units is better than using px.

rem stands for root em and it means “root element’s font size”. As web developers we need to understand that our apps will be used by all types of users — young, old, specially abled, and thus we need to take care of accessibility. rem helps us to maintain that accessibility.

Why not px ? The disadvantage with using px with everything like padding, margin and font-sizes is that the UI does not scale proportionately. This is where rem shines. It helps the UI to scale proportionately.

The root font-size is 16px. So, when we encounter a value of 1rem , we mean 16px

When to use `rem` and when to use other relative CSS units?

I personally use rem for font-sizes and em for margin and padding . You care read more about it here.

There are solid reasons to use rem and not em for font-sizes. While re-searching about this blog post (yes, I do my homework!), I came across this very detailed analysis on rem on font-sizes. Please go through it once and thank me later!

Use Rems for Font Size to Respect User Preferences by Aleksandr

How To Use REM In CSS

There are multiple ways to use rem in your front-end applications. This is not something specific to React. You can use it with any web-applications.

Some of them, from the same article above are:

Work out the math by hand (e.g., 24 / 16 = 1.5rem).
Use a CSS calc expression (e.g., calc(1rem * 24 / 16)).
Use a CSS preprocessor like Sass and write a custom to-rems utility function.
Use the 62.5% font size trick to make the math easier.

Here, we’ll be discussing the third in the list i.e Use a CSS preprocessor like Sass and write a custom to-rems utility function.

As I have already pointed out that we need to use a CSS preprocessor for this. I am going with SASS.

This is a utility function wherein you just pass the value in px and the function returns the rem equivalent.

Consider this situation:

You are working with a UI/UX designer and the designer provides you with a Figma file. Your job is to convert Figma designs in front-end code, but in a responsive manner. Now the font-size values can vary for different designs and screens and hence you cannot have a pre-determined CSS variables. This is where the CSS utility method pxToRem will come handy!

You can use this function like this:

Need for a utility function

Getting rem values for px values like 16px, 32px, 8px is easy for a root font-size of 16px. It will be 1rem, 2rem, 0.5rem.

But what if we want to capture font-size values of 15px, 35px, 7px? I certainly cannot divide 15/16 and come to a floating value with proper rounding off at a moments notice. But it might be easy for you. So, kudos to the “genius” in you!

Not everyone is a genius like you! I certainly am not!

Now, for dumb people like me who are not math wizards and are able to do the calculation on the fly, we need a simple utility function.

But for a math wizard/genius like you, all you need to do is divide the value in px you want to convert in rem by the root font-size.

So, if the root font-size is 16px then the utility function can give back rem values pretty easily. All we have to pass is the font-size values from the Figma designs.

Why Not To Use EM For Font-Sizes in CSS?

I’d like to cover this part as well so that you can appear smart in-front of your peers when they attack you with this questions!

So, em calculates the value relative to its parent element with an explicit font-size Therefore it will take the relative value from it’s closest common ancestor with any explicit font size value. So even if it’s container or container’s container had an explicit font size set, it will use that value

- A very thoughtful comment

Let me show via an example, where things can go south when using em for font-sizes:

Now we give a font-size to the parent element. The child element will consider parent’s i.e closest common ancestor with an explicit font size value as its base for the calculation of rem

But, this can create an issue as you can see here. Different parent elements can have different explicit values for font-sizes and hence it will lead to different results for the same 0.5em values in children elements.

The issue becomes even more serious with nesting:

If we give font-size to parent and sub-parent , the child will get the nested value in terms of em

Hence, we cannot use em for font-sizes.

Other ways to use REM in CSS for responsive web apps

The above is just one of the ways to use rem for your web applications. There are other ways as well. Please feel free to explore them here.

The 62.5% Font Size Trick
Work out the math by hand (e.g., 24 / 16 = 1.5rem).
Use a CSS calc expression (e.g., calc(1rem * 24 / 16)).

Thanks for reading ❤

If this blog was able to bring value, please follow me here! Your support keeps me driven!

Originally published on adityatyagi.com

Want to connect?
Follow me on Twitter and LinkedIn or reach out in the comments below!

Everyday GIT

Aditya Tyagi — Thu, 30 Jun 2022 10:18:22 +0000

Might not be for you, but might be exactly what you need!

Not another git cheatsheet you say?? There are a ton of git cheatsheets already there are it is highly unlikely that i’ll ever refer to a cheat sheet when I can just google that sh** in 5 min and go through 5 Stack Overflow answers. Copy-paste random things until something works!

Why another Git Cheatsheet?

I beg to differ. I say this because most of the git cheat-sheets out there are very generic and have commands that I will rarely use. In my 4 years of dev career, which is pretty small as compared to some of the veterans out there, but still have managed to narrow down to the following git commands.

These are the commands that I use daily, almost. Some of these are the ones that come handy when I f*** up and f*** up bad. Some of these are just because I am too lazy to type.

Why a blog? Why a publicly available blog?

This is majorly a self-note blog post. A reference point for me. No matter where I am, and irrespective of the organisation I am working for, this blog post will the go-to point.

What’s in it for you?

Nothing special but everything you want. To be honest, bookmark it, or ignore it if you feel it’s too much. But the following are the commands that I have used and I am positive that I’ll be using it more!

Useful GIT resources

Find the complete table here

ReadMe and Markdown

ReadMe and Markdown Cheatsheet

Git Alias

Git Alias are nothing but git shortcuts. For example:

cp = cherry-pick
st = status -s
cl = clone
ci = commit
co = checkout
br = branch
diff = diff --word-diff
dc = diff --cached

A progammer uses simple commands like fetch, pull, merge, rebase, push on a daily basis and like a 1000 times. There are commands that are simple, yet verbose to type. Git Alias helps to create shortcuts for these git scripts.

You can add alias one at a time:

$ git config --global alias.co checkout
$ git config --global alias.br branch
$ git config --global alias.ci commit
$ git config --global alias.st status

or you can add all at once. To setup git alias, we need to edit the .gitconfig file and add the aliases there. The path of this file can vary depending on the operating system you are working on.

Generally,

MacOS: ~/.gitconfig
Linux: ~/.gitconfig
Windows: It can be different based on system settings. A starting point

To quickly open, try running git config --global --edit in terminal and it is highly possible that it will open in your default editor.

There are literally a ton of aliases that you can use and what works for me, might not work for you. Thus, will drop few links here where in you can select the aliases that works for you.

Must Have Git Aliases: Advanced Examples by Nicola Paolucci
Sample .gitconfig file: Check here or here

The most powerful feature of git alias is positional parameters. Positional parameters, in simple words are the values to your alias functions. Yes, functions.

my_alias = "!f() { 〈your complex command〉 }; f"

You can write alias functions that take arguments (just like normal functions) and run the script with them. The only thing you have to take care of is the order in which you pass parameters while invoking alias.

$1 to mean the first parameter passed to the command.
$2 to mean the second parameter passed to the command. (and so on for $3, $4, etc.)

For example, if you want to delete branch locally and remotely but don’t want to remember the long git script

git branch -d localBranchName && git push origin --delete remoteBranchName

You can create a git alias function

delAll = "!f() { \
         git branch -D $1 && git push origin --delete $1; \
       }; f"

Now, all you have to do is pass the branch name you want to delete locally and on remote. You can fire this beauty by:

git delall mybranchName

Multiple Git SSH accounts

Specifying the SSH key to use

Special Mentions

Conventional Commits: A specification for adding human and machine readable meaning to commit messages

Thanks for reading ❤

If this blog was able to bring value, please follow me here! Your support keeps me driven!

Originally published on adityatyagi.com

Want to connect?
Follow me on Twitter and LinkedIn or reach out in the comments below!

Why NextJs should not be ignored.

Aditya Tyagi — Wed, 29 Jun 2022 06:33:59 +0000

A brief introduction to a full-stack framework backed with React syntax

The NextJs official website’s landing page terms NextJs as “The React Framework for Production”. It is by Vercel. I encountered NextJs while I was pursuing to become a full-stack developer with 4+ years of hands-on experience in front-end web technologies.

NextJs is a layer on top of React extending its capabilities. React does not need NextJs, but NextJs needs React. Therefore, to be good at NextJs, one needs to go through React concepts! React is a Javascript library while NextJs is a React framework.

TLDR: I was blown away with the number of features NextJs comes right out-of-the-box!

Some of the features that you might like are:

Server-side rendering (SSR)
Static site generation (SSG)
API routes
Built-in Image optimization
Automatic code splitting by route
Dynamic Static Regeneration
Server components (experimental)
Automatic link prefetching
Built-in head/meta tag component
Built-in scroll restoration
Middleware support

This is indeed a long list of features that you might/might-not know about, but I can guarantee you that once you are well versed with each of these, it will be hard for you to ignore NextJs.

Products using NextJs

You won’t believe what all products have already switched to this beast. Let me list a few down here, but for a more exhaustive list and to have your jaw dropped, check this out!

TikTok
Hulu
Nike
AT&T
GoPro

If the data is not changing multiple times every single second, then it is a contender for NextJs. NextJs can be used for the use-cases such as:

Landing pages
Small static websites
Marketing websites
E-commerce websites

Comparison with other frameworks

The official website gives a catchy intro as:

Next.js gives you the best developer experience with all the features you need for production: hybrid static & server rendering, TypeScript support, smart bundling, route pre-fetching, and more. No config needed.

- NextJs

The best part of diving into NextJs (as a seasoned ReactJs developer) is that the syntax and the underlying principles are same (almost). The learning curve is not steep and one can grab the basics in a couple of days.

The JS world is ever-so-growing and one can find it overwhelming just to keep up with the number of frameworks and new stuff coming out! This makes our job, as front-end developers even more complicated as we need to take decisions by weighing the pros-and-cons of frameworks!

A framework comparison matrix by reactjsconsulting.com

As you can see above, NextJs checks most of the boxes in comparison with other frameworks!

Cory House

@housecor

Here are 7 ways to create a React app in 2022. This feature matrix shows some key differences at a glance.

List includes:
@vite_js
@nextjs
@remix_run
@GatsbyJS
@RedwoodJS
@ShopifyDevs Hydrogen

#react

16:24 PM - 20 Jun 2022

A tweet thread by Cory House for comparing frameworks

I’ll go through some of the features of NextJs in brief to give you an idea of what’s in store for you if you give NextJs a shot! I will not go into detail in this post as I am planning to cover topics from NextJs in detail in my upcoming blog posts!

Developer Experience & Community

I have created a project in NextJs and have developed multiple enterprise level React projects. There are certain things that I liked about NextJs and on some I’ll pick React. But to be very honest, they both have great documentations. The developer experience is not taking a hit and one compliments the other.

The speed of coding and the ease of coding — both are great! NextJs has gained popularity in the last couple of months, if not years and has seen a very closely knit community!

Join the discord community for NextJs here with 40,356 members. The community is active and helpful. NextJs also boasts some great GitHub stats as well:

Forks: 18.9K
Stars: 88.4K
Commits: 11.5K
Contributors: 2K

Community:

Discord
Reactiflux on Discord — has a NextJs channel
Reddit

You can read the developer experience in detail here.

Performance

Web apps built using NextJs are extremely fast because the pages are already pre-rendered on the server before reaching the client. This is the underlying principle for Static Site Generation (SSG) or Server Side Rendering (SSR) — both features of NextJs.

In SSG, the page is generated during build-time and not when the client requests for it. This static page is then re-used for every incoming requests from a static server like CDN (Content Delivery Network) making your apps super-fast!

The main difference is in the underlying architecture. NextJs runs on server while React apps like Create-React-App (CRA) runs on client’s browsers. This burdens the client-side to not only download heavy bundles but also render them using the complete V8 engine (Chrome’s JS Engine) as all that downloaded code is NodeJs code.

One thumb-rule to always keep in mind is that HTML is faster than JavaScript!

The performance of the apps also shoots because of multiple in-built features like Image Optimization where the images are pre-processed in the best formats for web apps i.e WebP.

SSR on the other hand is responsible for data-fetching and rendering at request time.

Better Search Engine Optimization

React apps are Single Page Applications or SPA. They are by nature bad at Search Engine Optimization or SEO. NextJs introduces Server Side Rendering or SSR. SSR is preparing the content of the web page on the server and not on the client.

The SSR is SEO friendly. SPA’s in general are not SEO friendly. This is because SPAs are hard to crawl by Googlebot and hence is difficult to render content for SEO purposes. A study has proven that the new SPA’s are not being crawled by search engines like Google properly.

The SPA’s take some time to print the content on the page, but by then the Googlebot (Google’s SEO crawler) is already done with its work. You can read more about SEO in SPAs here.

What happens when you use React without server-side rendering is that the crawler halts on the very first page because it can’t see any hyperlinks to follow. It sends the page to the indexer, which then has to render the page and extracts the hyperlinks, which will then be added to the crawler’s queue. Then the crawler will eventually crawl the next set of pages, and again will stop there because all the links are invisible until the JavaScript is rendered. So it has to wait for the indexer to come back with a new set of URLs to crawl. Etc.

It makes the crawl process incredibly slow and inefficient. And that is why websites built on React (and similar JavaScript platforms) perform worse in Google than websites that primarily serve plain HTML to the crawler. The latter type of website will be crawled much more efficiently; plain HTML websites can be crawled very efficiently, newly added and changed content will be crawled and indexed much quicker, and Google is much better able to evaluate the crawl priority of individual pages on such websites.

-

in SEO vs. React: Web Crawlers are Smarter Than You Think

When the app is not an SSR app, the search engine crawler just sees the root <div> where the app will be rendered once the JS is downloaded by the browser. Then it has to show a loading state by the time API hit is in progress and is getting the data. This adds to the delay on the user side.

In SSR, the page is completely ready to be shown on the front-end from the go! It allows us to pre-render React pages and components on a server.

You can do it on the client side using ReactServerDOM. It can be done in ReactJS as well, but it requires additional effort and is a bit complex to get it going. On the other hand, NextJs has it in-built. Automatic page re-rendering is something that is great for SEO and initial load.

The search engine sees what are users looking at when SSR is in place. This is not the case when an application is created using ReactJs only. Because of SSR, the users have a better user experience (UX) as there are no flickering or loading states. It blends client-side to server side. Fetch data on the server and render finished pages.

File Based Routing in NextJs

NextJS defines pages and routes with files and folders instead of code.

In React, we have to use an external routing library (react-router-dom) to implement “in-page” routing. For every route added to the list, we have a corresponding page too.

Routing in ReactJs

In NextJs, you have a dedicated folder pages and inside that the order of the files and folders defines the routing of the NextJs app. The structure of the pages folder defines the paths and routes the app supports. It is less code, less work, and highly understandable. It mimics the way we had old static sites (index.html/about.html/contact.html)

Routing in NextJs apps

As you can see, the “pages” folder has a sub-folder “news”. The news folder has “index.js” file and a [newsId].js file.

For routing:

index.js will create a route /news

[newsId].js will create a route /news/:newsId where newsId is the route parameter.

A nested folder structure basically means nested routes.

Configurations for NextJs

React recommends using Create-React-App or CRA for its projects, but there are certain things that are not required out-of-the-box for small-scale React apps. NextJs is a bit opinionated and helps developers work a certain way.

React doesn’t offer great configurability, unless you eject the app from CRA. On the other hand, everything is configurable in NextJs.

Full Stack Capabilities of NextJs

Below are some of the capabilities added to your project when you choose to go with NextJs:

Can add backend (server-side) code to Next/React apps
Storing data, getting data, authentication etc. can be added to your NextJs project
No different REST api project. One project can have both.
If we see the app that is created by the NextJs CLI command, it does not gives us index.jsfile, as SSR is in-built. NextJS allows us to determine WHEN a page should be pre-rendered.

You can learn more about why you should not ignore NextJs here:

Why I Don’t Use React JS Anymore! React JS vs Next JS by Codedamn

Thanks for reading ❤

If this blog was able to bring value, please follow me here! Your support keeps me driven!

Originally published on adityatyagi.com

Want to connect?
Follow me on Twitter and LinkedIn or reach out in the comments below!

My name is Aditya. I am a Senior Software Engineer - II (Frontend). I blog about web development!

How to debug a React App

Aditya Tyagi — Mon, 27 Jun 2022 05:49:19 +0000

Debug React apps like a pro!

While working as a front-end developer for last 4+ years, one thing I have witnessed junior developers constantly struggle with is proper debugging skills. I believe debugging is a skill and developers who are good at it can bring immense value. As with any other skill, one can learn debugging. All one needs to understand the tools at one’s disposal to debug React app.

This little handy guide is not only about debugging React apps, but any JavaScript based app. Some principles here are generic to programming while the others are targeted towards debugging JavaScript applications.

Re-read the error messages

Old lady reading meme

Debugging is no rocket science. Sometimes developers just panic and what could have been resolved within 5 minutes, take 30. I say this because I have spent 30 minutes.

The maintainers of programming language, library and frameworks have worked hard to make error messages self explanatory. Therefore, when you debug, the very first step is to read the error message and then re-read it.

I want to lay emphasis on re-reading the error message because usually the solution is screaming at you. Skimming through the error message is not what you should do. Read it. Slowly. Understand it and then move forward.

The error message lays out the entire call-stack. How the error bubbled up and at which line number the error was thrown, everything is out there. Going through the error call-stack will help you analyze the code flow and warnings. Reading and making sense of the error call-stack is an essential skill a developer must work on as it can help one work with legacy code-bases which are an amalgamation of hundreds of files and thousands of lines of code!

For example, if we have a button element which calls a function showAlert but we forget to define such a function, the app will throw an error.

React is kind enough to show the error at two places:

The dev-tools

The console of the dev-tools of all the browsers will show this error.

React throwing error in dev-tools console

The web page

React ensures that the error is more human readable on the web-page. You can clearly see below where the error was thrown and hence this will be the starting point to debug React app.

React error message on the web-page

I cannot stress enough on how important it is to read and then re-read the error message. You need to understand it completely before you even start exploring Stack Overflow and Google.

One thing that I have experienced is that Google is pretty good at its job as a search engine. It will give you back the results for the question you asked. Now if you have mis-understood the error and are trying to ask Google wrong questions, it will give you answers which will take you down the rabbit hole of copy-pasting different solutions until something works!

Learn to use your IDE

Queen Elizabeth II insists on cutting cake with a sword at G7 event

Today, Integrated Development Environments (IDE) are very powerful. They hint you what’s wrong right in your code, even before you Save it. Not understanding the tools you have slows you down and makes you inefficient at your job. Understanding how your IDE works is so important that programmers and content creators out there have created full fledged courses on the very topic. Some of my favourites around VS Code are:

You can use VS Code extensions/plugins for effective debugging as well. For JavaScript, plugins like ESLint by Microsoft are a must. If you want your project to ship with an ES Lint, then you can do that as well by using a NPM library.

If you find yourself relying too much on plugins and external NPM libraries, please remember this:

To a man with a hammer, everything looks like a nail.

– Mark Twain

React apps with proper ESLinting and IDE, will even fail to compile, eventually throwing the error in the terminal:

React app failing to compile due to undefined variable

Working with Breakpoints

This is one of the most helpful and yet one of the most under-utilized piece of debugging tool developers use. In software development, a breakpoint is an intentional stopping or pausing place in a program which is added to debug the code. One can work with breakpoints in multiple ways, but the two most prominent are:

Breakpoints via Dev Tools in the browser
Using the debugger in the IDE like VSCode

Breakpoints via Dev Tools in the browser

Open the Chrome dev tools. I am using Google Chrome as my primary browser, but dev tools are present in all browsers. Go to Sources. Go to the Page tab and the localhost:3000 dropdown. There you’ll see all your files and you can add debuggers to your JS files right then and there.

Location of all the files of your app in dev tools

Here, I’ll be adding a breakpoint on the testDebugger function, just before it consoles the value of the variable a. As soon as you click the button, it will stop the execution of the app on the very breakpoint. You can then use the panel of buttons on the top-right corner (in Red box) to move around the function.

For a more detailed tutorial, you can refer Debugging JavaScript — Chrome DevTools 101.

If you look closely below, you’ll be able to see all the breakpoints, the call stack and the file on the left panel.

Debugger in Chrome Dev Tools to debug React app

Using the debugger in the IDE like VSCode

Today the IDEs come with in-built debuggers. You do not have to rely on the dev tools in the browser. The workings of the VSCode debugger is similar to debugger in dev tools. To understand it, you can refer the following two resources:

This is how the debugger will look like in the VSCode:

Yellow: Debugger
Blue: The breakpoint
Pink: List of all breakpoints
Red: Variables

VSCode Debugger in action

React Developer Tools

React Developer Tools is a browser extension that helps to debug React apps. It is present in other browsers as well, but I’ll recommend you to get comfortable with the Chrome extension. This extension makes the process to debug React app easy and consistent!

From the official docs:

React Developer Tools is a Chrome DevTools extension for the open-source React JavaScript library. It allows you to inspect the React component hierarchies in the Chrome Developer Tools.

– React Developer Tools (Chrome Web Store)

Once you enable this extension, you’ll see two new additions to your dev tools:

Components
Profiler

The Components will show only React components and not the entire DOM like the Elements tab shows.

Demo of React Dev Tools chrome extension

You can learn here with examples:

Reach out for help!

Baby Yoda Meme

Sometimes the error message is cryptic or we cannot make sense of it. Even after struggling to find a working solution, trying everything from Stack Overflow and doubting your entire life, you aren’t able to debug. In such cases, pause. Take a deep breath and ask for help!

If you are a junior developer working in a company, then reach out to the senior developers. Sometimes all you need is a fresh perspective to the whole situation. If you are a self-taught developer and are building something all by yourself (kudos to you!), reach out to the very welcoming developer community on Twitter and Discord. The community, combined with this one skill can help you debug any bug!

Few developers know, the programming community on Discord is amazing! All you have to do is ask the relevant question in the relevant channel and you’ll get the solution. If not, the solution, there will be 1 kind soul to help you move forward with your quest to debug React app.

Some of the Discord communities I follow:

If you are still stuck, call it a day. Sleep on it and tackle it with a fresh mind the next day. You’ll be surprised how often the answers are just in front of us.

Thank you for your time. I hope I was able to bring value.

I’m reachable on some social media channels, so consider checking me on:

Twitter especially if you’re into programming and software development in general.
LinkedIn if you want to get in touch for some collaboration opportunity.

4+ years of cracking technical interviews

Aditya Tyagi — Fri, 24 Jun 2022 15:06:32 +0000

A framework to solve any technical interview question

I have been working as a Senior Software Engineer — II (Frontend) from quite some time now and have been on both sides of the interview table. I have given a lot of technical interviews and have taken the same amount (if not more).

From white-boarding the data structures and algorithmic questions to pair-programming with my interviewer, its been an eye-opening & humbling experience of how draining these interviews can get!

Therefore, over these last 4 years, I have come up with this little framework that has helped me crack multiple roles in various tech companies.

There are 5 major parts to this problem solving approach

Understand the problem
Explore concrete examples
Break it down
Solve or Simplify
Look back and refactor

Let’s go through each one of them in detail:

Understand The Problem

As soon as you are given the question, do not start slapping the keyboard and declaring variables. Breathe. Read the question and then re-read it.

“It is foolish to answer a question that you do not understand.”

- “How to Solve it” by George Polya

Then, try to note down answers to the following questions:

Can I restate the problem in my own words?
What are the inputs that go into the problem? This is the place where you can ask the interviewer for the edge cases with respect to inputs.
What are the outputs that should come from the solution to the problem?
Can the outputs be determined from the inputs? In other words, do I have enough information to solve the problem?
How should I label the important pieces of data (variables declaration) that are part of the problem?

Explore Concrete Examples

Coming up with examples can help you understand the problem better. These examples also provide sanity checks that your solution works the way it should work.

This can help you to understand the nature of inputs and outputs more clearly and reveal any corner/edge cases.

These are nothing but user stories or unit tests for the problem statements.

For example, consider this question:

Write a function charCount which takes a string and returns count of each character in the string?

The examples of this can be:

charCount("aaa");        // Output -> {a:3}
charCount("hello");      // Output -> {h:1, e: 1, l: 2, o: 1}

// Check examples for empty inputs
charCount(""); // Output -> { }

// Check examples for invalid inputs
charCount(1234);         // Output -> { } 

// Check examples for invalid inputs
charCount(false);        // Output -> { }

Break It Down

This is one of the most important, yet most ignored/skipped step. You need to keep the interviewer on the same page throughout your problem solving journey.

Communicate while breaking the problem down
Ask questions like “Does this sound good?” or “Am I going the right path?”
Write comments and not the actual code.
Explicitly write out the steps you need to take. You need to just write the pseudo-code or steps that you will be taking to solve the problem.

The process of breaking down the problem compels you to think about the code you will write before you write it and helps you catch any lingering conceptual issues or misunderstandings. This is an important step to follow and will help you immensely before you dive in and have to worry about the details like syntax of the code.

Solve or Simplify

By the time you arrive at this step, you should already have the pseudo-code written. All you have to do is just write the code now.

Defeat Them in Detail: The Divide and Conquer Strategy.

Look at the parts and determine how to control the individual parts, create dissension and leverage it.

- Robert Greene

If you are “stuck” and are not able to proceed, do not worry. Try to break down the problem into smaller problems. Try to identify a simpler problem and then solve it. This will also give you a psychological sense of achievement and thus help you proceed with the problem “emotionally”.

Yes, emotionally. There have been times when I started sweating, mouth went dry while solving a DSA question. One has to be in a balanced mental state to come down to a solution as this is a mental game!

To simplify:

Find the core difficulty in what you are trying to do
Temporarily ignore the difficulty
Write a simplified solution
Then incorporate that difficulty back in

Look Back And Refactor

This is the last piece, but the piece of this framework that will distinguish between a great candidate from a good one!

For refactoring, ask yourself:

Can I check the result?
Can I derive the result differently?
Can I understand the solution at a glance? Is the solution readable?
Can I use the same method for some other problem?
Can I improve the performance of the solution?
Can I think of other ways to refactor?
How have other people solved the same problem? This is something that comes in “Looking Back” area of the framework!

All the very best for your interview (if you have any coming up).

Thanks for reading ❤

If this blog was able to bring value, please follow me on Medium! Your support keeps me driven!

Originally published on adityatyagi.com

Want to connect?

Follow me on Twitter and LinkedIn or reach out in the comments below!

My name is Aditya. I am a Senior Software Engineer - II (Frontend). I blog about web development!

How to Write Cleaner React code

Aditya Tyagi — Tue, 08 Feb 2022 10:50:29 +0000

After getting my hands dirty with over 10 production level React projects, one thing that was consistent with most of them was the use of unnecessary HTML elements/tags. It is highly important that your code is easier to maintain, write, read and debug. As a thumb rule, you can follow this to identify if your code follows clean code guidelines:

These tags were polluting the DOM for no reason at all. But they introduced these tags to overcome the drawback of JSX in React. The drawback is that JSX should always return a single root HTML element.
In other words, this is invalid JSX:

// The parenthesis helps to write multi-line HTML
const element = (

  // 1st div block
  <div>
    <h1>Hello!</h1>
    <h2>Good to see you here.</h2>
  </div>

  // 2st div block
  <div>
    <h1>Sibling element</h1>
    <h2>I will break JSX element</h2>
  </div>
);

Because of this drawback, many developers add div tags to wrap enormous blocks of code. Hence, resolving the drawback of JSX.

const element = (

  // The wrapper
  <div>

      // 1st div block
      <div>
        <h1>Hello!</h1>
        <h2>Good to see you here.</h2>
      </div>

      // 2st div block
      <div>
        <h1>Sibling element</h1>
        <h2>I will break JSX element</h2>
      </div>

  </div>
);

Now, this works for minor projects. I am guilty of going this route as well. Won’t lie. But then as I started working on gigantic React oriented projects, I found the DOM code filled with div tags throughout. This sooner or later resulted in a “div soup“

What is a div soup?

An example will make it much clearer than me slapping the keyboard to vomit out explanatory paragraphs!

Consider this piece of React code:

return (
    // This div does nothing but wraps the two children
    <div>
      <h1>This is heading</h1>
      <h2>This is a sub-heading</h2>
    </div>
  )

The result of this in the DOM will be:

This is a minor example. Real React apps are way more complex. You can have a deeply nested parent-children relationships between components. For example:

  return (
    <div>
      <h1>This is heading</h1>
      <h2>This is a sub-heading</h2>
      <Child1>
        <Child2>
          <Child3>
            <Child4/>  
          </Child3>
        </Child2>
      </Child1>
    </div>
  )

Where the children are:

// Every React JSX element inherently receives the "props" argument
const Child1 = (props) => (
  <div>
    <h3>I am child 1</h3>
    {/* Anything that is passed between <Child1> and </Child1> */}
    {props.children}
  </div>
);

const Child2 =  (props) => (
  <div>
    <h3>I am child 2</h3>
    {props.children}
  </div>
);

const Child3 = (props) => (
  <div>
    <h3>I am child 3</h3>
    {props.children}
  </div>
);

const Child4 = () => (
  <div>
    <h3>I am child 4</h3>
  </div>
);

This will produce DOM:

If you carefully check the generated DOM, you’ll see a ton of div tags which serves has no purpose but to wrap the code and overcome the JSX limitation. Eventually, this will cause a div soup.

This can exponentially increase the time of debugging and hence can affect faster delivery and bug-fixes!

Avoid a DIV soup

Eagle-eyed readers must have noticed the solution in the problematic code itself. All we have to do is create a wrapper React component which returns the passed component without the div

// Wrapper component that returns any DOM element passed between <Wrapper> and </Wrapper>
// The props inherently have the children property on it
// All react JSX elements should be Capitalized as a naming convention 

const Wrapper = (props) => {
  return props.children;
}

Refactoring the previous code:

// Every React JSX element inherently receives the "props" argument
const Child1 = (props) => (
  <Wrapper>
    <h3>I am child 1</h3>
    {/* Anything that is passed between <Child1> and </Child1> */}
    {props.children}
  </Wrapper>
);

const Child2 =  (props) => (
  <Wrapper>
    <h3>I am child 2</h3>
    {props.children}
  </Wrapper>
);

const Child3 = (props) => (
  <Wrapper>
    <h3>I am child 3</h3>
    {props.children}
  </Wrapper>
);

const Child4 = () => (
  <Wrapper>
    <h3>I am child 4</h3>
  </Wrapper>
);

and

return (
    <Wrapper>
      <h1>This is heading</h1>
      <h2>This is a sub-heading</h2>
      <Child1>
        <Child2>
          <Child3>
            <Child4/>  
          </Child3>
        </Child2>
      </Child1>
    </Wrapper>
  )

This will remove the unnecessary div tags and hence prevent the soup!

React Fragments

It will be difficult and an added effort to introduce this Wrapper component in every React project, and we developers try to avoid exactly such situations.

Introducing React Fragments.

According to the official documentation:

A common pattern in React is for a component to return multiple elements. Fragments let you group a list of children without adding extra nodes to the DOM.

ReactJs.org

You can do this in two ways:

Using React.Fragment
Using a short syntax of React.Fragment which is <> and </>

Let me show you via our code above with this:

return (
    <React.Fragment>

      <h1>This is heading</h1>
      <h2>This is a sub-heading</h2>
      <Child1>
        <Child2>
          <Child3>
            <Child4/>  
          </Child3>
        </Child2>
      </Child1>

    </React.Fragment>
  )

Using a short-hand is much better for lazy developers like me:

 return (
    <>

      <h1>This is heading</h1>
      <h2>This is a sub-heading</h2>
      <Child1>
        <Child2>
          <Child3>
            <Child4/>  
          </Child3>
        </Child2>
      </Child1>

    </>
  )

The final code will look like this:


const Child1 = (props) => (
  <>
    <h3>I am child 1</h3>
    {/* Anything that is passed between <Child1> and </Child1> */}
    {props.children}
  </>
);

const Child2 =  (props) => (
  <>
    <h3>I am child 2</h3>
    {props.children}
  </>
);

const Child3 = (props) => (
  <>
    <h3>I am child 3</h3>
    {props.children}
  </>
);

const Child4 = () => (
  <>
    <h3>I am child 4</h3>
  </>
);

This will help you get the same results, avoiding the div soup.

How to be better at your software development job - A Guide

Aditya Tyagi — Thu, 17 Sep 2020 17:04:38 +0000

I have been working as a software engineer for the last 2 years now. I was lucky enough to land a job in an MNC (Multinational corporation) early on and currently working as a Frontend Engineer in my third job and second startup. During these years, I have been exposed to working on client-sites, in teams of all sizes (3-20 people), and various environments like in-office as well as remote!

While working all these years, I came to a few conclusions to become better at your software development jobs. This is for everyone – people employed as software developers and developers who are preparing to land a job in the next couple of months. So, let’s begin…

Being Pro-Active

There is no point of controlling fire when you could have prevented it in the first place. In other words, be pro-active. Now what that means?

Being a pro-active developer means NOT delaying to convey your fuck-ups. That’s pretty much it. Now, these fuck-ups can be as small as an ugly git merge to as big as wrong estimations on a piece of work. When you are pro-active, it gives your team (and your manager) to put a contingency plan in place.

Pro-active also means to convey the updates on your tasks, without being asked. Always consider your team members and managers to be super-busy and hence, try to convey them as much as you can, when you can. Keeping them in-loop will help you ensure everyone is on the same page. Yes, it will take some extra effort, but believe me, having everyone on the same page prior to a SCRUM Call is a boon.

Over Communication

I am not one of those who think being an affluent speaker in a language like English makes you a superior developer. But, being understood, and conveying your point clearly in a message in one go is a super-power and that indeed makes you a superior developer.

The latter is possible only when:

You are absolutely clear what you want to convey.
You know how to frame a message that compliments that clarity of thought

Over-communication is always better than zero or under communication (if that is even a word).

Now, what do I mean by Over Communicating? It means stating the obvious. At times we withhold a piece of information on purpose just because we have a preconceived notion about other developer’s understanding. Refrain from practicing this. When you are working with humans, nothing is “obvious”. Ensure that the message is loud and clear and the fellow developer understood your message.

A tip:

Whenever you are unsure about being on the same page, always request the fellow developer to explain your message to you (like you double-check the order while ordering in a restaurant by asking the waiter to repeat the order). That is how you’ll be 100% sure that your message has been conveyed successfully!

Another domain where over-communicating helps is testing. When you are submitting a module to the testing team, ensure that you attach a list of things to test and explain the functionality/feature you built, saving tester the guess work! This also helps you in hindsight as the tester does not poke you time and again for clarifications.

On the other hand if you are a tester, ensure that while raising a bug you also communicate the steps to reproduce the bug saving developer from treasure hunting the bug!

Clean Code

Everyone knows how important writing clean code is, but most of us ignore the sheer importance of it in the long run. But wait, karma is a bitch, right?

It is highly probable that the shit code you are writing today which is in a “working” condition comes biting you in the ass 3 months down the line. This happened to me, and believe me I am writing this because the scar (from that bite) stays!

Clean code is so important that people have dedicated books on the topic. So a few things that I always follow are:

Indentation - Ensure the entire team has the same indentation settings. 1 Tab = 4 Spaces or 1 Tab = 2 Spaces. Decide and stick to it.

Comments - There are lover letters/snippets to your future self as well as the next developer working on your module.

Missing semi-colon - This is just a noob mistake!

Use TODO - Leave hints/tips and breadcrumbs for yourself and the fellow developer working after you. Complete the TODO before raising the PR.

Debugging messages - Check for all the console.log() messages before submitting your code. And if you are lazy (like me), click here to learn how to remove all console.log() messages in one-go! Also, remove all debuggers as well!

Punctuality

This is one of the most talked about but yet remains the most underrated aspect of working in a team. Even if you are one of the most bad-ass developer, you have to respect everyone’s time. Just because you are good at what you do doesn’t give you “GET-OUT-OF-JAIL” card for free!

So be on the morning SCRUM calls, be punctual with your work commitments and don’t just take an off abruptly on a weekday (I mean too often).

Sometimes your fellow developers are waiting for you to push your code! Don’t be a jerk for keeping them waiting – on purpose!

Be Organized – Google Sheets

This is my Mjölnir. Google Sheets have helped me organize my workday and my work-flow in general. The number of things to keep a track off can hinder your general programming and hence it is important to be on top of it – all the time. Also, the number of things to follow increases significantly when you are working remotely with 20 other people! For example:

Work-From-Home (WFH) checklist

This helps me to make sure I do everything when I start my day and when I end my day. Get the WFH checklist

Sprint Tracker

If you have worked in a product based company and JIRA, the term Sprint will not be alien to you. But for others, a Sprint is a development cycle adhering to a fixed time period, post which the team has a feature implemented. Details here.

The Sprint tracker is something personal and works like a charm for the work-flow being followed at my work-place. It is important to understand that the workflow can be different for different teams and different projects. So, my advice to you will be to develop a Sprint tracker for yourself. Get Sprint Tracker template

Important R&D Links

Now this is “My Thing”. Some of you will definitively think this is just STUPID. But to be honest with you, this has helped me leaps and bounds and have increased my developments speed. One thing that I am sure off is that the problem I solved after 3 hours and if that problem comes again, I don’t want to again go through the agony of finding that 1 StackOverflow answer or that 1 Medium article.

So, every-time I stumble upon something new, I just make a note of it. Now because I work in startup, it also gives me the opportunity of working with a ton of frameworks. So, I have dedicated tabs for them!

Burn Out

Do not work so much that you collapse. You’ll be replaced within 2 days once you aren’t fit to work anymore. Get this thing into your head.

Keep your sanity intact. Do not try to outwork yourself or anyone in your company as a matter of fact! Take your Saturdays and Sundays. Breathe.

In Conclusion…

I’ll be updating this article as I progress with my career as a software developer because improving at your skill and productivity is a continuous process!

Rest, to my fellow experienced software developers, please feel free to suggest your productivity hacks down below in the comments!

Originally published at adityatyagi.com

Pick colors: LIKE A BOSS

Aditya Tyagi — Sun, 14 Jun 2020 11:21:21 +0000

Disclaimer: Windows only

As a front-end developer, one of the most important work is to get the design right. Now there are times when the client is a bit low on budget and cannot provide a professionally designed app with colors-scheme and shit!

There are times when you are asked to do a hot-fix for a production ready app wherein you just have to match the color according to the design.

So, whenever I am developing on Windows, and there is a need to pick colors from an image, browser, website, practically ANYTHING, my go-to tool is: COLORCOP

Color from a desktop icon

Picking color from the Winamp logo

Color from browser

Picking Purple color from the Broswer – RegEx text

With Colorcop, you can pick colors off any surface, literally ANY SURFACE. As you can see in the image above, we are picking colors off of an icon – a fucking icon! Now, how cool is this shit!

In an alternate universe…

For MacOS or Linux users, stick to Chrome/Firefox extensions like ColorZilla. But obviously, just Google ColorCop alternatives for MacOS or Linux and if you do stumble on anything concrete, ping me here!

Originally published at adityatyagi.com

Understanding tabindex – keyboard accessibility

Aditya Tyagi — Sun, 07 Jun 2020 09:22:06 +0000

As a web developer, you are required to ensure that your users have the best of experience while using your product. Traversing your website with a keyboard is one of the fastest ways. Not only this, filling a form which is keyboard accessible takes 1/2 the time, if compared to filling the form using a mouse-keyboard duo.

But the thing is, accessibility is for the people who are either using screen readers or are using assistive technologies. My main aim here is to put down notes on tabindex and how it plays a major role in making your forms and DOM (Document Object Model) keyboard accessible.

How to find active element?

One of the problems while making a form keyboard accessible with tabindex was to find out where the fuck I actually was in the DOM while pressing the TAB key. At times it drove me nuts but then I had to find a better a solution. Turns out, its pretty simple.

document.activeElement

Fire up the chrome/firefox developer tools in your browser and once you are done TAB-bing through the form and want to know which element is in focus, use “document.activeElement” and press Enter.

Firefox developer tools

The most amazing thing about this is that when you hover on active element thrown by the developer tools, you’ll see something like in the picture above, and below!

Chrome developer tools

Understanding `tabindex` and how it works

tabindex is used for 2 major reasons:

to check if the element is focusable
at what point/in what order the element comes into focus

Focus order

There are 6 HTML elements which has the ability to focus by default i.e. you don’t have to explicitly put tabindex attribute.

<a> with href attribute
<link> with href attribute
<button>
<input> without the type="hidden"
<textarea>
<select>

This means, these 6 elements will have the focus during the TAB-ing behavior and the screen readers will be able to read these elements without any extra help!

Important note for Frontend Developers

The order will highly depend on the order in which these elements are coded in .html files.

For example, if you want to use <a> and <input> under the same parent, and you want the <input> to have focus before the <a>, then make sure you <input> has been coded before <a> in the .html file.

position:absolute

Therefore, if you are positioning elements with position: absolute then make sure the absolutely positioned element is AFTER the element you want focused on! I learnt this the hard way so want to give you a heads up!

<!-- First in order -->
<button type="button">I will be first in focus</button>

<!-- Second in order -->
<a href="javascript:void(0)">I will be focused second</a>

Testing playground: You’ll learn it better when you see it in practice! So stop being a lazy-ass and try these examples on CodePen here.

tabindex values: -1, 0, +1

The tabindex values can be negative, 0 or positive.

1. Negative: When the element has negative focus, neither it will be read by screen readers nor it will come in the TAB-ing sequence. A negative tabindex (say -1) will remove the element from the ordering sequence completely. A negative value is a negative value. This means, there is no difference between -1 and -145 or -9999.

If you want to purposefully ignore an element in the TAB-ing sequence, just give it a negative tabindex.

<button type="button">Sample Button 1</button>

<!-- This will be ignored -->
<button type="button" tabindex="-1">I will be ignored</button>

<button type="button">Sample Button 2</button>

Testing playground: You’ll learn it better when you see it in practice! So stop being a lazy-ass and try these examples on CodePen here.

2. Zero: This is the default value. The 6 elements we talked about, will have tabindex="0" by default when the DOM gets built in the browser. But if you want to focus on a non-focusable element like <div> or <span>, you can explicitly give it a tabindex attribute with value 0. Once you do that, the element will follow the default TAB-ing order.

<button type="button">Sample Button 1</button>

<!-- Making non-focusable element focusable -->
<div tabindex="0">Please focus on me</div>

<button type="button">Sample Button 2</button>

Testing playground: You’ll learn it better when you see it in practice! So stop being a lazy-ass and try these examples on CodePen here.

3. Positive: The positive tabindex will place the element having a positive tabindex in the order sequence and the order will be decided based on the value. The TAB-ing will happen in the ascending order.

<button type="button" tabindex="2">Sample Button 1</button>
<!-- This will be ignored, even though it has a tab-index -->
<button type="button" tabindex="1">Sample Button 2</button>
<button type="button" tabindex="3">Sample Button 3</button>

Testing playground: You’ll learn it better when you see it in practice! So stop being a lazy-ass and try these examples on CodePen here.

The first-focus will be on Sample Button 1 having tabindex value of 2. The next TAB will take you to Sample Button 3, completely ignoring Sample Button 2. The TAB-ing will NEVER happen in decreasing order, therefore you will never reach Sample Button 2.

The catch

Positive tabindex values are discouraged and are an antipattern. According to MDN Web Docs, never use positive tabindex values and stick to the default value of 0. But if there is a use-case wherein you want to have a positive tabindex value to change the order of focus sequence, then take a stop the fuck right there. Take a step back and a deep breath while you are at it! Now try to change the order of elements in your HTML file/source code!

TAB-ing must be fixed with correct order of HTML elements within the source code.

In Conclusion…

I have been working as a web developer for more than 1.5 years now and I am a self-learner developer, like the majority out there. The thing with self learning is that you learn stuff when the opportunity knocks on the door to learn that shit. And this was no different. I learned about web accessibility recently and the sheer importance of it.

As web developers we need to understand that we enjoy the privilege to develop products and projects that will be used by speech and visually impaired people as well, apart from the rest of the world. Therefore the next time you are writing code in an HTML file, ensure that it adheres to web accessibility standards.

Checkout more cool stuff here.

Originally published at adityatyagi.com

Working with loaders and RxJS Observables

Aditya Tyagi — Sun, 31 May 2020 11:35:00 +0000

Loaders is an integral part of user experience. Appropriate usage of loaders is essential to ensure smooth experience. If a loader stops too early, it feels like nothing has happened and seems like the app has frozen. If the loader stops too late, then it feels like an eternity to use the app. In both the cases, you loose a user and in extreme cases, are liable for some cuss-words too!

Now if you are working in Angular, then you are obviously working with Observables. But if you are working with React, and are using RxJS Observables to control the data flow (the reactive paradigm), even then you can use the following technique to ensure perfect start-stop of loaders.

Observable lifecycles

There are 3 stages in the lifecycle:

next – This is when the observable completes with a success and sends data to the subscriber
error – When the observable’s execution throws an error and sends an error object to the subscriber
complete – When the execution is completed but no data is sent to the subscriber

Say, you start the loader before making the API call. The tricky part is when and how to stop the loader using the Observable lifecycle.

STOPPING AT EVERY STEP

// initially the loader is false
this.isLoading = false;  

// fetch todos
fetchTodos() {
    // start the loader
    this.isLoading = true;
    const http$ = this.http.get('https://jsonplaceholder.typicode.com/todos'); 

        http$.subscribe(
            next => {
              console.log('Data from API', next);

              // stop the loader once the observable completes with success
              this.isLoading = false;
            },
            error => {
              console.log('Error from API', error);

              // stop the loader if the observable fails
              this.isLoading = false;
            }
        );
  }

Play with the demo here: Stackblitz Link

Using `complete`

The loader in this case will stop only when the observable completes with a success. If the observable fails with an error, we’ll have to still explicitly stop the loader in the error block.

 // initially the loader is false
 this.isLoading = false;  

 fetchTodos() {
    this.isLoading = true;
    const http$ = this.http.get('https://jsonplaceholder.typicode.com/todos'); 

        http$.subscribe(
            next => {
              console.log('Data from API', next);
            },
            error => {
              console.log('Error from API', error);

              // stop the loader if the observable fails
              this.isLoading = false;
            },
            () => {
              // onComplete block
              // stop the loader once the observable completes with success
              this.isLoading = false;
            }
        );
  }

Play with the demo here: Stackblitz Link

BEST WAY: RxJS `finalize` operator

This will help you to stop the loader in both cases, when the observable execution completes in success or when it fails.

For this, you’ll first have to import the finalize operator from RxJS.

import { finalize } from 'rxjs/operators';

Once done, you can use this operator with the pipe operator, just before you subscribe.

// initially the loader is false
this.isLoading = false;  

fetchTodos() {
    this.isLoading = true;
    const http$ = this.http.get('https://jsonplaceholder.typicode.com/todos'); 

        http$
        .pipe(
          finalize(() => {
            this.isLoading = false;
          })
        )
        .subscribe(
            next => {
              console.log('Data from API', next);
            },
            error => {
              console.log('Error from API', error);
            }
        );
  }

Play with the demo here: Stackblitz Link

Here, you don’t have to stop the loader explicitly within “next” and “error” blocks. The loader will be stopped in the “finalize” block in both the cases:

When the observable completes to success
When the observable completes to error

Faking a Failed HTTP Request

To check the stopping of loading in case the observable throws an error, we can fake a failed API response by throwing an error on purpose. For this, we’ll be using RxJS operators like map.

this.isLoading = false;

 fetchTodos() {
    this.isLoading = true;
    const http$ = this.http.get('https://jsonplaceholder.typicode.com/todos'); 

        http$
        .pipe(
          map(d => {
              // deliberately throwing an error
              throw new Error('test error');
          })
        )
        .subscribe(
            next => {
              console.log('Data from API', next);
              this.data = next;
              this.isLoading = false;
            },
            error => {
              this.data = [];
              console.error('Error from API', error);
              this.isLoading = false;
            }
        );
  }

Play with the demo here: Stackblitz Link

The “map” operator is generally used to modify the incoming data before we can use it in the subscribe block. Here, we are using the map-block to throw an Error and hence the error block will get executed.

Hidden Gem – `.add()`

If you feel like “finalize” doesn’t makes sense according to flow because we are writing code to stop the loader before everything, there is .add() operator for you. It behaves same like the finalize operator and gets executed in both the cases – success or error.

let isLoading = false;

fetchTodos() {
    this.isLoading = true;
    const http$ = this.http.get('https://jsonplaceholder.typicode.com/todos'); 

        http$
        .subscribe(
            next => {
              console.log('Data from API', next);
              this.data = next;
            },
            error => {
              this.data = [];
              console.error('Error from API', error);
            }
        ).add(() => {
            this.isLoading = false;
        });
  }

Play with the demo here: Stackblitz Link

In Conclusion…

The one thing which is not addressed here is unsubscribing of Observables but I’ll surely cover that in the upcoming post. This was just to bring to your attention that Observables are sneaky.

I learnt this after a number of trial and errors and its such a small thing which is being used in every project I do. There is one other way to start-stop the loader globally in the app which uses RxJS BehaviorSubject. I’ll try to update the post with this in future as well!

Until then, share this with your friends/colleagues.
Any suggestions/ideas/advice/feedback – please reach out to me:

In the comments below
Email - tyagi.aditya844747@gmail.com
Twitter - @secondbestcoder

Originally poster on adityatyagi.com

Forem: Aditya Tyagi

Logical CSS: Padding And Margins In Multi-lingual Web-Apps

The Need For Logical CSS

Defination

Physical CSS Properties: Rewind

Understanding The Basics Of Logical CSS Properties

Understanding Block Flow

Understanding Inline Flow

Box Model for Logical CSS Properties

Support

Code Reviews Should Not Suck!

How to raise a pull request (PR) as a beginner

No Clear Reviewer or Assignee or Title

Delayed Reviews

Missing Details — Pull Request Templates

Repeated/Skipped/Ignored Reviews

Singleton Purpose Of The Pull Request

No PR Should Be More Than 400 Lines Of Code — Scientifically Backed

Mind Your Tone Of Writing

Responsive Font-Sizes In React Apps

Best CSS practice to ensure consistent styling in web applications

Pre-requisite to understanding responsive layouts

CSS REM — What is REM in CSS?

When to use rem and when to use other relative CSS units?

How To Use REM In CSS

Need for a utility function

Why Not To Use EM For Font-Sizes in CSS?

Other ways to use REM in CSS for responsive web apps

Everyday GIT

Might not be for you, but might be exactly what you need!

Why another Git Cheatsheet?

Useful GIT resources

ReadMe and Markdown

Git Alias

Multiple Git SSH accounts

Special Mentions

Why NextJs should not be ignored.

A brief introduction to a full-stack framework backed with React syntax

Products using NextJs

Comparison with other frameworks

Developer Experience & Community

Performance

Better Search Engine Optimization

File Based Routing in NextJs

Configurations for NextJs

Full Stack Capabilities of NextJs

How to debug a React App

Debug React apps like a pro!

Re-read the error messages

The dev-tools

The web page

Learn to use your IDE

Working with Breakpoints

Breakpoints via Dev Tools in the browser

Using the debugger in the IDE like VSCode

React Developer Tools

Reach out for help!

4+ years of cracking technical interviews

A framework to solve any technical interview question

Understand The Problem

Explore Concrete Examples

Break It Down

Solve or Simplify

Look Back And Refactor

Want to connect?

How to Write Cleaner React code

What is a div soup?

Avoid a DIV soup

React Fragments

How to be better at your software development job - A Guide

Being Pro-Active

Over Communication

A tip:

Clean Code

Punctuality

Be Organized – Google Sheets

Work-From-Home (WFH) checklist

Sprint Tracker

Important R&D Links

Burn Out

When to use `rem` and when to use other relative CSS units?

Understanding `tabindex` and how it works

Using `complete`

BEST WAY: RxJS `finalize` operator

Hidden Gem – `.add()`