Forem: aderchox

What is "the time"? ⏳ ...and what is meant by UTC in date.toUTCString()?

aderchox — Wed, 31 May 2023 23:51:12 +0000

Background

Pretty much in all major programming languages there's support for working with dates and times. JavaScript for instance, has a Date class for this purpose, and this class has many methods. Among all of these methods though, one is toUTCString(), which I happened to have encountered a million times, and yet had no clear understanding of it (well, of course, before Googling and writing this article).

Checking its documentation on the MDN first, we'll see:

The toUTCString() method converts a date to a string, interpreting it in the UTC time zone.

Hmm... so UTC is a time zone! Just like Greenwich (GMT), so let's Google it to see how it's different from GMT:

Coordinated Universal Time or UTC is the primary time standard by which the world regulates clocks and time.

Well, but that sounds a lot like GMT!?

So I Google GMT vs UTC next:

Prior to 1972, this time was called Greenwich Mean Time (GMT) but is now referred to as Coordinated Universal Time or Universal Time Coordinated (UTC).

Hmm... that's odd! It cannot be just about a "rename"!

What is the difference between GMT and UTC really?

Although this is not a coding question, programmers bump into it pretty often, so a non-programming and easy to understand answer to it would be worthy.

In simple terms, we can assume that both GMT and UTC are "clocks" that tell us "the time", however, UTC is the more precise one, so it took GMT's place in our measurement of the time around the world (in 1972).

But wait, what does "a more precise clock" mean at all? To understand this, we need to understand what "the time" itself really is in the first place!

What is "the time? ⏳🔮

Time (in its today's form, i.e., months, days, hours, minutes, etc.) is a human-made thing, and is our "means of measuring the passage of events". Say you're planning a programming event next month. What is next month? So you need to have an a shared and wide-spread understanding of the time (the amount of the passage of the events) we all consider "next month"!

Our today's shared understanding of "the time" is the result of a convention/agreement our ancestors left for us: They searched for some regularly recurring event, and they initially found it in the change of day to night, and in the change of seasons. (If you notice, these are astronomical events, i.e., rotation of the earth around its own axis, and sun's position in the sky. This is what the GMT clock (timezone) uses to measure the time). But there was still room for improvement:

The measurement of time began with the invention of sundials in ancient Egypt some time prior to 1500 B.C. However, the time the Egyptians measured was not the same as the time today's clocks measure. For the Egyptians, and indeed for a further three millennia, the basic unit of time was the period of daylight. source

So basically, you could tell someone "I'll see you tomorrow", but you couldn't tell them "I'll see you tomorrow at 7:30"! :D

So the next [obvious] step for them was to make their measurement of the time more precise, and as a result, they agreed (not surprisingly) to divide each full day into 24 parts, aka "hours", and they agreed to divide each hour into 60 minutes, and so on. So today you have something called "a clock" that allows you "to universally keep your understanding of every point of the past, of the current and of the future events in sync with others", therefore you can happily plan your event next month, without an issue (well, without a "temporal issue" at least!) 🕙🕜🕞.

Why was UTC needed then? UTC was needed for the exact same reason, it was a further step in this interminable road towards our unquenchable thirst for more and more precision. As we've said above already, GMT used some not-stable-enough astronomical events to tell us the time, i.e., events not as precisely regular as we expect to set as the basis of our modern agreement for measuring the time.

Don't get me wrong, actually, the GMT clock is still good enough for numerous purposes, but it's just like a ruler that measures in units only as small as millimeters, while we need greater length precisions as well definitely once we get into realms like engineering, science and so on.

Here's where UTC comes in wonderfully. UTC measures "frequency of an atom's vibration" (*), and that happens to be a much more stable and regularly recurring event compared to things like earth's rotations or sun's position in the sky. Indeed, we're talking about 1 billionths of a second per day v.s up to a few minutes per day! So no wonder UTC can keep us in sync in a much more reliable way.

That's it, ...for the most part! If you're a curious mind, there's still one more delicate (and important) point we've missed to mention here. If you think about it, UTC is great in terms of its precise measuring of the time, however, it also creates a (minor) issue: We actually do care about what a full day is! This is regardless of how we measure the time! No matter how accurate a clock is, no matter how precisely it keeps us in sync to each other, we do not like it to make our days dark and to make our nights bright! (with a bit of exaggeration). So we need to occasionally adjust the UTC clock, and this is exactly what we do, using a second aka a "leap second" to . From Wikipedia:

A leap second is a one-second adjustment that is occasionally applied to Coordinated Universal Time (UTC), to accommodate the difference between precise time (International Atomic Time (TAI), as measured by atomic clocks) and imprecise observed solar time (UT1), which varies due to irregularities and long-term slowdown in the Earth's rotation.

- (*) Disclaimer: I'm neither a Physicist nor an Astronomer, and these topics are very complicated, so this answer should have some inaccuracies naturally. If you need a deeper and more accurate understanding, read further in this answer on Physics Stack Exchange.
- Cover Image from Unsplash by Lukas Blazek.

What is the DEBUG 🐛 environment variable in Node.js, and how to use it?

aderchox — Tue, 04 Apr 2023 13:44:51 +0000

(The credit for the cover image goes to coralogix)

You might have seen a command like this while navigating in Node.js projects:

$ DEBUG=myapp:* npm start

For example, in Express, you might see:

DEBUG=express:* node index.js

So what is it?

Although it's used by Express, it's indeed more broadly, the way a popular NPM package called debug works, which is used internally in Express too. Under the hood, the debug package expects the DEBUG environment variable to determine what debug messages to print (could be on the console, or into a file, or into stdout to be collected by a log aggregator service).

In case of Express specifically, to see all the internal logs used in it, we could set the DEBUG environment variable to express:* when launching the app. E.g., on Linux, run:

DEBUG=express:* node index.js

Or to see logs only from the application implementation, run:

DEBUG=express:application node index.js

The syntax used in both of the above commands (FOO=bar command) is the general Linux-y way of defining a one-off environment variable exclusive to only a single execution of a command, i.e., will only be accessible to the command and only at that single time. It's very beneficial that it's a one-off thing, as it won't pollute the environment variables' global space unnecessarily).

debug is like an augmented version of console.log, but unlike console.log, we don’t have to comment out debug logs in production code. Instead, logging is turned off by default and can be conditionally turned on by using the DEBUG environment variable.

You can also specify more than one debug namespace (whether regarding Express, or regarding any other modules by assigning a comma-separated list of names:

DEBUG=http,mail,express:* node index.js

If you wonder what a "namespace" is, it's again related to the debug package, for example, consider this snippet:

const debug = require('debug');
const httpServerLog = debug('http:server');

What is that 'http:server'? It's simply the flag/namespace for that specific logger that you will pass to the DEBUG environment variable in order to turn ON the debugging. So now you could do:

const http = require('http');
http.createServer((req, res) => {
  httpServerLog(req.method + ' ' + req.url);
  res.end('debug example');
}).listen(3200, () => {
  httpServerLog('listening');
});

And to enable the above logs, the "http:server" namespace has to be enabled, so we'll do:

DEBUG=http:server node app.js

You could check the package.json of any 3rd-party packages to see if they've used the debug module or not, and if they have, you could check the namespaces they've defined and pass them using the same method (of passing the DEBUG environment variable to pass the desired namespaces) to see their logs.

Read more about the "debug" package here and here.

Hey, you're also invited to join our small and fledging 🐥🐣 Discord community called TIL (stands for "Today-I-Learned") where we share things that we learn with each other, in the realm of web programming, using this link.

Thanks for reading this article 👋 You're very welcome to suggest any fixes or improvements in the comments section below.

Create a pure Node.js and TypeScript app + Getting node-fetch ESM-only (version 3) up and running

aderchox — Thu, 16 Mar 2023 19:22:30 +0000

Introduction

Node.js is a browserless (server-only) runtime environment for JavaScript apps, node-fetch gives Node.js apps an API similar to the browsers' standard fetch() API, and TypeScript provides static typing which is cool. In this article, we're going to bootstrap a project that glues these three together.

node-fetch version 3 is ESM-only

Node.js apps used a module system called CommonJS in the past (modules in this system are imported like this: const x = require("/path/to/module");). ESM system wasn't a thing yet then, but since its emerge (first in browser environments), Node.js has also started the transition (which has some benefits compared to CommonJS system, and its imports are like this: import x from "/x.js").

Since the release of Node.js version 14 in April 2020, it has had stable support for the ESM module system. So no wonders package authors have also tried their best to keep up to speed with this transition and have provided ESM support for their packages too.

Usually, package authors support both these module systems (despite the difficulties of doing it, e.g., automating, maintaining, bugs, etc.) for the sake of backwards compatibility, however, among all packages, there are also ones whose authors have pulled the future close to "now" faster..., and are offering "ESM only". fetch-node version 3 is an example of these ESM-only packages.

The Steps

1. Create a directory for the project, cd into it, initiate a Node.js project, and install TypeScript and node-fetch packages:

mkdir ts-node-fetch-app
cd ts-node-fetch-app
npm init -y
npm i typescript node-fetch@3

2. Create app.ts:

import fetch from "node-fetch";

type Todo = {
  userId: number;
  id: number;
  title: string;
  completed: boolean;
};

async function fetchTodo(id: number) {
  const response = await fetch(
    `https://jsonplaceholder.typicode.com/todos/${id}`
  );
  const todo = await response.json();
  return todo as Promise<Todo>;
}

const todoId = 1;
fetchTodo(todoId).then((todo) => console.log(todo.title));

NOTICE: In a real project, you'd commonly have a src directory for your source files and a build directory for your compiled modules and so on. This is a quick project however, for demonstration purposes only. So we've kept things utterly minimal and [hopefully] on-point.

3. Generate a configuration file for TypeScript (tsconfig.json):

npx tsc --init

Now we should have a tsconfig.json file with some default options in it. We need to change the value of the option module though, so that the module code generated by the TypeScript compiler will work on Node.js. We'll change its value from "commonjs" to "node16".

NOTICE: We could use "nodenext" too, but "node16" suffices for our purposes. You may also put the cursor in the middle of the double quotations and hit CTRL+SPACE to get intellisense on the available values for each of the options.

After making the above change and removing all the comments, this is our final tsconfig.json:

{
  "compilerOptions": {
    "target": "ES2016",
    "module": "Node16",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true, 
    "strict": true,
    "skipLibCheck": true
  }
}

4. Since node-fetch version 3 is ESM-only, we have to ESM module system in all our Node.js project. Node.js, however, by default assumes all projects to be "commonjs", unless otherwise specified using in the package.json. So in the package.json add:

"type": "module"

5. Now compile the app.ts to JavaScript:

npx tsc

6. And run it:

node app.js // Prints: delectus aut autem

Bonuses

7. We can also use top-level await in our app.ts instead of the chaining .then() syntax used. Top-level 'await' expressions though are only allowed when the 'module' option is set to 'es2022', 'esnext', 'system', 'node16', or 'nodenext', and the 'target' option is set to 'es2017' or higher. Our tsconfig.json is fine for the most part, except for the target option which is on "es2016". Let's tweak it quickly and change it to "ES2022":

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "Node16",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true, 
    "strict": true,
    "skipLibCheck": true
  }
}

Now app.ts may be re-written with top-level await in it:

import fetch from "node-fetch";

type Todo = {
  userId: number;
  id: number;
  title: string;
  completed: boolean;
};

async function fetchTodo(id: number) {
  const response = await fetch(
    `https://jsonplaceholder.typicode.com/todos/${id}`
  );
  const todo = await response.json();
  return todo as Promise<Todo>;
}

const todoId = 1;
// Top-level await:
const todo = await fetchTodo(todoId);
console.log(`Todo Title: ${todo.title}`);

Now compile and run it with:

npx tsc
node app.js

8. Currently, every time we make a change, we have to manually re-compile and re-execute our project. This is not cool. So let's use a tool that can do these both automatically for us. I'll use tsx. Check out their repository and also don't forget to leave them a star if you find it useful.

NOTICE: Obviously you can use any other packages too, but make sure to check their ESM support beforehand. For instance, at the time of writing this article, ts-node-dev's ESM support seems to be missing support ESM yet.

npm i -D tsx

NOTICE: We'll use it in development only, so I've added a -D option to specify it as a devDependency in the package.json and later on we'll be able to prevent its installation once not needed anymore, e.g., using npm install --omit=dev.

Now add this script in the package.json:

"dev": "tsx watch --tsconfig ./tsconfig.json ./app.ts"

Now run the project with:

npm run dev

9. We may also use types similar to the types defined in microsoft/TypeScript for the standard fetch() API, and define a custom fetcher function that is typed generically.

NOTICE: An easy way to find these standard types is by typing them in the editor and ctrl-clicking on them.

We've called this generically typed function "fetchData". Here's the final app.ts code:

import fetch, { RequestInfo, RequestInit } from "node-fetch";

type Todo = {
  userId: number;
  id: number;
  title: string;
  completed: boolean;
};

type Request = RequestInfo | URL;

async function fetchData<T>(request: Request, init?: RequestInit) {
  const response = await fetch(request, init);
  const todo = await response.json();
  return todo as Promise<T>;
}

async function fetchTodo(id: number) {
  return await fetchData<Todo>(
    `https://jsonplaceholder.typicode.com/todos/${id}`
  );
}

const todoId = 1;
const todo = await fetchTodo(todoId);
console.log(`Todo Title: ${todo.title}`);

Hey, you're invited to join our small and fledging 🐥🐣 Discord community called TIL (stands for "Today-I-Learned") where we share things that we learn with each other, in the realm of web programming. Join using this link.

Thanks for reading this article 👋 You're also very welcome to suggest any fixes and improvements in the comments section below.

Let's learn Solid.js quickly, by creating a useDebounce hook

aderchox — Thu, 02 Mar 2023 15:26:08 +0000

Disclaimer: I'm not a Solid.js affiliate in any ways, and also I'm not experienced enough with Solid.js (~2days!) to claim what I write here is "good solid.js code" or even "correct".

Introduction

Although I started learning Solid.js just two days ago, I feel it's made me very productive. One thing I tried to do with it as a first personal exercise, was creating a "drawer" (drawers are those menus that enter the page from one side, in case you didn't know).

I wrote just a few lines of very understandable (read "lovely") code, and then voila, it worked!

At this point, I felt very happy with the journey I'd begun, so I decided to do a second exercise: To make the drawer "less crazy"! I.e., I didn't want it to expand "just when the mouse started hovering on it", I wanted it to "wait" for some time (a delay) and let the user make up their mind whether they actually wanted the drawer to open or not. So I needed a debouncer! (Don't worry if you don't know what it is, I'll explain).

It happened to be an interesting exercise in the end, and it taught me more of Solid's API, so I decided to share it with other peer learners (you!) too. Don't worry if you don't know any Solid.js, I'll try to explain things bit by bit.

What is Debouncing?

To me, debouncing means "not jumping into conclusions". A practical example of when a debouncer can be useful is, when the user is typing letters into a search box, and you want to "trigger the search as the user types", you think this would be great UX, the user doesn't have to click/tap the magnifier (search) button, however, there's an issue with this great idea, EVERY letter that the user types, will make a call to your backend..., which is wasteful. Actually, it could even be "bad UX", assume the search box reacting to every letter instantly as the user types, they might feel the search box is made by a crazy developer!

Solid.js Quick Start Tutorial

Reactivity

The general idea of UI frameworks is to make views react automatically to changes to "the state of the data" (aka, just "the state"). This makes it way easier to write and reason about UI code, compared to using a bunch of event listeners here and there to "manually" update views once the data has changed.

Signals

Solid uses the term "signal" for state (data). Well of course that might not be a precise definition of signals, but it's good enough for the beginning. Let's continue the talk in code (which is not cheap, hopefully!):

function Likes() {
  const [likeCount, setLikeCount] = createSignal(0);
  return (
    <button
      onClick={function like() {
        setLikeCount(likeCount() + 1);
      }}
    >
      {likeCount()} likes
    </button>
  );
}

(playground: https://playground.solidjs.com/anonymous/20a27607-7aed-4c34-9249-e09580131742)

In the example above:

This function is a Solid "component", we've called it "Likes" component. Solid knows how to translate this function into a component under the hood. We just need to return some html from the function (which is basically not "normal HTML", it's "JSX", which gets translated to JavaScript by a compiler before creating the DOM, but we don't need to care about that).
(Read this if you're coming from React) You don't need to worry about stale closures when using signal setters in Solid, i.e., passing a mapper function (mapping old value to new value) to the setLikeCount() instead of passing the actual value wouldn't be considered a best practice, you could do that, but it's not different. This is due to the different model that Solid has towards reactivity, it doesn't re-run the entire component on re-renders, rather, only the points that need to change, do change atomically.
We can make "signals" for our data using the createSignal function, and then use the signals in our JSX, by "calling" them (e.g., { likeCount() } ^{Note: it has to be wrapped in curly braces due to how JSX works.}). This will make our view "reactive" to the likeCount, and whenever this datum is changed, "all things" that have used it (with a call) will also get updated.
I said all "things" on purpose, because the dependent doesn't have to be only JSX, it can even be another JavaScript variable, or an effect (more on this a bit later). For example, let's say we want the background color of the button to go green when the number of likes reaches 3:

import { createSignal } from "solid-js"
import { render } from "solid-js/web";

function Likes() {
  const [likeCount, setLikeCount] = createSignal(0);
  let likesColor = () => likeCount() >= 3 ? "limegreen" : ""; // <-- The value of the likesColor depends on the value of the likeCount signal, and gets updated whenever likeCount changes. likesColor is also known as a "derived signal".

  return (
    <button
      onClick={function like() {
        setLikeCount(likeCount() + 1);
      }}
      style={{ "background-color": likesColor() }}
    >
      {likeCount()} likes
    </button>
  );
}

render(() => <Likes />, document.getElementById("app"));

(playground: https://playground.solidjs.com/anonymous/3bfab2a8-14cf-46e2-873e-2b14adf5b48b)

Effects

Now let's say, whenever the Like button is clicked, we want to shout it out to the world! For such a thing, we need to "track the signal", which is called an "effect".

createEffect(() => {
  console.log(`I Was Liked ${likeCount()} times, World!`);
});

(playground: https://playground.solidjs.com/anonymous/afaae217-4c65-45e2-a88b-a1f0fb666053)

(Read this if you're coming from React) No dependencies arrays have been passed to createEffect, it is not a mistake. Manually passing a dependencies array to createEffect is not needed (and does not exist) in Solid, because Solid signals are used in the effect by "calling them as functions", it is able to detect its own dependencies automatically. Solid also provides other APIs like on for more granular control on effect's dependencies once it's needed (we'll see a forthcoming example of it soon).

Well...... our effect works, but it's kind of lame! Because it even shouts on the very first render, i.e., when we haven't been liked at all!

I Was Liked 0 times, World!

So let's fix this major issue. To fix it, we need to skip the first trigger of the effect (the function passed to the createEffect), and for that, we need to wrap the effect in on. This is NOT the main purpose of the on function, rather, it's a means of making dependencies of the effect explicit. (Sometimes we have signals in an effect that we don't want changes to them to re-trigger the effect.) But it's not related to our use-case here, what we want to use from it is just the options object that we can pass to it which allows us to skip the first trigger:

  createEffect(on(likeCount, (c) => {
    console.log(`I Was Liked ${c} times, World!`);
  }, { defer: true }));

(playground: https://playground.solidjs.com/anonymous/1a15305d-2620-4aad-9b7f-ee1e633c002b)
As you see in the snippet above:

The first argument of the on function is the signal we want our effect to explicitly depend on.
The second argument is the effect itself, however, the signal's VALUE is passed to it (not the signal itself, so we use it by c and not by c()).

Now it works just the way we expected!

The useDebounce hook

Now back to our initial goal at hand! This is an example of how we want to use this hook:

const [isOpen, setIsOpen] = createSignal(false);
const isOpenDebounced = useDebounce(isOpen, 400);
// A 400 milliseconds delay to let the user make up their mind,
// or regret it (usually this value is between 400 to 600).

Let's just code it up and hopefully by now, it will be talking to you in a more familiar language:

function useDebounce(signal, delay) {
  const [debouncedSignal, setDebouncedSignal] = createSignal(signal());
  let timerHandle;
  createEffect(
    on(signal, (s) => {
      timerHandle = setTimeout(() => {
        setDebouncedSignal(s);
      }, delay);
      onCleanup(() => clearTimeout(timerHandle));
    })
  );
  return debouncedSignal;
}

(playground: https://playground.solidjs.com/anonymous/7c8c8d82-502b-4a31-ab96-2cb45a6e705a)

In case you don't understand it yet, it's your own fault, re-read everything, just kidding. The gist of it is, we have defined an effect which depends on the signal we want to debounce, so whenever the signal is reset, the effect is re-triggered, and also onCleanup will clear the previously set timer.

There's a big downside to the above solution though, the passed state MUST be initiated using the equals: false option, so that createEffect gets re-triggered even when the state is set with the same value!

  const [likeCount, setLikeCount] = createSignal(0, { equals: false });

Of course not ideal.

A much more Solid solution!

A better (much better 😅) implementation of the useDebounce debounces the "state setter" (not the getter), e.g., the setLikeCount, not the likeCount. Not only this solution is easier, more readable, and doesn't require setting an { equals: false } option, but also demonstrates how close Solid.js can be to vanilla JavaScript!

function useDebounce(signalSetter, delay) {
  let timerHandle;
  function debouncedSignalSetter(value) {
    clearTimeout(timerHandle);
    timerHandle = setTimeout(() => signalSetter(value), delay);
  }
  onCleanup(() => clearInterval(timerHandle));
  return debouncedSignalSetter;
}

(playground: https://playground.solidjs.com/anonymous/0850d269-ca93-4a6d-9607-ca8c2aa2f0cb)

createEffect and on are not needed anymore!

In case you're wondering what happens to clearTimeout in the first render: clearTimeout's API is OK with undefined passed to it and just ignores it. Also in case you're wondering why we need that onCleanup call, that's because the last time the timer is set, the component might unmount without cleaning up the timer, which could cause an error. (This example also shows how onCleanup is not dependent on createEffect, which might be against what you're used to, if you're coming from React.)

This is the final result:

Bonus: Solid Primitives Library

Although the above solution works, it's not tested enough, and as I initially said, I'm not experienced enough with Solid to guarantee the quality of the above solution. But no worries, thankfully Solid's community is so helpful and they've already provided a library like React's usehooks-ts for such frequent needs, and they've called it "solid-primitives". So if you want a battle-tested solution for debouncing using Solid, I recommend using the debounce primitive from this library. Install, import and use it just the way we used our own debounce hook above! Please don't forget to also give them a star if their work makes your life as a developer easier ☺.

Thanks for reading this article, you're very welcome to suggest any fixes and improvements in the comments section below.

Happy Solid coding. 👋

Thanks to my friend "David Guillaumant-Mergler" for suggesting improvements, and to the amazing folks on the Solid's Discord server for their considerable help and inexhaustible patience.

Multiple GitHub Accounts On One Machine - A Quick Guide 🤹‍♀️🚀

aderchox — Sat, 25 Feb 2023 10:29:51 +0000

Let's say we need one GitHub account for our personal use, and another one for our work/professional use. How do we do this?
^{NOTICE: Git is [thankfully] very strict on telling the truth about the history, and what's explained here is also not an exception. This method is NOT a way of "impersonating" one account with another! Rather "multi-account" here means "being able to use multiple accounts on the same machine SEPARATELY". If you don't know what all these mean, no worries, just ignore this notice.}

Here are the steps:

👉1. Create and edit ~/.ssh/config on you machine (On Windows, that would mean a path like C:\Users\<your-username>\.ssh\config).

👉2. Add this to it:

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa
Host github.com-personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa_personal

^{Explanation: Basically what this config is saying is very simple, if it ever sees the string git@github.com in a repository address, it will use the ~/.ssh/id_rsa private key, and if it sees the string git@github.com-work in a repository address, it will use the ~/.ssh/id_rsa_work private key. You'll see an example in the end.}

👉3. As you see, we need two pairs of SSH keys (the ones which their private keys have been addressed by IdentityFiles in the config snippet above). Now create these two pairs inside the .ssh folder of your machine by cding to it and running the below command twice:

cd ~/.ssh
ssh-keygen -t rsa -b 4096 -C "your-work-email-address"
# After running the below command for creating the personal-use
# key pair, make sure to enter the correct name i.e. "id_rsa_personal",
# similar to the one that we used in the config.
ssh-keygen -t rsa -b 4096 -C "your-personal-email-address"

^{NOTICE: When prompted for passphrases, you may only hit Enter on your keyboard to skip it.}

👉4. Now add the public key of each of these pairs to its corresponding GitHub profile settings. I.e., one goes into your personal GitHub account's profile settings, and the other one goes into your work/professional one's profile settings.

👉5. Now set the account that you use more as the global one for your machine's git account, and the one that you use less as the local one (on a per-project basis). E.g., I use the work account more, so:

git config --global user.name <work-username>
git config --global user.email <work-email>
cd <a-specific-personal-project>
git config --local user.name <personal-username>
git config --local user.email <personal-email>

If you like you can check and make sure all configs have been set properly:

git config --global --list
git config --local --list

👉6. Now use git@github.com for work/professional use, and git@github.com-personal for personal use. E.g.: git remote add origin git@github.com:username/repo.git when in work repositories, and git remote add origin git@github.com-personal:username/repo.git when in personal repositories! 🤹‍♀️

You're also invited to join our small fledging Discord community called TIL (stands for "Today-I-Learned") where we share things we learn and articles we write in the realm of web programming with each other. Join us using this invite link.

Thanks for reading this article, you're very welcome to suggest any fixes or improvements in the comments section below.

Credit and Acknowledgment: Thanks Jeffery Way for writing a guide on this, here I've only tried to explain it in a different way, by putting it in my own words, and summarizing it a bit.)

Weird thing I missed about Async/Await: Implicit Returns

aderchox — Sun, 17 Jul 2022 18:29:25 +0000

Weird I didn't know this so far, because I've been using async/await syntax for a while now, but I've just realized this.

Async functions return a Promise implicitly and automatically themselves. We don't need to do anything for this (e.g., we don't need to do return new Promise((resolve)=>{/*...*/}) inside our async functions (unless we explicitly need to)).

Example
This snippet:

async function foo(){
    return "foo";
}

is an equivalent of this snippet:

async function foo(){
    return Promise.resolve("foo");
}

For our comfort, JavaScript does the above conversion itself automatically.
Note that even if we return nothing, still the above conversion will take place, i.e.,:

async function foo(){}
// is an equivalent of:
// async function foo(){ return Promise.resolve(undefined); }

// Let's call foo to confirm our claim:
foo();
// Prints: Promise {<fulfilled>: undefined}

Now why would understanding this be useful? Well personally I knew that whenever we use an await keyword, it has to be kind of *coupled* with some Promise, so for instance we could do:

const delayFoo = ms =>
  new Promise(
    resolve =>
      setTimeout(() => resolve("foo"), ms)
  );
const delayFooThreeSeconds = () => delayFoo(3000); // (*) This returns a Promise explicitly.

// now inside some async function:
async function demo(){
    console.log("foo", 1);
    console.log(await delayFooThreeSeconds(), 2); // (*) This awaits the Promise returned explicitly by the call to delayFooThreeSeconds.
    console.log("foo", 3);
}

demo();

delayFoo is an example of a function that is returning a Promise explicitly, but what if we need an async call within our function at a point that is not where it's returning? For example, consider a nested async/await where a function is both doing an async operation and is supposed to be awaited itself too inside another async function:

async function bar(){ // <-- (*) This function is not returning any Promises explicitly.
  doSomething();
  await delayFooThreeSeconds()
  doSomethingElse();
}
async function baz(){
  await bar(); // <--- (*) Would this be possible?
}

Now the bar function is not returning a Promise explicitly, so could it be awaited inside baz? As you might have guessed the correct answer by now: "Yes", because the above function is returning a Promise implicitly. (Even if we have multiple async calls wrapped inside an async function, the hierarchy of the promises will be the same as the invocations of the async functions.)

Here are some working examples for you to play with and see things better in action: https://playcode.io/928113/

You're also welcome to join our very small and fledging Discord community where we share the things that we learn in the realm of programming with each other, it's called TIL (stands for "Today-I-Learned"). Join here: https : // discord.gg / ATp8gc7G. Thanks for reading this article.