DEV Community: Sameer Kumar

🔮 Functional Programming for Humans — Foundations

Sameer Kumar — Mon, 29 Jul 2024 06:09:34 +0000

Functional programming (FP) is like the cool, rebellious middle child of the programming (language) family. Instead of following the traditional imperative way of doing things step-by-step, FP focuses on creating clean, predictable code by treating functions as first-class citizens. It’s like the stand-up comedy of coding: sharp, witty, and always on point.

A lot of jargon in the introduction itself? Thought so.

Some quick bullet points to wash off that cult image of FP

There isn’t a clear line dividing functional programming languages from other languages.
You can write functional code in almost all languages. Even in boundaries of strict OOP languages.
Your code doesn’t need to be 100% functional. Try to keep it as immutable and pure as humanely possible.
FP doesn’t make you cool. It may do a little bit of idiot-proofing though.

Today we’ll go through a few jargon to set the stage for upcoming adventures. I’ll stick to dumb JavaScript for code examples. Let’s keep Haskell/Elixir show off for later, hold peace it’ll come.

Pure functions
Immutability
Side effects
Higher order functions

Pure functions

The simplest and most important concept of functional programming is to make code outputs consistent. The same input(s) should give the same output. As simple as that. No T&C applied.

You send 2 and 3 to a function called sum. It should always give you 5 and never 23. Javascript joke!

So you ask: Dear Sameer, it’s dead simple to ask for any computer program let aside this FP. Doesn’t all code work like that, or at least should work like that?

Well easier said than done in large codebases where everything is like a mess of randomness. Let’s take a few simple examples.

Pure functions:

function add(a, b) {  
    return a + b;  
}  

// Example usage:  
console.log(add(2, 3)); // 5  
console.log(add(2, 3)); // 5

function toUpperCase(str) {  
    return str.toUpperCase();  
}  

// Example usage:  
console.log(toUpperCase("hello")); // "HELLO"  
console.log(toUpperCase("hello")); // "HELLO"

Impure functions:

let counter = 0;  

function incrementCounter() {  
    counter += 1;  
    return counter;  
}  

// Example usage:  
console.log(incrementCounter()); // 1  
console.log(incrementCounter()); // 2

// Outputs a random number between 1 and 10  
function getRandomNumber() {  
    return Math.floor(Math.random() * 10) + 1;  
}  

// Example usage:  
console.log(getRandomNumber()); // 2  
console.log(getRandomNumber()); // 6

However rudimentary, that gives a general idea. A pure function will always be consistent. Impure ones can and will backstab you in most unexpected places. Imagine, one time your bank account shows $150,000 and you refresh the page to see $150. Good enough for a minor heart attack, aye?

Immutability

Let’s define mutation first

No change == No mutation == Immutability == Trust

Now that we have semi-formally defined it, let’s look at how it works. After all, programming is all about changing one data into another. We’ll write a small mutable code and see the perks of its immutable version.

function updateAge(obj, newAge) {  
    obj.age = newAge;  
    return obj;  
}  

// Example usage:  
const person = {  
    name: 'Alice',  
    age: 25  
};  
console.log(updateAge(person, 26)); // { name: 'Alice', age: 26 }  
console.log(person); // { name: 'Alice', age: 26 }

Let’s dissect. Good Alice is 25 years old, to begin with. If I come to the last line directly and want to know the age of Alice(aka person), I’ll have to track this person object everywhere and carefully understand who modified it and “how”.

Let’s fix this mutation:

function updateAge(obj, newAge) {  
    return { ...obj, age: newAge };  
}  

// Example usage:  
const person = {  
    name: 'Alice',  
    age: 25  
};  
console.log(updateAge(person, 26)); // { name: 'Alice', age: 26 }  
console.log(person); // { name: 'Alice', age: 25 }

Now, anywhere we meet this person, we are guaranteed to know its state by seeing it’s original definition. If this new value is required for something, go ahead and keep it in a new updatedPerson variable. If someone later wanna know the age of updatedPerson , he’ll just jump to the place where it is first defined. Savvy?

Benefits you ask. Here are a few:

It becomes easy for the language’s internal tools to clean the used memory, aka, garbage collection.
An implicit guarantee that value will remain consistent throughout the life of a variable.
A ton of predictability in the code. You can just skim a few lines and tell what the value is at any point in time, without reading the entire code.
Idiot proofing. You know that someone else won’t modify what you read the first time. Ah! Do those edited WhatsApp messages ring a bell?

Higher order functions

This one ain’t much. Simply said, a function can take and return functions too, just like it plays with regular data.

Depending on your previous programming experience this may look normal or whaaaat. I expect no in-between experience.

When you treat functions as first-class citizens, you can do some pretty amazing things by combining or passing them around. Let’s see a few examples:

// High-order function that returns another function  
function makeMultiplier(multiplier) {  
    return function(number) {  
        return number * multiplier;  
    };  
}

// Example usage (custom tailored functions on the fly)  
const double = makeMultiplier(2);  
const triple = makeMultiplier(3);console.log(double(5)); // 10  
console.log(triple(5)); // 15

import {map} from 'lodash';

const numbers = [1, 2, 3, 4, 5]; // This map function takes a list of some data and a function.  
// Basically running the same function on each item in the list.  
const doubledNumbers = map(numbers, number => number * 2 );// Example usage  
console.log(doubledNumbers); // [2, 4, 6, 8, 10]

Side Effects

Here the real trouble starts. As the name suggests, your code will poke its nose into things that are beyond its scope. If the function modifies or triggers something that’s outside its scope, it can wake the dead from graves. We may never know the full extent of what this external call did until you are neck deep in that call stack rabbit hole.

Too many fancy words? My sympathies. Let’s see the code you wrote some days back.

Yeah Yeah Yeah! Now you tell me that you didn’t know that bunnies too have nukes. Classic!

Let’s create a cocktail of what we learned from pure functions and immutability. Side effects totally rack jacks our two beloved concepts.

const numbers = [1, 2, 3];  

export function addNumber(number) {  
    numbers.push(number); // Modifies the original array  
}  

export function viewArray() {  
    console.log(numbers); // Prints numbers array  
}  

// Sinjo calling same method in different files  
viewArray() // 1,2,3  
viewArray() // 1,2,3  
viewArray() // 1,2,3  

// nastyuser_123 called it somewhere randomly  
addNumber(4)  
viewArray() // 1,2,3,4

These functions are making side effects on the numbers array. Our good user Sinjo is compulsively printing arrays using viewArray function and getting the same results everywhere, pseudo-smiling in purity. Then someone called this addNumber(4) and now his system is broken and he doesn’t even know why.

Sinjo wants answers, Sinjo wants justice! ❤️‍🩹

That’s all folks for today. Reflect on this jargon list. Whatever we went through should give a clear idea about what problems we are trying to solve. In the next piece, we’ll get our hands dirty with some deeper concepts. Ciao.

Want to connect?

Website

PostGraphile — The Gateway Drug To GraphQL

Sameer Kumar — Fri, 03 Nov 2023 10:02:49 +0000

Postgraphile is the quickest way to scaffold a fully functional GraphQL CRUD API for your application without touching a line of code, (well that’s a lie but let it pass for dramatic effect). This article will expose you to the basics of what GraphQL is and how can we create an api quickly with postgraphile.

Disclaimer: This article will give an overview of what these concepts are at top level. Go ahead with documentation of specific library to understand real world implemenetation details.

What is GraphQL

https://graphql.org

GraphQL is a query language(QL) just like the good old SQL. I won’t go into any bookish definition. Let’s understand it practically.

Now that the QL part is sorted, let’s give meaning to the graph word. It may chime with the feel of ERDs used in RDBMS. Okay my bad, forgot my promise of being practical. Let’s visualize the medium or any blog as a graph in the simplest possible manner.

User 1 wrote 2 articles — Article 2 has 2 comments — User 2 wrote Comment 1 — User 2 also wrote Article 3

Now things appear much more visually understandable. We can see the connection that each record bears with another, without abstractly thinking in terms of tables. At this point, everything starts looking like one big graph of records.

To sum up, GraphQL is a query language to query this graph of records, just like SQL is a query language for data stored in tables.

Terminologies

Node: An individual object present in our database.
Edge: Relationship of the said object with others.
Query: As the name suggests, process of getting one or more fields from the node.
Mutation: A change operation on the node as a whole or some of its fields.
Schema: A representation of the overall structure of the graphql system.
Resolver: A function that tells how to get a certain field on a node.

These folks have picked up some sensible nomenclature. It seems redundant to even explain what each term means. +10 points. If you want to learn it, nothing beats the official docs. But, for the sake of completeness, let's do a small example.

Sample code in JavaScript

import { ApolloServer } from "@apollo/server";  
import { startStandaloneServer } from "@apollo/server/standalone";  

const typeDefs = `#graphql  
  type Book {  
    title: String  
    author: String  
  }  

  type Query {  
    books: \[Book\]  
  }  
`;  

const books = [  
  {  
    title: "The Awakening",  
    author: "Kate Chopin",  
  },  
  {  
    title: "City of Glass",  
    author: "Paul Auster",  
  },  
];  

const resolvers = {  
  Query: {  
    books: () => books,  
  },  
};  

const server = new ApolloServer({  
  typeDefs,  
  resolvers,  
});  

const { url } = await startStandaloneServer(server, { listen: { port: 4000 } });  

console.log(`🚀 Server listening at: ${url}`);

I know it may be overwhelming for someone new. Let’s quickly break it down a bit in some bullet points.

**@apollo/server** is the GraphQL provider library, which makes the implementation and life easier. It has both a server and a client.
**typeDefs** is used to define the structure of our data and allow queries.
**books** is a mock source of data, in the real application this will be some database.
**resolvers** provide the implementation details as to how these queries will be resolved.

Output

localhost:4000

I wonder if anything can be simpler. You might not have noticed that it solves one of the biggest problems with REST APIs.

With GraphQL we fetch only the specific fields that are required for our current need.

Long gone are days when API responses will contain two-thirds of useless data for work in hand. It is a game changer for large-scale applications owing to this solution for overfetching.

Apart from overfetching, underfetching is no less a problem. Imagine you want a book and its publisher’s name to show on a webpage. One query goes for the book and then the next one for publisher API. With GraphQL, it can be easily done in one shot as:

query BooksWithAuthor {  
  books: {  
    title,  
    author,  
    publisher: { name }  
  }  
}

So far so good. I see you vibing with the overall idea. Define how you’d like the output to be and it comes just like that without repeated queries. What can be accessed and how it will be furnished can be tightly controlled by typedefs and resolvers in the backend.

In the next section, we’ll take a few bitter pills to set the expectations right.

What isn’t GraphQL

Not a piece of cake

Repeat after me, GraphQL is just a type of API, like REST.

GraphQL is not a:

Standalone full-scale server
Database paradigm or Query Language
Business logic container

So, even with GraphQL, you’ll need a traditional SQL/no-SQL database like MySQL, Postgres, MongoDB, etc. We are just changing the way the front end calls the back end in contrast to the traditional REST API.

GraphQL is a delight for front-end developers. Nothing makes them happier than using GraphQL to fetch all the data they need in one shot. Imagine a single API call giving all the information needed to render a page completely.

Then why it isn’t spreading like wildfire in the developer circles? Well, that’s because it’s a pain for backend devs to write and manage these APIs. All that nesting becomes troublesome to write typedefs for. Nuances for connecting with every single table, handling permissions, and most of all tuning the performance.

If one is not going for traditional table joins then imagine hitting a query to get publisher details for every book that you get. It’s the infamous N+1 problem in the world of SQL and REST. Frontend becomes a little easy but the backend becomes a nightmare.

What is PostGraphile

PostGraphile Instant GraphQL API

It is a GraphQL implementation using Postgres as its database, the best database known to mankind. The good part is that it involves the least amount of manual intervention possible. Almost a no-code solution if you want to query or modify your database without any customization.

It can be used in three ways:

Schema only — It generates the GraphQL schema by using Postgres table reflections and leaves implementation to users.
CLI mode — It can be run using the PostGraphile CLI tool with options and a list of extensions passed inline.
Library mode — The most versatile approach where it can be mounted as a route to existing NodeJS applications. Custom functions can be written to extend the schema obtained from the database.

For a complete overview, we will look into library mode. In its essence, PostGraphile is a middleware that sits between the Postgres database and your web API, which automatically scans and facilitates GraphQL queries and mutations. In short, it automagically creates typedefs and resolvers.

Getting started

Scaffold an express application.
Install PostGraphile. npm install postgraphile
Add some quick start configs to the starting point of the app.

const express = require("express");  
const { postgraphile } = require("postgraphile");  

const app = express();  

const postgraphileOptions = {  
  watchPg: true,  
  dynamicJson: true,  
  setofFunctionsContainNulls: false,  
  ignoreRBAC: false,  
  showErrorStack: "json",  
  extendedErrors: \["hint", "detail", "errcode"\],  
  exportGqlSchemaPath: "schema.graphql",  
  graphiql: true,  
  enhanceGraphiql: true,  
  allowExplain(\_) {  
    return true;  
  },  
  enableQueryBatching: true,  
  legacyRelations: "omit",  
};  

app.use(postgraphile(process.env.DATABASE\_URL, "public", postgraphileOptions));  

app.listen(process.env.PORT);

Apart from PostGraphile feature toggles, we need to pass the database URL as the most important parameter to PostGraphile for it to bootstrap the application.

It may appear monkey business up till here but forget not. This is all you need. It doesn’t matter if your database contains 2 or 200 tables, 10 or a million records, 10 or 10,000 users, etc.

You might have noticed we are not defining any typedefs or resolvers. Postgraphile is looking at our well-structured Postgres db and converting the table schema into a GraphQL schema.

Apart from the HTTP endpoint, we get a full-blown playground to test our queries and mutations easily. It comes up at the /graphiql route. Have a look below.

localhost:5001/graphiql

No surprise, it works just like the regular GraphQL API, and we can do that nested query, which we were amazed at. On the left, we have a full-blown explorer, which shows what our schema looks like. The center panel is for queries and mutations. The right one is for our output. Once we are confident, we can just copy the centerpiece and paste it into our front-end application.

One super important thing to notice here is that all this schema is generated by following some strict naming conventions. Notice how we used the field name tracksByUserId to get all tracks of a user where the tracks table is connected to users table using the user_id field. There are a handful of such rules that you can check on the PostGraphile website.

In the next section, we’ll go through some common things you may want to do in PostGraphile.

How to do stuff in the PostGraphile world

Preparing the database

This is going to be the old simple Postgres setup with no additional steps. Create a schema explicitly if you need access control to certain tables. Make sure to add necessary foreign keys to connect various tables. In the end, all we need is a valid database URL to feed in PostGraphile initialization. The format looks like this:

postgres://user:password@somehost:2345/somedb

Creating a custom field

It’s pretty common to need a composite/computed field in your response object. The simplest example is combining the first and last name into full name. There are two ways to achieve it:

Use database-level functions: This method is the fastest and most optimized because code lives right into the database. For this example, you just need to open the database console and run the following:

CREATE OR REPLACE FUNCTION users\_fullname(users users) RETURNS text AS  
$$  
SELECT CONCAT(users.first\_name, ' ', users.last\_name)  
$$ LANGUAGE sql STABLE;

Notice that it follows a certain format in naming. The name of the function will always be tableName_fieldName, allowing PostGraphile to connect it as the resolver for that specific field automatically. You can keep it as a db migration script or whatever fits your use case.

2. Write resolver manually when things are more complex: We need to go this path to cleanly define custom functionalities in the PostGraphile system. For the given example of fullName, we can create it as an extension in a separate file and import it into the main file where we initialize the app.

fullname.js contains this custom resolver to extend what we already have. The name of the file is totally up to you.

const { makeExtendSchemaPlugin, gql } = require("graphile-utils");  

// Create a GraphQL schema extension to add the computed full\_name field  
const FullNamePlugin = makeExtendSchemaPlugin({  
  typeDefs: gql\`  
    extend type User {  
      fullName: String  
    }  
  \`,  
  resolvers: {  
    User: {  
      fullName: (user, args, context, resolveInfo) => {  
        return \`${user.firstName} ${user.lastName}\`;  
      },  
    },  
  },  
});  

module.exports = FullNamePlugin;

Now we can import this file into our main file as:

const FullNamePlugin = require("./fullname");  

const postgraphileOptions = {  
  ...  
  appendPlugins: \[  
    FullNamePlugin,  
  \],  
  ...  
}

With just this much work, our custom field and resolver are ready to use in our application. And, it works as expected.

Querying custom fields in postgraphile

Adding a description to fields in GraphQL Explorer

It makes sense, and it is hardcore simple. Add a comment to the field using SQL, and it will be available in the explorer.

comment on column tracks.bpm is E'Beats per Minute...';

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zd9n8x6cayhfz7537b5h.png)

Auto-generated documentation for the bpm field

Control visibility/modification of fields or tables

Again magic comments are to our rescue. Postgraphile can be instructed to exclude any field or table from GraphQL access by using smart tags such as:

// users table is marked as read only  
comment on table users is E'@omit create, update, delete';  

// version field from tracks table is completely removed from graphql  
comment on column tracks.version is E'@omit read';

Access control to records

Since it is so deeply tied to Postgres, it makes full use of Postgres roles and schemas for security. Postgraphile comes with a built-in implementation of JWT and can be used to fine-tune access further. A simple authorization looks like:

GRANT SELECT ON users TO app\_users;  
GRANT DELETE ON users TO app\_admins;

Also, row-level security features can be used to finely restrict people from accessing a certain row in the table.

create policy user\_policy\_select  
on public.users for select to users  
USING (  
email = current\_setting('current\_user\_email')  
);  
ALTER TABLE users ENABLE ROW LEVEL SECURITY;

Filtering records

Filtering is supported natively to a certain extent, and it can be enhanced with full relational operator support using a connection filter plugin. Sample syntax:

query getOneUser {  
  user(id: 1) {  
    id  
    email  
    name  
  }  
}

Postgraphile Filtering

Connection Filter Plugin

One good thing to know is that postgraphile behind the scenes optimizes your query conversion from GQL to SQL. The result is one single top-level query, thus eliminating the N+1 problem we discussed earlier.

You can go on with postgraphile documentation to continue your exploration further.

Cons of PostGraphile

Once again, same question: if everything is so awesome, why isn’t everyone using this as a defacto way of building applications?

The answer was evident from the start. PostGraphile takes away a lot of control from the user for its magic to happen. From big technical details to simple things, such as how one should name his fields, are dictated by PostGraphile. Engineers don’t like this, and they seriously don’t.

Apart from technical things, the community is pretty small. So, if you are stuck somewhere, the lord may have mercy.

Being so close to db creates a big abstraction for developers. Making change is tough because things are living right in the database. And, also switching the db is not much of an option.

Regardless, I like the simplicity it brings to the table. We can use this solution for small websites like personal blogs, portfolios, hobby projects, etc. It seems a solid contender for even big websites that are frontend-heavy and don’t have much going in the backend apart from simple crud.

Conclusion

It's been a bumpy ride, ain’t it? GraphQL is an interesting piece of technology and can be useful in certain scenarios, such as:

You don’t know the access pattern of the consumer apps.
Your tables are huge, and in most cases, people only need a small subset of fields.
Performance issues need to be solved by reducing response payload size and network roundtrips.

But be aware implementing those types and resolvers will suck life out of you as the application starts getting complex. PostGraphile’s approach is clap-worthy but a little idealist. Nonetheless, if someone is starting with GraphQL, postgraphile serves as a magical option to use your existing database and get a feel of how things will look in the GraphQL world without investing time and effort in an elaborate setup.

Want to connect?

Website

No More Drama: Conflict Resolution

Sameer Kumar — Tue, 24 Oct 2023 13:25:16 +0000

Earth and World are not same things. You might have heard people discussing their world view, and not the earth view!

Oh! you are confused? Works well for me. After ages, I am writing a non-tech article solving softer problems in this diverse tech industry. Let’s take a purely fact-driven objective take on this issue, no personal takes. Any personal opinion from me will pollute the theme of this discussion.

Earth vs World

Okay, let’s clear up this one first. First, a quick definition to set baseline context and ensure we all are on the same page. Don’t disagree at this point, otherwise, I’ll find you and have a word, the old-fashioned way.

Earth — A planet on which we live. It looks blue, blue is beautiful.
World — A consolidated model of everything someone “knows about”, covering the earth and beyond.

Now that term, world-view makes sense. The key takeaway is that “The Matrix” is real and everything is a mere interpretation of someone trapped in it.

Nothing is absolute truth if more than one person is involved in the context. Even this very sentence depends on your prejudice.

Bold Take! I get it, let’s break it into digestible chunks.

Conflict — The Origins

Most of the time, I witness conflicts either professionally or personally circle around the root cause of identity crisis. We work our entire lives to gain an identity in society and make sense of our existence. Psychologically, it is understandable that we can’t gain that identity if we compromise every now and then, we’ll be wiped off. After all, we are what people perceive about us.

We defend what we stand for because they define us. Without that, there are billions of similar human bodies occupying the earth, who gives a crap.

As you would have guessed yourself, conflicts rise when contrasting identities collide. Seems right, as long as something is scientifically justified, I’m cool with it. Now that raises the question, “If it is so normal, then why does it feel so piercing at times, is there a crack in human anthropology?”

The answer seems straightforward to me. It is a well-architected negative feedback loop. You lose an argument, you feel inferior, you work on it, win the next one.

Well now that we have established that we are not fighting but our opinions are, let’s look at how to fix it. Without a solution, this whole discussion will be a sham.

Perception — The problem

Perception is the root cause of each conflict. Take the example of the cover image of this article. Both are fighting because one perceives the digit as 6 and the other as 9. This is a little evened out, let’s give it the benefit of the doubt. Maybe an office scenario, where two colleagues are fighting over which solution fits better as in the case of a competing project proposal. This seems more relatable. Ain’t it?

The way every person lives in this world is totally unique and hence the viewpoint. No two people ever can perceive the same thing/event in exactly the same way. So, by our Many World theory, both are right. If someone is wrong at all then it’s the person who thinks “only” he/she is right.

Example: Two people fighting over which is better SUV or Sedan. X says SUVs are best because it is for all terrains. Y says Sedans are best because they look the best. One common issue that will follow after the sane argument above is defensive-offensive justifications. This point beyond perceptions overtakes facts and people start influencing and imposing their opinions so that the competition starts thinking in their favor, eventually folding towards his/her point of view.

Perspective — The solution

To understand the gist of this term it takes a lot of maturity and experience. How many times, you have seen a conflict resolution with your colleague ending in, let’s do whatever is good for the project, or Here are 3 pros and cons of my approach?

Ain’t that relatable? Some workplaces do encourage such good outcomes, including mine, but at the end of the day we are humans and our perception goes ahead of us. Perspective is like glasses that you can wear and see what another person might be seeing. Seems trivial in the text but takes a lot of courage to compromise own identity and adopt others’ even for a short while.

Steps for resolution

Detach: Detach your identity from the problem at hand. Exclude all your relevant experience from the “decision” part. Example: For me as a programmer, my first language java always makes a tiny vote in deciding how a system should look, maybe subconsciously. As expected, for two equally good proposals I’ll subconsciously choose one that is in harmony with my experience. Maybe between Java and Ruby, I decided on Java. I know both, no problems for me either way, but on the flip side maybe the other guy only knows Ruby and is going through a nightmare thinking about the Java behemoth he’ll have to deal with if this one gets approved.
Objectify your thoughts: This is extremely important as in any conversation, conversation skills play a bigger role than the underlying points. We should even that out by looking at things objectively first before going into subjective explanations. Make a bullet list of why your idea is good and what problems it has. Writing or even thinking about the second part will clean up half the malice. I bet it will be just a smooth discussion thereafter because you yourself have attested to where you(your idea) win and lose.
You are not the only right one: Start the discussion with one clear goal that you are not the right person in this discussion or your idea is not the right one. It changes everything when you open yourself to walk in another’s shoes and see things as they are thinking. On a positive note, you can find a flaw in other people’s thought processes and can give feedback rather than being dismissive at the surface level.

If you start losing to yourself. Repeat the following:

I, a well-educated rational person, can’t even listen with an open mind to someone who maybe comes from a different culture, upbringing, education, experience, work style, goals and more. I am awesome !!!

Funny but works. An instant dose of humbleness gets delivered. Never involve yourself. Let those 5 bullet points shoot each other. Whatever survives the battle, go with that.

If everything is based on perspective, how can mine be the absolute one?

This sheer fact changes everything as long as you are courageous enough to compromise your identity for the duration of the discussion.

I landed in such a conflict with one of my friends last month while deciding tech stack for his mobile application. For reference, he is a hardcore native mobile developer and I just know a little bit of Flutter. I vouched for Flutter, he went for Kotlin. We shot each other for an hour and later realized how stupid we were and the idea for this article came.

Even he laughed when opened a notepad and started noting figures for usage volume and access patterns. In the end, we went for react native after salvaging a significant chunk of business logic from the main React web application.

Give it a shot, feels good!

Want to connect?

Website

The Pragmatic Guide to Your First JavaScript Library

Sameer Kumar — Sun, 22 Oct 2023 14:40:22 +0000

JavaScript libraries! Every man and his dog has a node_modules folder full of them. This article will be more or less a pragmatic guide to writing these without going neck-deep in history and theory.

Let’s get started. First of all, a bit of pseudo-nomenclature. For all intent and purposes, we will classify libraries into two sections:

Utilities: Non-UI libraries, as in these libraries, will provide functionalities in JavaScript without manipulating the DOM. For example, Lodash gives us a function to sort an array.
Components: UI manipulation libraries, which mainly intend to manipulate the DOM. For example, a react component library like material UI.

Intuitively, it’s clear that building utilities is easier than building components because of the technical stack’s width involved. What the particular library internally does is beyond our scope. We will focus on how to pack, distribute, and use them.

Setup the Most Basic Example

Remember, in most cases a good library is a decoupled section of your application that you want to distribute to others. Folder structure:

You can get the idea by looking at the example application I have set up. Codes living in the lib folder, don’t directly link to the business logic of the main application.

For our first example, we are building a utility library that returns a random ninja’s name using a highly complex randomization logic. Let’s look at the file contents:

// lib/ninja.js  

const ninjas = \["Kakashi", "Itachi", "Shikamaru"\];  

export function getRandomNinja() {  
  return ninjas\[Math.floor(Math.random() \* ninjas.length)\];  
}

// index.js  

import { getRandomNinja } from "./lib/ninja";  

console.log(getRandomNinja());

<!-- index.html -->  

<!doctype html>  
<html>  
  <body>  
    <h1 id="name"></h1>  
  </body>  

  <script type="module">  
    import { getRandomNinja } from "./lib/ninja.js";  

    const ninja = getRandomNinja();  
    document.getElementById("name").textContent = ninja;  
  </script>  
</html>

Looks good. Let’s try to run it. A flying brick received right in the face. Hey, we are positive people. We are going to look into it. No worries!

>>> node index.js

Modular JavaScript (MJS)

The error looks straightforward. Let’s try to look into the second suggestion before dialing into the whole node_modules ecosystem. We are going to rename those JS files to the mjs extension. And voila! It works. Even the HTML example started working as expected after changing the extension of the referenced file there.

ninja-lib ❯❯❯ node index.mjs  
Shikamaru  
ninja-lib ❯❯❯

For its help, mjs definitely deserves a discussion here. MJS is an acronym for Modular JavaScript.

So, officially, there are two flavors of JavaScript: one regular one and another that imports and exports modules “natively.” There are technical differences in their internal implementation and scope resolution, but let’s not get ahead of ourselves.

MJS is newer and may not work in a Neanderthal’s machine running Internet Explorer, but for common masses, its good to go.

Here comes package.json

Now, we’re revisiting the previous suggestion of using a package.json file. Apart from the internal cons of mjs, the main reason for the former approach being widely accepted is because of more familiarity with devs and machines.

We rolled back those mjs extensions to regular js files and added this bare-bone package.json file at the root of our project. Notice we mentioned it’s a module here. Everything works as expected!

// package.json  

{  
  "name": "ninja-lib",  
  "author": "Sameer Kumar",  
  "type": "module",  
  "version": "1.0.0",  
  "description": "Library for finding real ninjas",  
  "main": "index.js",  
  "directories": {  
    "lib": "lib"  
  }  
}

This lib folder is now ready for shipping. You can push it to GitHub or npm. Each platform has a very easy quick start guide to publish there; nothing too technical involved. Your users get exactly what you have written in the lib folder — no surprises packaged. This works well depending on the complexity of your library and how much less it depends on other libraries.

Stepping Up With Distribution Strategies

Now that we have written something, we want to distribute it to other folks in a clean “packaging.” After all, we just added a package.json file, so the name should carry the weight.

A module/library can be packaged in a few well-accepted formats. Some techniques are:

UMD (Universal Module Definition)

UMD is a versatile module format that works in all environments, including in the browser. It provides a way to create modules that can be used with minimum expectations from the consumer.

Forget the mumbo-jumbo, remember the script tag from the golden days. You’ll go for this packaging if you want to simply import in an HTML file and move on like we used to in our beloved jQuery. Here’s what that looks like:

<!-- index.html -->  

<!doctype html>  
<html>  
  <body>  
    <h1 id="name"></h1>  
  </body>  

  <script src="https://code.jquery.com/jquery-3.7.1.js"></script>  
</html>

ES6 Modules (ESM)

ECMAScript Modules (ESM) are a native module system for JavaScript, and modern browsers and Node.js support them. They use import and export statements to define and load modules.

We have already done an example of this format in our previous ninja finder example. Here’s the code:

// calculator.js  

export function sum(a, b) {  
  return a + b;  
}

// index.js  

import { sum } from "calculator.js";  

console.log(sum(2, 2));

CommonJS (CJS)

CommonJS is a module system used primarily in Node.js. It uses the require and module.exports (or exports) syntax to define and import modules.

No wonder you have seen it once or twice. It is the predecessor to the ES6 import/export syntax we used in our above example. It is slowly fading out of even the backend development ecosystem in favor of the ES6. You must have seen it in Express apps.

It’s very important to consider this packaging format if you are shipping your library for both frontend and backend.

// calculator.js  

const sum = (a, b) => {  
  return a+b;  
};  

exports.sum = sum;

// index.js  

const calculator = require('./calculator');  
console.log(\`2 + 2: ${calculator.sum(2, 2)}\`);

Many more of these formats are custom-tailored for specific use cases, but the above three should be good enough for us potato developers. ;)

Honorable mentions should extend to SystemJS and AMD (Asynchronous Module Definition) as well.

Bundling Systems

Now, the real fun starts. You don’t want the user to import 42 separate js files to handle other files that need to be imported. To be honest, your user won’t take a look at your library either. It should be as close to a one-click installation as possible. As seen in the UMD example above, we added a ton of jQuery features just by adding one line of script tag.

Some common bundling toolchains build your application/library into an optimized distributable bundle. The strategy can vastly differ from everything bundled into a single js file or split into chunks that automatically load when needed. A few big names in this game are:

Webpack
Rollup
Parcel
esbuild
SWC

Each one has its own nuances, but for us, all are doing the same work of bundling. Some are faster, some are more extensible, some are more supported, etc.

For our purpose, nothing matters. When choosing one for your project, you’ll do deep analysis for sure. One that I can suggest, which works well, is a tool called Vite. Vite is not a bundler but a build framework that internally uses esbuild and Rollup for bundling. Let's implement it in our ninja application.

Adding Vite to Existing Application

https://vitejs.dev

Adding Vite is super simple. Let’s add it to our package.json file. Notice the scripts and devDependencies sections. Run npm install or yarn to install the new dependencies we added. Here’s what that looks like:

// package.json  

{  
  "name": "ninja-lib",  
  "type": "module",  
  "version": "1.0.0",  
  "description": "Library for finding real ninjas",  
  "scripts": {  
    "dev": "vite",  
    "build": "vite build"  
  },  
  "devDependencies": {  
    "vite": "^4.4.5"  
  }  
}

With it installed, we are ready to roll with all the goodies with Vite, especially my favorite, hot reload. Before we start our dev server, let’s make some changes so the code will accept Vite.

Using Vite for a single-page application

By default, Vite looks for the index.html file in the root directory, so we are good there for now. Let’s simplify the HTML a bit by adding the following code:

<!-- index.html -->  

<!doctype html>  
<html>  
  <body>  
    <h1 id="name"></h1>  
  </body>  

  <script src="./index.js" type="module"></script>  
</html>

// index.js  

import { getRandomNinja } from "./lib/ninja.js";  

document.getElementById("name").innerHTML = getRandomNinja();

That is all. Nothing else is needed to run the application. We can start the application by doing npm run dev or yarn dev. A local server will run and manage our application on a certain port 5173 by default. All properties of Vite can be configured by adding a vite.config.js file at the project’s root.

The application can be optimized and built by running npm run build or yarn build. It creates a distribution folder, dist, which contains one HTML and js file that encapsulates the entire application. Even if we add ten more files, the output will still produce the same two files. And hence came the name of the process, bundling.

yarn build

Using Vite to build libraries

Hey, hey, hey, where did we go in the flow? We were building a library, not another single-page application. Oopsies, my bad!

Let’s add the vite.config.js file we talked about earlier. Here, we instructed Vite to build a library and also pointed to the main file of our library, as you can see below:

// vite.config.js  

import { defineConfig } from "vite";  
import path from "path";  

export default defineConfig({  
  build: {  
    lib: {  
      entry: path.resolve(\_\_dirname, "./lib/ninja.js"),  
      name: "Ninja",  
      fileName: (format) => \`ninja.${format}.js\`,  
    },  
  },  
});

Upon running the build command again, we see that now the dist folder only contains the library we want to ship — thankfully, in two flavors by default. ninja.es.js works better as an npm package but ninja.umd.js will be better as a script tag. Note that we can configure it to churn out other formats, too.

yarn build

Let's chime into the magic now. Here, we added a new demo.html file that has literally no connection to our application. We got our application working by importing it as a simple js script, not even type=“module”.

<!-- demo.html -->  

<!doctype html>  
<html>  
  <body>  
    <h1 id="name"></h1>  
  </body>  

  <script src="./dist/ninja.umd.js"></script>  
  <script>  
    const ninja = Ninja.getRandomNinja();  
    document.getElementById("name").textContent = ninja;  
  </script>  
</html>

Let’s get “modern” and use ESM build as well. Works like a charm.

import { getRandomNinja } from "./dist/ninja.es.js"; // library name later  

document.getElementById("name").innerHTML = getRandomNinja();

Though this may look similar to what we were doing earlier, on the bright side, this one import can have hundreds of files clubbed and optimized in a single unit.

Building Components

After going through all the foundational work, we are now ready to get into the real deal. Let’s imagine we are building a notification library of sorts. Calling js functions only is not going to suffice. We need to do some HTML of our own and, in turn, hook it to the user’s DOM as well.

Vite or any other build system can only bundle JavaScript as its core functionality. Our requirements have overgrown our capabilities. Anyway, let's give it a shot. We’ll make sure not to go in the same single-page application direction again.

We will display a message on the screen without end user intervention by using our own HTML. This can vary from a simple text to a self-contained application. Here’s what the code looks like:

<!-- notify.html -->  

<h1 id="ninja-notify">  
  <span>Your ninja is: </span>  
  <span id="name"></span>  
</h1>

// ninja.js  

import notifyHTML from "./notify.html?raw";  

const ninjas = \["Kakashi", "Itachi", "Shikamaru"\];  

function getRandomNinja() {  
  return ninjas\[Math.floor(Math.random() \* ninjas.length)\];  
}  

export function notifyNinja() {  
  const notifyEl = document.createElement("div");  
  notifyEl.innerHTML = notifyHTML;  
  document.body.appendChild(notifyEl);  
  document.getElementById("name").innerText = getRandomNinja();  
}

// index.js  

import { notifyNinja } from "./lib/ninja.js";  

notifyNinja();

<!-- index.html -->  

<!doctype html>  
<html>  
  <body></body>  

  <script src="./index.js" type="module"></script>  
</html>

Okay, all done. This setup will smoothly bring the component we created in our library to the consumer application. I played a trick regarding HTML files. Did you notice?

Using the above import syntax, we can inject HTML into the js file as if it were a raw string. This is super powerful in bundling because our bundler will otherwise error out, saying that it doesn’t identify the HTML file type. Makes sense, it is a JavaScript bundler, after all.

Rest assured, it builds correctly, and we get the same single-file builds in our dist folder, one for umd, and one for esm.

Demo HTML

The last piece is all about fusing our styles. CSS is a world with dozens of build systems just like JavaScript. One sane thing to do here is pray to our overlord, Vite, to manage it somehow. Luckily, Vite has a rich ecosystem of plugins (actually, esbuild and Rollup plugins).

Here, we have added one such plugin, vite-plugin-css-injected-by-js, that injects all CSS used in the library’s js files directly into the bundle, which will create a host application.

// package.json  

{  
  "name": "ninja-lib",  
  "type": "module",  
  "version": "1.0.0",  
  "description": "Library for finding real ninjas",  
  "scripts": {  
    "dev": "vite",  
    "build": "vite build"  
  },  
  "devDependencies": {  
    "vite": "^4.4.5",  
    "vite-plugin-css-injected-by-js": "^3.3.0"  
  }  
}

Adding some random styles

/\* styles.css \*/  

#ninja-notify {  
  color: cornflowerblue;  
  font-family: sans-serif;  
  position: fixed;  
  top: 1rem;  
  right: 1rem;  
  padding: 1em 2em;  
  border: 1px solid cornflowerblue;  

  border-radius: 0.5em;  
}


// ninja.js  

import notifyHTML from "./notify.html?raw";  
import "./styles.css";  

const ninjas = \["Kakashi", "Itachi", "Shikamaru"\];  

function getRandomNinja() {  
  return ninjas\[Math.floor(Math.random() \* ninjas.length)\];  
}  

export function notifyNinja() {  
  const notifyEl = document.createElement("div");  
  notifyEl.innerHTML = notifyHTML;  
  document.body.appendChild(notifyEl);  
  document.getElementById("name").innerText = getRandomNinja();  
}

Demo HTML

And it works, no doubts there. The dist folder still consists of just a single JavaScript output, which contains HTML, CSS, and JavaScript, ready to be imported into the host application with zero configuration. If you have a larger library, then it will be better to keep bundles split for performance gains.

Final Words

I hope this walk-through was somewhat helpful. There is a lot of tooling around single-page applications mainly due to the popularity of the mighty three: Angular, React, and Vue.

This guide is a bare minimum boarding point to help you explore the library. If you are/get stuck somewhere, feel free to reach out. Good luck. Craft something helpful!

Get the full code at this link.

Want to connect?

Website

Overcoming Vim-Phobia: My journey of redemption

Sameer Kumar — Fri, 06 Oct 2023 12:10:35 +0000

Hee-haw… Here we go. I have been coding for almost a decade now. And, for anyone who spends two-thirds of his day doing so, his toolchain matters. Let’s go for a walk down the memory lane. This article is going to be different.

Disclaimer: Today’s content is going to be subjective, so, please read with an open mind.

Sometime Around 2010 — Notepad Grade

I was dabbling in Notepad++ to learn Java development as a young, clueless potato. At that moment, I didn’t even understand what an editor was. To me, it seemed like a Notepad with extra buttons.

The focus was on learning programming, not DX (Development Experience). The only intriguing thing was that I could run code using a plugin by pressing one of the function keys. It gave me a big advantage over writing in Notepad and running Windows command prompt.

Key points

It's good to have a place to write and execute code together.

Two Years Later — Eclipse

I could decently code in a couple of languages now. One of the books I was reading recommended the next shiny thing, Eclipse. Eclipse had hit quite the right spot. For the first time, the toolchain was becoming addictive. The joy of coding, building, and running those Java Swing apps without diving into the build and execution system was simply… muahhh.

Internet was not big, so I often would go through offline docs and figure my way out. It got tedious at times, but there wasn’t another way out. For the first time, I wondered why this software didn’t behave like the previous one. No, I didn’t know the word IDE yet. I only knew that Java runs on three billion devices, and I had to be good at it.

Key points

It’s better if your software can handle the configuration work for you.
It’s even better if your software can tell you what to write next.

2014 — Meeting Linux and VI

I got this new blue laptop. The sticker says, “Ubuntu.” What the heck is this thing? Where is my DVD with pirated Windows and activation key written on the back of it? Went to the school library, and boy, that book on Unix gave me tremors of joy. I decided to shift to Linux permanently (and I never touched Windows ever since).

I couldn’t understand why weirdos on the internet always suggest editing random config files using something called VI. Who on god’s green earth would open a terminal, navigate to a file, and enter into that creepy vi thing from where one can’t even quit?

Sadly, it was a part of the college curriculum, and I had to write in it. The good thing is that after you press ‘i’, vi becomes “normal.” I hated it so bad that I wrote a gedit config, so my professor thought I was coding in the terminal.

Key points

Never push for a product/outcome. You may push for an idea and see if people resonate with it.
Every developer should use Linux. No exceptions. (Personal take: I also consider macOS a Linux distro.)

2017 — Sublime Art of Coding

Now, things were taking shape. I had decided my career path as a web developer. I often built small utility apps. Again, the book I was referring to told me that the Sublime is the next shiny thing. Ahoi! I was on board.

There is something about it that feels close to my heart. It was JSON configuration, and I spent the whole week tweaking things in the settings file. It was a near-magical experience to copy a JSON file on a USB drive and make my friend’s machine like mine. Lowkey dotfiles, hehehe.

At that point, my Sublime started to look like a different application to regular Sublime users. To this day, I am a hardcore ricing fan (a fancy term for customizing your software). And yes, I am immune to that pop-up asking me to buy Sublime, just like good old Winrar.

Key points

Sublime was fast for the kind of things it can do.
The only reason it “failed” was due to VS Code’s similar pitch, corporate backing, and excellent community support. Developers moved to VS Code, and no one develops tooling around the software they personally don’t use. Vim is nowhere close to Sublime's power (all mighty GUI), but the community stuck to it, and it became awesome over time.

2019 — The Rise of VS Code

I felt like I was getting ancient and even started working professionally. Sublime text was like the back of my hand now. Every keybinding and config option lived in my mind. Not to mention the plethora of extensions, well customized for my workflow.

At that point, losing my Sublime config folder was more of a worry than the laptop itself. Just kidding, I knew git by then. The office was asking to work in VS Code, so again, there were no options. Spent a month tweaking it.

In the end, I wondered what a Frankenstein’s monster I had made. It looked like Sublime, responded like Sublime married to VS Code, and started heavy like my old friend, Eclipse. The worst part was that the senior guy scolded me every time he tried debugging on my machine. Usual hacker problems, no big deal.

One thing I love about VS Code is its zero-config extension ecosystem. And it overall felt smart under the hood while coding. I could feel that it had something that Sublime lacked. To this day, VS Code has been my favorite coding software. If something can be coded, it will eventually be in VS Code. I feel it is like the modern version of emacs.

I felt the difference between strict and dynamically typed language firsthand. I worked on Ruby on Rails those days and dynamically typed languages are a nightmare for any editor. Shoot me, but I hate Ruby, Python, JavaScript, etc., even though I code in them daily for one reason. Maybe for that one reason, I knock on the doors of JetBrains from time to time.

Key points

VS Code had a vision of being an omnipresent editor, and the community made it happen.
Its core is rigid and well-thought-out, on top of which people make what they want.
Its blessing proves to be its curse. Since anybody can easily write anything, people write them without much thought and later blame VS Code for being slow.

2021 — Oops, I Have a Bit of a Perfection Problem

What’s this OCD-looking thing, you ask? It’s a condition where you are a bit too strict about how things should be. You may say, wow, that’s a good thing, but then if your table’s edges don’t match your laptop’s, you get a shiver of anxiety.

Also, I get distracted fast, so I need a focused environment. I left this article to get the above image, and now I am back after reading about the movie this meme came from. OK, cool, we are on the same page now. See, we aren’t much different after all!

I like both environments, outside and inside the laptop, to be ultra-mimal. Check out the screenshots at the bottom of this page; there aren’t even close icons on application windows, if possible. From letter spacing in fonts to the inner padding of a popup, everything is a trigger. To be honest, it makes me happy to do this kind of stuff, and if you search for “Unix ricing,” you’ll get blown away.

On the other hand, literally on the other hand, I started getting wrist pain due to constant jumping from letters and arrows. Grinding 80 hours a week comes with its own perks. 😅

I was googling about this wrist pain condition, and funnily enough, one of the tips was to use Vim (-mode) on your computer. That sneaky VI, I couldn’t even understand was the same thing until I opened it. I had some residual hate towards it.

For server work, I was using Nano. Later, I moved to micro, which was closer to VS Code bindings. Every stunt it takes to avoid my arch nemesis, Vi. I realised that literally every tool I use has that weird Sublime and VS Code hybrid keybindings.

Gosh! I hate myself. Can’t even use another person’s computer running a pure version of that software. To support the no terminal mindset, over the years, I forgot all my appreciation for awk, sed, grep, etc. Things needed to change; I couldn’t live in this denial.

Key points

Do what you enjoy and not necessarily what keeps you abstracted from the real problems.
Everybody spends time in denial. It's normal as long as you are ready to come out of it after realization.
Learn core (gnu-) Linux tools. You’ll understand the benefits in the long term. For example, I’d have been much better at regex if I had just continued using grep and sed for finding and replacing.

2022 — Adopting Vim Motions

For the first month, I used nothing more than hjkl.

I resolved to use Vim. Not because it’s any better for my specific workflow but because I wanted to break my dependency on VS Code.

I knew I couldn’t drop into Vim for my day job. So, I settled on the middle ground of using Vim bindings in VS Code. Courtesy to a YouTuber called Ben Awad, who showed this peaceful path of adopting Vim. I always wondered how he could magically teleport to random places when I could only move there really fast.

On the safe side, I’d automatically turn it off in all my office project folders. Nothing in Vim particularly amazed me then because I had a similar shortcut in mind for VS Code. Yet, the constant tussle between both was getting hard. By the end of the year, I could fluently navigate in VS Code using Vim keybindings. After almost a year of usage, I started seeing the ergonomic and functional benefits*.*

Key points

Be practical, you son of a gun. Learn to walk before you run.
Temptations to achieve what others flash is a good motivation. Personal willpower won’t be enough to explore unchartered territories. We need some rocket fuel to kickstart the process.

2023 — The Final Migration

It was darn stupid of me to think that one day I’d uninstall VS Code and move to Vim someday because I could navigate there similarly. I didn’t realize I was using Vim bindings for doing VS Code things; the workflow part was still a miss. All that I learned was a few keyboard shortcuts.

I moved anyway. One day I had to find and replace a few words in a project. I couldn’t do it, so welcome back home. VS Code, at this point, had become my identity. I could fly through code blazingly fast in VS Code, and my friends knew me for that. So I settled back in, leaving Vim.

I was happy I could do whatever those Vim nerds could do, yet I knew I was still in a big comfort zone bias. My problem was that I was using VS Code with a hybrid keybinding, and now I replaced even that with something else. What kind of a solution was that?

Luckily, I got a break from office project work sometime back, and I knew this was the chance to transition my configs. I realized I had no trouble in moving from Sublime to VS Code; it was a happy process. I started working in raw Neovim, and yeah, it was painful, but I had a plan. Whenever I missed something, I would “read Neovim docs” and add it.

Makes me happy I understand and have written every single line of my editor config myself. Took two months but now I have my own sweet little PDE (Personal Development Environment).

This covered everything from default indentation size to a file tree to language servers. Earlier, I watched a YouTube video from ThePrimeagen on Neovim setup, and it overwhelmed me so badly that I had to take a week’s break from thinking about my own configuration. 😂

Key points

Acknowledge the iceberg theory. One gets attracted to what floats and not the work it will take to create and understand the base. My suggestion, if you ask, is simple. Respect it!
My biggest motivation for making the final switch was the aww factor surrounding Vim as a software. All you see in the screenshots below is text on a terminal window, no images, no real buttons, and no GUI of any kind. They aren’t even real icons. It’s really hard. Imagine you can’t even change the fonts or the size of it. Every single thing is carefully manipulating text on a black terminal window. That respect for the people who build it keeps me going.

Today

Now that I have fully moved my workflow to Neovim, it doesn’t even feel any different. I was already used to Vim bindings, only the aesthetics have changed. Yet the good part is I understand how these moving pieces work. I understand how that in-line error message shows, from where these fancy auto-completions come, how each line gets formatted, and much more. Looking back, I could have peeped into the source code of VS Code or its extensions, but the mindset was to use it and not learn it.

The biggest shift is that I look at software in general from the mentality of the builder rather than a consumer. Now, when I see something, I ponder how to build it rather than use it.

After all, I am an engineer and my identity revolves around two main things: how well I understand softwares and what I (can) build

Some Snaps of My Coding Setup

Terminal using iterm2

Neovim landing page

AI code suggestions

Language-based completions and documentation

Fuzzy file and content exploration

Change tracking (can rollback to things changed days ago, no git needed)

Unfortunately, I can’t go through every screen and utility, but if you like the setup, I can write an article on how everything is set up from scratch. A detailed tutorial of sorts on the basics of terminal and Vim customization. Do drop a comment if you’d like me to.

FAQs

Will using Vim make me a better developer? — Yes, I take the guarantee.
How hard is the transition? — It’s pretty easy. Just a few hundred keybindings, lol. (I have a super secret ninja way to learn them all in 30 minutes)
Why does it even matter? It’s just an editor. My work goes with what I write in it. — You want to be an engineer or a writer. Figure out fast! Good that you chose engineer. Now think again: how many fundamentals of engineering do you get exposed to that your day job abstracts from you. You don’t want to be an engineer with a weak core, do you?
It seems too hard to get started. Will I grab it? — Took two years, multiple quits, and it only worked when I started from scratch and incrementally added functionality. It’s your child now. You won’t say anything bad about it. Remember that you don’t choose your interests; you raise interest in things you put effort into.

True Story…

Want to Connect?

Website

JetBrains Fleet — A VS Code killer?

Sameer Kumar — Wed, 19 Oct 2022 07:41:15 +0000

An excellent lightweight polyglot IDE from JetBrains.

JetBrains is pure love. It doesn’t matter which code editor you use but a few things are always of personal priority. For me, it’s aesthetics, speed, and intelligent suggestions. Extra point for aesthetics 💛.

I used to be a long-time Sublime Text fan. Then it faded into oblivion and I packed my bags and moved to VS code which has the above three in ascending order. Still, nothing beats my experience with JetBrains IDEs, especially RubyMine while I was working on ruby on rails development. The only thing that taints these gorgeous IDEs is the speed, primarily the time to get interactive.

JetBrains’ answer to most of its problems is Fleet.

Fleet is targeted to be more of an intelligent editor than a full-blown IDE. And I consider this a good thing because most of the time we don’t want all those nuclear features packed inside the IDE to manipulate a few lines of code and get decent IntelliSense. When I installed fleet for the first time, I was a bit skeptical because I thought I’ll be losing all the good parts of IDE but after using it for a couple of days, I can say that all that power is not needed in day-to-day uses.

Things I liked in fleet ❤️

Aesthetics

JetBrains fleet editor

If you ask me one thing I don’t like about VS code, it will be the look and feel. It's no surprise that VS code can be customized to the very extremes using the plethora of extensions but still, it feels very plasticky to me. Earlier I thought it was just me, but when I asked a couple of my friends who are longtime users of JetBrains, they also seconded that JetBrains IDEs offer a more sturdy look and feel.

Fleet takes the old IDE inspiration and conveys it in a modern design language. The new design is extremely fluent and distraction-free. The application itself is divided into four panes.

The first pane is on the left side and is divided into three tabs featuring a file explorer, version control, and commit history. Upon selecting the pane each of these three subsections can be easily navigated using keyboard shortcuts. The presentation and navigation felt buttery smooth and they just work.
The second pane is at the bottom and can host different views, including terminal, run logs, docker, etc. which can be selected from the drop-down presented there. It’s totally up to us what we want to see, maybe in the future, there will be custom views as well.
The third pane is on the right side and can contain the same views as the second one. It can be used as a secondary panel, but in most cases, I think I’m better without it still, it’s nice to have when screen real estate is not a limitation.
Apart from these, the main editor area itself is quite a distraction-free, accessible, and clean-looking view. Looking at the customization side of things we can change the theme, font, and other common attributes. The application theme ties itself to the system theme pretty well and the defaults are well-designed.

KeyMaps

Fleet keymaps

“Thou shall leave your editor but not thy keymaps”

Coming from a different editor, the biggest challenge is getting your muscle memory of keyboard shortcuts transferred but here almost half of the keyboard shortcuts were already aligning with VS Code, and it took me around 15 minutes to map other shortcuts as per my liking.

Being a keyboard-driven power user I find a lot of things missing from IDEs as well as VS Code. The very first thing I noticed was not being able to move to a tab by using command plus number keys but again we are just looking at the preview version and these things will be integrated when it comes to the real release or a plugin will tackle it.

Overall keyboard navigation was very responsive including the find files and actions part, even in a large-scale project containing thousands of files. But, then it's JetBrains, their whole core is dedicated to fueling enterprise codebases.

Fleet palette view.

DX ( Development Experience )

DX = Happy Developer

It can look and feel good, but at the same time, it can be a waste without solid development experience. Thankfully, it’s going on the right track here. It’s not the time to evaluate the finished product as it’s not finished yet, but we can get a clear direction in which things are going to move.

The editor managed to be a super fast experience by turning off IntelliSense by default, but it can be enabled with a simple click on the bolt in the top right.

The smart mode in the fleet editor.

It starts as nothing but a notepad, and on clicking the smart mode toggle it pulls in enough power to provide you with some good-quality intelligence for mid-weight development. We can do all those familiar things like jumping to the declaration, finding usage, global find using regex, etc. The visual presentation of content and mapping of controls is welcoming to both JetBrains and VS Code users.

Cloud-enabled features in JetBrains fleet.

A more worthy feature in the fleet is its remote backend. Use the power of virtual machines in the cloud to build your app and run Fleet along with the IntelliJ code-processing engine. It solves the “IntelliJ is too heavy to run on my tiny machine” problem by pulling all the fancy stuff in the cloud and you have only the code local while keeping bulky intelligence features in the cloud.

Pros and Cons of JetBrains fleet editor.

Let’s take a break from our walk in the garden and be slapped in the face with a brick called reality. Although it is still in preview and the vision is not solidified yet but few things are crystal clear. I am listing two things below which in my humble opinion may not work in favor of the fleet vision.

Things that scare 😱

Not a Free and Open Source Software ( FOSS )

Open source software.

It's not a surprise that JetBrains will keep the code closed as it did with all other products it built so far. But, the fleet is not on the same lines as creating highly specialized enterprise-grade software that sets benchmarks in the industry.

Fleet extensions framework.

Jetbrains themselves can not make the Fleet a polyglot system and it will be in the product’s best interest to offload the work to the community which specializes in a particular language and framework. As of now, there is no extensions framework but it's in the pipeline before the final release.

But, even when it lands, a small dev community sitting behind a paywall can not make a rich ecosystem like vscode. We have seen other IDE products from JetBrains and the range of extensions is very low.

I don’t sing of charity here but if the competitor is offering everything for free, the motivation to switch gets automatically low.

Not as lightweight as it says on the label

JetBrains Fleet resource consumption.

JetBrains environment running this fast is never heard of. I was pleasantly surprised when I stressed it with big codebases and everything worked with the same fluency. Then I looked into the system resource consumption and it wasn't much to be proud of. Have a look yourself.

JetBrains Fleet vs VS Code performance benchmarks.

For context, I have the same mid-size angular application running in both editors with just two files open and the server running in the integrated terminal.

As promised Fleet and its backend are running separately. But, the memory consumption is too high for it. To add to it I have at least 30 extensions added in the VS Code and the Fleet is fresh out of the box.

I have a beefy MacBook M1 Pro with higher specs than an average user. So, I can not justify that someone on a weaker machine will get the same speedy performance despite such resource usage.

Conclusion

Now that we have seen both sides with equal enthusiasm, it will be good to summarise this review with a non-opinionated summary. I must say, the fleet is what I was wanting for years but for others, it might be yet another shiny object. JetBrains has an IDE for almost every language and Fleet is an attempt to move in the polyglot direction. Since both of these are targetting different communities, it’s tempting to put them in the category of android vs apple comparison. On one side you are getting something extremely versatile and flexible but on the other side, you get a very refined and polished product best suited for the existing ecosystem users.

🤝 Want To Connect?

LinkedIn: https://www.linkedin.com/in/sameerkumar1612

5 must have softwares for pros like you.

Sameer Kumar — Fri, 07 Oct 2022 09:37:13 +0000

I have been using Linux for many years and am amazed that there is a tool for every use case. The same goes for MacBook as well, there is a plethora of free tools that will make you more productive and at the same save a lot of frustration coming out of repetitive manual work.

Meeter

[Meeter

We will get out of your way, so you can get done what needs to be done. Our simple and minimalist macOS app allows you…

www.trymeeter.com
](https://www.trymeeter.com/)

Meeter is a tool which sits in your top bar and sends you a quick join popup when a meeting starts. It works with almost all meeting solutions, including google meet, Microsoft teams, cisco webex, etc. I can not simply live without it. I came to know about this one out of very particular frustration about google meet.

And, here it goes, like every sane user I had more than 5 google accounts logged in my browser, and whenever I used to click a meeting link, it would join by the default account, and then the chain of frustration starts. Meeter tracks your on-device calendar and ensures that when you click the join button, you are joined through the intended account.

No more missing the call, because it keeps running a countdown timer in your top bar. Optionally it can also display the meeting title as well.

Countdown to the next meeting in the top bar.Meeter — https://www.trymeeter.com/

Bandwidth+

[‎Bandwidth+

‎* Track your Wi-Fi hotspot usage. * Zero configuration required. It just works. Bandwidth+ is a simple app so only…

](https://apps.apple.com/us/app/bandwidth/id490461369)

Working from home on a limited internet connection is a big challenge and I had to track the speed and usage constantly. This small tool comes as a full package solution for such use cases.

Even if you are on the better side, at least it can help you decide when call quality goes down, then whom to blame. 🎃

Bandwidth+ — https://apps.apple.com/us/app/bandwidth/id490461369

Fig

[Fig

The terminal is a sensitive environment. All cloud features are opt-in and your data is encrypted at rest. For…

](https://fig.io/)

As an engineer, I can not live without a terminal, or rather say most of the time I live in the terminal. Fig comes in handy by suggesting the next commands very intelligently and aesthetically in form of a dropdown.

These commands are context-aware and for most parts cover all daily use cases. To some extent, it serves as live documentation in the terminal.

Fig — https://fig.io/

Photopea

[Photopea | Online Photo Editor

Free online photo editor supporting PSD, XCF, Sketch, XD and CDR formats. ( Adobe Photoshop, GIMP, Sketch App, Adobe XD…

](https://www.photopea.com/)

Now and then, there comes a need to make a quick header for my blog or trim 2px from the logo I am supposed to put on a website. Since I am not a creative designer or photographer by profession, it doesn't make sense to use a full-blown Adobe product.

For the long period that I used this free product, I never felt the need to get photoshop installed. It will cater to all typical use cases of photoshop in a familiar layout without costing a penny. I encourage donating if you can to the good cause of bringing such a good photoshop alternative online.

Photopea — https://www.photopea.com/

Top Notch

[TopNotch for macOS

TopNotch is a little macOS app that makes your menu bar black and hides the notch.

](https://topnotch.app/)

Makes the notch disappear like a 🥷.

Macbook M1 Pro brought a good camera system but in turn gave me the biggest OCD ever, THE NOTCH. It started getting quite distracting and then I found this application that smartly hides your notch and gives realistic-looking rounded corners as well.

TopNotch — https://topnotch.app/

Want To Connect?
LinkedIn: https://www.linkedin.com/in/sameerkumar1612

React 18: When to use “useImperativeHandle” and “forwardRefs”

Sameer Kumar — Tue, 13 Sep 2022 11:54:11 +0000

Sometimes, you have to take out the big guns

This article is a continuation of https://betterprogramming.pub/react-v18-demystifying-useref-forwardref-and-useimperativehandle-feec2fc5b2f6 where we saw what refs are and how they operate. With the knowledge gained from the previous article, let’s dive into a little more complex understanding, which can come in handy in real-world projects with a lot of component nesting and a bit of real DOM-based needs.

Forward Ref

What’s a solution without a problem, right? So, let’s define a situation where regular refs can not get the job done. What if we have a parent component that wants a reference to one of the elements defined in the child component and modifies the focus state? Let’s create such an example.

The parent component controls the focus of the button defined in the child component.

As you can see above, the parent component controls the focus on the child component’s button. It is not as simple as passing the ref defined in the parent as a prop to the child. In our case, ref is a special property defined on the exact HTML element whose focus is to be changed, not the child component wrapper, as it’s just a function.

We can attain the desired behaviour by wrapping our child component into a forwardRef function provided by React, which will handle this delegation. This function should transfer the sent props and allows one extra prop on the component, that being our “ref.” Here’s the code:

useImperativeHandle

Well, seemingly, what we achieved in the previous section is enough for even complex situations. Still, at times you may be tempted to define a custom ref functionality inside your component, which will be exposed to components using it. Let’s try to create a situation where we need such fine-grained control.

By default, the focus colour on input is blue but let’s say if our ninja is supposed to get a supercritical jonin level mission, then the input field should focus on red instead.

The parent component can control which colour the child’s input focuses on.

To illustrate the use of useImperativeHandle in this case, let’s divert from common sense and build two custom methods tied to the input component through ref. Instead of the default focus method, this time, we’ll have two custom methods focusRed() and focusBlue().

We’ll still need to use forwardRef to pass on the ref to the child component, but inside the child component, we’ll create these new functions with the help of the useImperativeHandle hook. Here’s what the code looks like:

One important thing to notice is that in the code above we are not extending the methods available by default as in previous case but creating totally a new set of methods. So, the _default focus()_ method is no more available to us and calling it will give us sweet errors.

The focus method is not available when using the imperative handle.

Conclusion

To sum up, I’ll repeat what I said in the previous article: Refs to DOM themselves should not be used when doing a virtual dom-based development because the changes you make in the real DOM don’t get properly transferred to the vDOM setup, and that leads to unexpected reactivity.

I chose focus as the central topic for this article just because it’s one of the main needs when refs need to be summoned. React mentions a limited set of use cases for refs, which you can see here: https://reactjs.org/docs/refs-and-the-dom.html#when-to-use-refs.

Want To Connect?

LinkedIn: https://www.linkedin.com/in/sameerkumar1612

React v18: useRef — What, When and Why?

Sameer Kumar — Fri, 22 Jul 2022 12:05:34 +0000

Part 1: Taming React’s necessary evil — useRef

The concept of values and references is not new to any programmer. Values are what the name suggests, simple snapshots of data at a point in time. To jog your memory for the latter, references are pointers to some data which may change over time, but the reference itself remains the same. Think of it as a house’s address; the address always remains the same, although the house may renovate to a new one over time.

React highly recommends thinking in terms of UI = function(state). This simplification can handle maybe 99% of what we were used to doing with the traditional DOM-based paradigm, but the final 1% needed some plumbing.

The React team left an escape hatch for such situations in the form of the refs. IMHO, refs are a necessary evil that helps us take the liberty of solving problems for which React itself can’t provide solutions due to its data-driven design philosophy.

Since refs can get pretty complex to understand. We’ll cover three areas mentioned in the title separately. For part 1, we’ll understand what React references are and how to use the most fundamental useRef hook. In the upcoming part, we’ll cover more complex examples and use cases.

useRef

==========

Starting with the most basic implementation using the useRef hook provided by React. Let’s think of a situation that doesn’t need fancy DOM latches but a simple number to reference outside React’s state system. Our application is going to be a super simple counter app.

Component re-renders when updating the data contained in the React state.

It’s no rocket science to infer from the console logs that our component is rendering again for every change in the num value, which may be a nightmare come true in a complex production application.

Let’s try bringing in the ref to the picture and see how it performs. We will bring a number here which should not change between re-renders, and also, it should not cause a rerender if its value changes.

React refs persist data across component re-renders and don’t cause re-renders when updated.

As we can see from this example, our application can retain the random value stored in the ref variable even if the component is rerendering due to clicks on the increment button. The key takeaway from this experiment is that the referenced value is independent of the component lifecycle here.

Let’s go for a more practical example where you will see refs being used in real applications. In this case, we have an HTML input element, for which we want to see if it’s blank. If yes, then we put some random value there.

React believes in the unidirectional controlled component strategy, which says inputs should be tied to some state, and what we see in the input should only be generated through a change in the linked state. In our case, we will not have any state linked to it. We also don’t want to go ballistic by putting an id and starting with a document.getElementById like the old school way.

What we can do is use a ref as a pointer to this DOM element and control its value from within React. Let’s take a look at the following code:

Refs help us to control any DOM element on the page and interact with it outside the React way.

From the above demo, we can see that the input is populated the first time itself, and that too without accessing the real DOM API directly. Our inputRef is serving as a pointer to the input DOM element, using which we can manage its properties directly, bypassing the React’s state system.

Managing form using refs is often discouraged as it kills the whole reason behind using a state-driven library like React.

Let’s look at something which is more suiting for the use of React refs. Imagine we loaded a form, and we want to automatically move focus to an input field for achieving UX brownie points. We can take the above application, for example, and use refs to focus the input field on load. This can be a welcoming feature that forms loads, and you know what to begin with. In the golden era, this could also open your mobile keyboard, but it is now blocked due to security and user preferences.

Focus input field using React refs.

The Dark Side

=============

If something this powerful is presented to programmers, how could they not abuse it? But, just because we have a ton of parachutes, it doesn't mean every day is a skydiving day. Refs are meant to be used in cases that need direct dom, such as our above example. The first counterexample is also something that can be handled with caching using the useMemo hook.

React warned us from starting against accessing DOM directly in a virtual DOM system. The biggest concern is predictability. The uni-directional data model in React will not respond if something directly changes the DOM element without properly notifying React.

In our case, if we make a small timeout trigger that will change the data directly, we will lose the notification to the other component we defined for a controlled change. We can see the message in the lower paragraph tag has not been updated after the ref changed the value.

Value updated directly by using ref in a 2-second timeout broke our application.

Conclusion

==========

We have gone through enough examples to understand how refs can help us and what we should look out for. In the next part, we will look into some more complex use cases which may come in handy for a bigger application that needs cross-component communication and passing refs to other components.

Want To Connect?

LinkedIn: https://www.linkedin.com/in/sameerkumar1612

The Boy Scout Rule 💡👩‍💻

Sameer Kumar — Mon, 23 May 2022 14:06:27 +0000

This post is going to be a little different.

Most engineers have heard of the 'boy-scout rule': 'Always leave the code better than you found it.' It's often been heralded as a magic cure for technical debt; if only all software engineers behaved like good citizens, our software wouldn't deteriorate so relentlessly.

A small snippet from an office talk describing impact of it on real projects:

Sameer Kumar on LinkedIn: Sameer on coding standards

👩‍💻 Most engineers have heard of the 'boy-scout rule': 'Always leave the code better than you found it.' It's often been heralded as a magic cure…

linkedin.com

Audio snippet:
// Detect dark theme var iframe = document.getElementById('tweet-1528731583473065985-428'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1528731583473065985&theme=dark" }

What you think about conscious negligence and voluntarily clearing technical debt left by previous engineers?

Quote referred from: Here

To Connect

🏭 LinkedIn: https://www.linkedin.com/in/sameerkumar1612
✍️ Medium: https://sameer-kumar-1612.medium.com
✍️ Dev.to: https://dev.to/sameer1612

React v18: Why useEffect suddenly go crazy?

Sameer Kumar — Sun, 22 May 2022 06:32:52 +0000

React version 18 has brought some very appreciable changes to the core. One such bittersweet change is in for form of the mount -> unmount -> remount pattern of loading components in strict mode. If you have not tasted this first hand, be prepared because at first glance it seems some sort of dark magic on your happily working application. Let’s dive.

Problem

Let’s take this fairly simple code for example. Judging by the empty dependency array in useEffect, we can expect “App Loaded” to be printed once in our console and be done with it.

If you are confused with the use of this console.count method, do read here: Awesome console methods.

Surprisingly, we are seeing this message being printed twice. That raises the question, are we doing something wrong or is react drunk today?

Background

To understand this whole mess let’s discuss first the concept of pure functions and idempotence. The following illustration is self-explanatory and we can see that under the same conditions, a function should produce the same output. Whereas, idempotence means that even if a function runs multiple times, the outcome should be the same.

Well, you must be wondering what it has to do with our problem in hand with react. Take a practical example, we intend to subscribe to a stream of notifications coming from a certain server and we keep it in useEffect expecting it to subscribe ONCE the user opens our website, using the empty dependency array for the purpose. But, as established in our little demo, code written in useEffect ran twice and hence will our subscription. Possible outcomes can be:

We are showing two or more notifications, depending on the number of times our component is rendered. [Application level pure behaviour is no more present, sometimes showing 1 notification, sometimes 83.]
Our subscription server may throw an error that, “You are already subscribed”. [Idempotence cries in the corner.]

Solution

Enough mathematics for the day, let’s look into the fix. “The fix” is essentially sticking to the best practices. I found many online resources, suggesting custom hooks to replace useEffect hacked with using ref and whatnot. Frameworks tend to make our life easier by abstracting decisions and we launch full-scale battles for finding ways to sneak out. Effect always provides a cleanup function which should be used to clean the work done during the effect run. It can be used to do the unsubscription in our hypothetical example. Looking at our previous example, it should be like this:

Conclusion

The react team decided to bring strict mode to these hooks for establishing best programming practices during the development phase. As in the case of our useEffect, this double mount saves us from many unseen issues that can come into the production later as we saw in our subscription example. Also, take note that React doesn't do this mount — unmount — mount cycle in an actual production build, it’s a dev mode feature provided by using the StrictMode tag in the index.tsx for the sole purpose of imposing best practices.

StrictMode in react.

To Connect

🏭 LinkedIn: https://www.linkedin.com/in/sameerkumar1612

✍️ Medium: https://sameer-kumar-1612.medium.com

✍️ Dev.to: https://dev.to/sameer1612

Console.log and his Ninja Pals 🥷

Sameer Kumar — Sat, 21 May 2022 07:57:02 +0000

Swiss knife of javascript ninjas, our beloved console.log has some lesser-known yet more powerful variations. In this blog, we’ll explore some methods with examples which I find very useful in day to day debugging and scripting.

The console object provides access to the browser's debugging console (e.g. the Web console in Firefox). The specifics of how it works vary from browser to browser, but there is a de facto set of features that are typically provided everywhere. It provides a set of methods and formatters to show information in the browser console in a more user-friendly way depending on the type of data being passed to the specific method. Since everyone is already familiar with thelog method, we’ll look into the rest.

console.count()

The count method can be used to display the number of times this message was shown on screen.

console.error()

The error method is the correct way to log error messages to the console, which uses browser tooling for proper representation of the error and semantically justifies the log. Also, you’ll find count on top of the console reflecting the number of errors [ x 2 ].

console.table()

The best of all the methods and my personal favourite. Really useful to debug API responses which contain an array of 100s of similar objects. Instead of opening each and looking into them, we can have a flat tabular representation.

console.time()

A quick and dirty way to measure the performance of your javascript code. You can get a benchmark of some intensive operations or find which operations are taking the longest in a chain using this method.

Woah! Javascript and new macs are fast!

console.trace()

When things get serious, you may need to solve the chicken-egg problem, ie, which method was called first. Especially troubles get more troublesome when playing the async game.

console.warn()

A semantic way to handle non-nuclear threats thrown by your application. A possible use case can be if your user is about to hit a certain limit, you can log some warning messages, until finally throwing an error. Or, most commonly seen in deprecation warning of certain functions.

console.asset()

Sometimes it's not worth logging every time. Maybe say, we are tracking mouse movement and need a message if the mouse cursor moves outside a box. To help in such situations, assert does conditional logging whenever the provided condition in the first parameter is false.

Conclusion

So, ninja pals, today we have learnt about many ninja tools that the console provides us with. These methods can make our stressful debugging moments a little bit happier and add a lot of semantic meaning to the power of almighty console.log(“Live Long and Prosper…”).

To Connect

🏭 LinkedIn: https://www.linkedin.com/in/sameerkumar1612
✍️ Medium: https://sameer-kumar-1612.medium.com
✍️ Dev.to: https://dev.to/sameer1612