Forem: Mayowa Obisesan

Why JavaScript's Object.assign()?

Mayowa Obisesan — Wed, 04 Jun 2025 23:15:13 +0000

In this era of AI generated code, you will see some logic generated by AI. An example of such is, Object.assign(). So if you have also come across this and don’t know what it means, this article aims to do justice to that. Let’s dive into it.

In modern JavaScript, a few methods quietly do the heavy lifting behind the scenes. One of those method is Object.assign(). While it might not have the flair of new syntax or frameworks, it plays a critical role in data manipulation, state management, and object composition. Note the Object composition.

By the end of this article, you should know what Object.assign() is, how it works, what it’s good for and where it can bite you if you’re not careful.

What Exactly Is `Object.assign()`?

Introduced in ECMAScript 2015 (ES6), Object.assign() is a static method on the global Object constructor. Its job is simple but powerful, it is meant to: copy the values of all enumerable own properties from one or more source objects to a target object.

Here’s the basic syntax:

Object.assign(target, ...sources)

target: The object that will receive the properties.
sources: One or more source objects whose properties will be copied.

The method returns the modified target object.

Let’s observe some examples.

Example: Cloning and Merging

const target = { a: 1 };
const source = { b: 2, c: 3 };

const result = Object.assign(target, source);

console.log(result); // { a: 1, b: 2, c: 3 }
console.log(target === result); // true

Here, source’s properties are copied into target, and target is returned. Object.assign() is destructive in the sense that it modifies the first argument.

Use Case 1: Shallow Cloning

If you need a quick way to clone an object, then Object.assign() works, but that also depends on if you’re okay with a shallow copy like this.

const obj = { a: 1, b: { nested: true } };
const clone = Object.assign({}, obj);

clone.b.nested = false;

console.log(obj.b.nested); // false (Oops!)

Because Object.assign() only copies property references for nested objects, changes to nested data in the clone affect the original. For deep cloning, consider structuredClone() or libraries like Lodash.

Use Case 2: Merging Multiple Objects

If you are merging or combining configurations, settings, or component props, Object.assign() also will work for you. Consider this example.

const defaultSettings = { theme: 'light', debug: false };
const userSettings = { debug: true };

const finalSettings = Object.assign({}, defaultSettings, userSettings);
// { theme: 'light', debug: true }

The order matters later parameters override earlier ones. This is great for applying defaults and then overwriting with user-specific values.

Pitfalls and Cons

1. Shallow Copying Only

As mentioned, nested objects are not deeply copied. This limitation can cause unintended side effects if you’re not careful. So now you know for next time you encounter this when vibe-coding or otherwise.

2. Enumerability

Only enumerable properties are copied. That means properties set with Object.defineProperty() using enumerable: false won’t be included.

const obj = {};
Object.defineProperty(obj, 'hidden', {
  value: 'secret',
  enumerable: false
});

const copy = Object.assign({}, obj);
console.log(copy.hidden); // undefined

3. No Prototype Transfer

Object.assign() does not copy over an object’s prototype chain. It only deals with own properties.

How `Object.assign()` Works

Internally, Object.assign() performs the following steps:

Converts target to an object (if it’s not already).
Iterates over the source objects from left to right.
For each source:
- Converts it to an object.
- Loops through its own enumerable properties (both string and symbol keys).
- Copies each property to the target.
Returns the modified target.

This behavior is consistent with the ECMAScript specification and helps developers predict its effects.

In case this seems too difficult to understand or you simply wish there were simpler alternatives to using Object.assign(). The answer is that there are. Let’s consider some alternatives.

Alternatives to `Object.assign()`

1. Spread Operator (...)

In many cases, the spread syntax is a cleaner alternative:

const merged = { ...defaultSettings, ...userSettings };

It’s more concise and often easier to read, especially when cloning or merging.

However, the spread operator is syntactic sugar, it’s not identical. Notably, it doesn’t copy symbol properties or getters/setters.

2. structuredClone()

structuredClone exists for deep cloning. Consider this:

const deepCopy = structuredClone(obj);

This handles nested structures, dates, arrays, and more. Something Object.assign() can’t do. So if there are certain copy Object.assign() cannot handle, when do we use Object.assign()?

When to Use Object.assign()

Use Object.assign() when:

You need to merge objects with potential fallback values.
You’re working in an environment without spread syntax support.
You need fine control over property copying (e.g., including symbols).

And, Avoid it when:

You need deep cloning.
You’re dealing with objects that include non-enumerable or getter/setter properties.

Some Real-World Applications

In frontend frameworks like React or Vue, Object.assign() often powers state updates, prop merging, and configuration layering.

In Node.js though, you’ll find it in utility libraries, plugin loaders, and even Express middleware that combines options.

It’s ubiquity makes it a tool every JavaScript developer should know inside and out.

Final Thoughts

Object.assign() isn’t flashy, but it’s reliable and versatile. Whether you’re merging configs, copying objects, or applying fallbacks, this method gives you precise control over object manipulation, that is if you understand its rules.

But Mastering Object.assign() will help you write cleaner, more predictable JavaScript. Just remember that with great power comes shallow copying.

If you enjoyed reading this article, give a like, clap or any reaction.

If you have questions or additions or comments, Drop a comment, I’d love to hear from you.

If you want to learn more uncommon JavaScript methods. Check out my other articles. I’m sure you’ll see other contents that interests you.

Thank you for reading. 🙂

TypeScript has a Required Utility Type.

Mayowa Obisesan — Sat, 31 May 2025 16:01:08 +0000

TypeScript developers love safety nets. We want guarantees. We want to know that if something should exist, it must exist. So, as you might expect, with all things programming, there is an utility type in TypeScript for that.

Required in TypeScript is a built-in utility type that quietly enforces presence where you don’t want optional properties. It helps to ensure that fields or type that are marked as required have to be defined.

Let’s dissect what Required does, how it works, and why it deserves a permanent place in your TypeScript codebase.

What Is the Required Utility Type?

TypeScript’s Required is a mapped type that transforms all optional properties of a given type T into required ones. It’s part of TypeScript’s standard library and is defined like this

type Required<T> = {
  [P in keyof T]-?: T[P];
};

In plain English, what this means is that you loop through each property P in type T, and remove the optional modifier ?. The -? syntax specifically removes optionality. The result is a new type where all properties are now mandatory.

A Quick Example

Here’s a practical use case:

In this first example, name and email are optional,

type User = {
  id: number;
  name?: string;
  email?: string;
};

type UserIsRequired = Required<User>;

But now that User is marked as Required above, UserIsRequired now has all properties required.

type UserIsRequired = {
  id: number;
  name: string;
  email: string;
};

No more optional name or email. If you’re consuming an object typed as UserIsRequired, TypeScript will enforce that those fields are present.

Why Is This Useful?

Think of it this way, optional fields are a double-edged sword. They’re helpful when you’re dealing with partial data, but they can turn into bugs if you assume those fields are always present later in the pipeline, and this can later come back to bite you.

Consider a user registration form:

function submitForm(user: User) {
  sendToServer(user.name.toUpperCase()); // name is undefined here
}

You either use non-null assertions (user.name!) and hope for the best, or check every field. But what if you know this function should only ever receive complete user data? That’s where Required<User> saves you.

function submitForm(user: Required<User>) {
  sendToServer(user.name.toUpperCase()); // name is now a guaranteed string
}

This makes your codebase safer and your intent clearer.

So, Where Should You Use It?

1. Validation Layers

After validating incoming data, you might want to treat it as fully defined. Here is an example of what I mean by this.

function validate(user: User): Required<User> {
  if (!user.name || !user.email) throw new Error("Missing fields");
  return user as Required<User>;
}

2. Default Merging Utilities

When combining defaults with user input. Here’s an example of this.

function withDefaults(user: User): Required<User> {
  return {
    id: user.id,
    name: user.name ?? 'Anonymous',
    email: user.email ?? 'no-reply@example.com',
  };
}

Now the return type explicitly communicates completeness.

3. Testing & Mock Data

When creating test data before integrating with served data from a server or an external API.

const mockUser: Required<User> = {
  id: 1,
  name: "Alice",
  email: "alice@example.com"
};

No half-baked objects will slip through this way.

Limitations of Required

It’s Shallow: Required only makes top-level properties required. Nested objects with optional fields won’t be affected unless you apply Required recursively.

type Config = {
  meta?: {
    created?: string;
  };
};

type FullyRequired = Required<Config>;

// meta is required, but meta.created is still optional

2. Type Assertions Are on You: If you claim something is Required, make sure it truly is. TypeScript trusts you once you assert it. This can also come back to bite you. So, it’s good to have a sense of this constraint when using Required.

Final Thoughts

TypeScript’s Required utility type is a small but powerful feature that enforces intent and safeguards your logic. It’s your ally in a world full of partials and maybes. You should use it to tighten up your types, document your expectations, and write safer, cleaner code.

In short, Required<T> isn’t just syntactic sugar in your code, it is a contract. And in software, clear contracts are pure gold.

Did you Learn Something?

If you like this article, give it a reaction.

If you have a question or an opinion or controversy, drop a comment.

If you want to read about other programming tips. Check out my other articles. You will definitely learn something new from there.

Thanks for reading. 🙂

NPM vs Yarn vs PNPM: Why so many?

Mayowa Obisesan — Thu, 29 May 2025 23:51:28 +0000

If you are a JavaScript developer, chances are you have a favourite package manager from the number of choices that exist. NPM, Yarn, and PNPM all package managers that aim to do the same job:

Manage project dependencies. But they do it in different ways, each with its own tradeoffs.

In this article, I’ll break down how these package managers work, what makes each one great (especially why we as devs say this one is better than this), and which is the smartest choice for modern development in 2025.

If you’re ready to find out. Then keep reading.

The Core of the Problem: Managing Node Modules

Every package manager for JavaScript solves the same core issue: downloading dependencies from the npm registry and making sure they play nicely together in a project. This may sound like a simple thing to do, but the Node.js ecosystem is notorious for deep, bloated node_modules trees, long install times, and version conflicts. That’s where these tools start to differentiate.

NPM: The Original, the Default, the Standard

First released: 2010

Current version: 10.x (as of 2025)

Bundled with: Node.js

NPM is the OG. It comes preinstalled with Node.js and is still the most widely used package manager by raw numbers. Over the years, NPM has improved significantly with better caching, package-lock.json for consistent installs, and support for workspaces. But it has a major problem of being slow for larger projects and less effective when it comes to managing disk usage. For clarity, let’s consider some of the Pros and Cons.

Pros:

It is ubiquitous and universally supported
It is simpler onboarding for beginners
npm audit and security tools built-in
It has a large ecosystem and strong community

Cons:

It is slower than Yarn and PNPM in larger projects
It is less efficient disk usage compared to PNPM

Ideal for: Beginners, simple projects, and teams who want zero setup beyond Node.js

Yarn: Speed, Determinism, and Better UX

First released: 2016 by Facebook

Current version: Yarn 4 (Berry)

Before talking about Yarn, I’m just impressed with how Facebook has really given us developers some interesting tools and frameworks, and we are grateful for it. Let’s talk about yarn though.

Yarn came onto the scene promising faster installs and better determinism. It was the first to introduce lockfiles (yarn.lock) and offline caching. With Yarn 2 and later (Berry), the project became far more opinionated. Yarn now uses a plugin-based architecture, strict PnP (Plug-n-Play) resolution by default (no node_modules!), and its own configuration style.

Pros:

It has fast install times, especially with PnP
It supports Deterministic builds
It has great monorepo support with workspaces
It supports Plug-in architecture for customization

Cons:

It has a steep learning curve post the first version of Yarn. (This might not be a problem for most people reading this though, but I just had to add it here.)
It requires config/setup to work with many tools
There are known compatibility issues with some legacy packages

Ideal for: Large-scale projects, monorepos, advanced developers who want control.

PNPM: Speed + Storage Efficiency = Game Changer

First released: 2016 by Zoltan Kochan

Current version: 9.x (as of 2025)

pnpmis my current package manager and I can say it is what I write in this article.

PNPM solves one of the biggest inefficiencies in Node.js, the issue of duplication. Instead of copying dependencies into each project, PNPM uses a global content-addressable store. Dependencies are linked using hard links and symlinks, dramatically reducing disk space usage. You might wonder why this took long to implement? I asked myself the same question too.

Another interesting thing about pnpm is that it enforces strict dependency rules by default, preventing packages from accessing dependencies they haven’t declared.

Pros:

Blazing fast installs
Minimal disk usage
Strict and safe dependency resolution
First-class workspace and monorepo support

Cons:

Smaller ecosystem than Yarn and NPM
Still not the default in most tooling
Some older tools assume traditional node_modules

Ideal for: Power users, large projects, teams managing multiple apps or libraries

Real-World Performance Benchmarks

Across various open-source benchmarks and internal reports from dev teams in 2024–2025, the numbers speak for themselves.

While actual numbers vary by project, PNPM consistently comes out ahead on speed and space. Yarn trails closely, especially with PnP mode enabled. NPM lags, though it’s caught up a lot in recent years.

Developer Preferences in 2025

Surveys and GitHub trends show that PNPM has surged in popularity over the past two years. While NPM still dominates due to default usage with Node.js, many mid-size to large teams are switching to PNPM for better performance and stricter dependency isolation.

Yarn remains strong in enterprise settings and monorepos, but its PnP system and complexity can turn off devs who want simplicity.

According to an Excerpt from StackOverflow Developer Survey 2025:

NPM has 55% popularity
PNPM has 32% popularity
Yarn has 22% popularity

So, Which One Should You Use?

Use NPM if:

You want simplicity and compatibility
You’re working on small projects or teaching beginners

Use Yarn if:

You need advanced workspace features and plug-in extensibility
You’re okay with its PnP approach and willing to configure around it

Use PNPM if:

You want raw speed and disk efficiency
You’re working in monorepos or CI-heavy environments
You care about strict, safe dependency boundaries

Conclusion

In 2025, PNPM is the best all-around choice for most developers. It’s fast, efficient, and increasingly well-supported across the ecosystem.

And I’ll end with this, unless you’re tied to NPM or need Yarn’s specific features, PNPM deserves your serious consideration.**

Enjoyed This Article?

Then share it with your dev team or community.

If you have questions or contributions, Leave a comment or reach out.

Follow me for more clear, developer-first tutorials, with real-world examples and sharp insights.

Thanks for reading and happy coding. 🙂

What is Pick in TypeScript? Do you know? 🤔

Mayowa Obisesan — Wed, 28 May 2025 18:36:47 +0000

When you’re building modern web applications in TypeScript, one of your goals should be writing safe, scalable, and maintainable code. A big part of that is mastering TypeScript’s utility types. One of the most useful and often misunderstood is Pick. If you’re new to TypeScript or just haven’t tapped into the full power of its type utilities yet or even if this is the first time you hear about this, don’t worry. You can learn all about Pick in just few minutes. So, Let’s break it all down, starting from the basics.

What is Pick in TypeScript?

Pick is a built-in TypeScript utility type. It lets you create a new type by selecting a subset of properties from an existing type. (If you want to learn about more utility-types in TypeScript such as Partial, Omit, I have article written about this as well. You’ll find them at the end of this article.)

Here’s the syntax:

Pick<Type, Keys>

Let me explain what these mean:

Type: The existing object type you want to base your new type on.
Keys: A union of the keys you want to extract.

A Simple Example

type User = {
  id: number;
  name: string;
  email: string;
  isAdmin: boolean;
};

type PublicProfile = Pick<User, 'id' | 'name'>;

const profile: PublicProfile = {
  id: 1,
  name: 'Alice'
};

PublicProfile is now a type that includes only the id and name properties from User. You pick just what you need. It’s as the name implies. This is cleaner and safer than redefining the type manually everytime you need a different type or a different interface.

Why Use Pick ?

Let’s talk some practical benefits:

1. Avoid Code Duplication

You don’t need to retype property definitions. I see people do this a lot in their codebase. I also used to do this before I came across these utility types. But since I found them, my TypeScript codebase has significantly improved in quality. And this has helped reduced a lot of maintenance headaches.

2. Improve Type Safety

By referencing the original type or Shape, Pick ensures consistency even if the base type changes. You might not understand this until you start using this utility type. The consistency is golden.

3. Enable Reusable Components

It’s perfect for reusable components. Say, you need a component that only needs part of a type? Pick lets you craft precise props.

4. Clear Intent

When you use Pick, you’re making it clear to other developers that your new type is a slice of something larger. It’s semantic and very readable.

How to Use Pick Dynamically

You can combine Pick with other utilities to build powerful abstractions. For example:

type KeysToPick = 'email' | 'isAdmin';
type AdminContact = Pick<User, KeysToPick>;

You can even dynamically generate keys with mapped types:

const keys = ['email', 'isAdmin'] as const;
type KeysArray = typeof keys[number];
type AdminContact = Pick<User, KeysArray>;

This is super useful when you’re working with dynamic forms or APIs that need flexible shapes. Please mark this point for your reference.

Let’s go over the Best Practices once more.

1. Use Pick to Build Read-Only Interfaces for UI Components

Keep frontend props tight and clean by sending only what a component needs.

2. Combine with Omit for Precision

Sometimes you need both. If you need to read about omit. Click here to read my article about omit.

type NonSensitiveUser = Omit<User, 'email' | 'isAdmin'>;

3. Use Named Utility Types

Instead of inlining Pick, give it a name like PublicProfile. It improves readability and reusability. Just the like the example I showed above.

4. Pair with `keyof` to Create Dynamic Helpers

function pluck<T, K extends keyof T>(obj: T, keys: K[]): Pick<T, K> {
  const result = {} as Pick<T, K>;
  keys.forEach((key) => {
    result[key] = obj[key];
  });
  return result;
}

Now you can extract exactly what you need from an object while preserving types.

Visualizing Pick

Here’s a simple visualization to clarify how Pick narrows down an object type.

Original Type:          Picked Type:
-------------------     -------------------
id: number              id: number
name: string    ===>    name: string
email: string
isAdmin: boolean

Conclusion

Pick might seem simple at first glance, but it’s a powerhouse once you understand how to use it effectively. From keeping your code DRY and safe, to enabling flexible, type-safe APIs, it’s a must-have in your TypeScript toolkit. If you’re serious about scaling your TypeScript applications with confidence, clarity and quality, I believe mastering Pick is a step you can’t skip in your journey.

TL;DR of this Article:

Pick in TypeScript is a utility type used to select specific properties from an object type.
It helps reduce code duplication and enhances type safety.
Use Pick with other utilities like Omit and keyof for more powerful patterns.
Ideal for API models, UI components, and anywhere precise type shaping is needed.

Pick what works best for you from these for your next TypeScript project, or maybe even for your existing project.

Enjoyed This Article?

If this article helped your understanding of Pick, share it with your dev team or TypeScript community.

If you have questions or want deeper dives into other utility types? Leave a comment or reach out.

Follow me for more clear, developer-first TypeScript tutorials, with real-world examples and sharp insights.

Thanks for reading and happy typing. 🙂

Microsoft "Edit" vs Vim: Is Vim dethroned?

Mayowa Obisesan — Wed, 28 May 2025 00:54:28 +0000

Over the years, Microsoft has made a significant shift in contributing heavily to the open-source world. From the development and release of TypeScript to VSCode, to contributing and working actively on other open-source projects such as Rust, React, and other major open-source tools that have made life easy for developers. Microsoft has really made a name for itself in this open-source game. And Microsoft has added yet another new open-source project to their already impressive arsenal of open-source tools. This new open-source project is called “Edit”, and it is an interesting project. Let’s talk about it.

Let me begin with this power quote: Microsoft is officially entering the command-line editor space with “Edit” a modern, open-source alternative to Vim designed for power users, developers, and sysadmins who live in the terminal.

While “Edit” might sound like just another text editor in a crowded market, it marks a significant shift, especially for Windows developers who’ve long relied on outdated Notepad variants or bolted-on Unix tools.

So enough of the introduction, what is Edit? And why is Microsoft building it now?

A Fresh Take on a Legacy Problem

For over 30 years, Vim has been the undisputed king of terminal text editors. Its interface, performance, and very deep configurability made it a favorite among Unix users. But it’s also infamous for its steep learning curve and “byzantine” keybindings. For many Windows users, Vim is more of a survival tool than a preference. And this is exactly what Microsoft’s Edit aims to fix.

“Edit” is Built in Rust, designed with performance and usability in mind, Edit is engineered to be fast, predictable, and easy to extend. It’s terminal-native but not hostile to newcomers. Think: Vim’s muscle, without the arcane rituals.

Fun fact,

“Edit” was written in 3 languages before finally settling for Rust. Rust was not the first choice for “Edit”. Zig was a preferred choice, but due to incompatibility issues with Windows, “Edit” was re-written in Rust.

Key Features of Microsoft Edit

Here’s what sets Edit apart:

Rust-Based Core: Edit is written in Rust, giving it modern performance characteristics, memory safety, and cross-platform potential out of the box.
Modal Editing (Yes, Like Vim): Edit supports modal editing but is designed to be more intuitive. Think of it as “Vim-lite” with better defaults.
Configurable Without the Pain: I think most people will like this. The Settings and keybindings live in clean, readable config files. You won’t need to memorize Vimscript to tweak your workflow.
First-Class Windows Support: Unlike Vim and its cousins, Edit is designed to feel native on Windows. No WSL workarounds, no Cygwin, no compromise. But not just windows. You can use it with other unix-based operating systems like MacOS and Linux.
Terminal-First, But GUI-Ready: Edit runs in your terminal, but the project roadmap includes optional GUI shells for a hybrid experience, similar to Neovim + frontends like Oni or Helix.

Why Now? Why Windows?

Let’s be honest: text editing on Windows has been a mixed bag. Notepad is too barebones. VS Code is excellent but heavy. Powershell and CMD have improved, but neither is developer-first in the way Unix shells are. Until recently, terminal editing on Windows was a second-class experience.

But now, with the rise of Windows Terminal, WSL2, and a growing Rust ecosystem, Microsoft has the pieces to offer something leaner and meaner for developers who live in CLI environments.

“Edit” is the missing puzzle piece. It gives Windows power users a native, high-performance editor that respects their workflows, doesn’t force them into Linux metaphors, and still plays nice with Git, SSH, and scripting pipelines. Yes it plays nice with SSH. Interesting right?

For Vim Veterans: Should You Switch?

If you’re a Vim user, you might be skeptical. Vim is mature, fast, and everywhere. Should you switch?

Here’s a breakdown:

What’s clear is that Edit isn’t trying to replace Vim wholesale. Instead, it’s positioning itself as a practical, modern option for users who want the power of modal editing without the historical baggage.

For Vim experts, Edit could be a “daily driver” alternative in environments where Vim feels clunky or outdated — especially on Windows.

For Windows Developers: A Game-Changer

This is where Edit could really shine. On Windows, terminal-based editing has long been an afterthought. With Edit, Microsoft is saying: you don’t need to live in VS Code to be productive. You can stay in the terminal, script, build, git, and edit all without leaving your flow.

For devs using Windows Terminal, Powershell, or WSL2, Edit fits right in. No more context-switching between editors. No more crutches like nano or Notepad++. Just a native, fast, keyboard-first tool that gets out of your way. (Even though I like nano, this is better).

The Bigger Picture: Microsoft Loves the Terminal Again

Edit is the latest sign of Microsoft’s ongoing love affair with developers and open source. From VS Code to the new Windows Terminal to full Linux kernel support in WSL2, the company is rethinking what productivity means for modern devs.

By releasing Edit as open source, Microsoft is betting on community-driven development. And by making it modular, scriptable, and terminal-native, they’re not just copying Vim they’re reimagining it for a new generation.

Final Thoughts

Microsoft Edit isn’t just a new text editor, it’s a statement. It tells developers, especially on Windows: We see you. We get how you work. And we’re building tools that respect that.

And if you think about this, this was the same thing Microsoft did with TypeScript and with VSCode. I truly believe in “Edit”. This Microsoft philosophy to understand what devs need in the past carved a place for itself and totally changed the tech world. I believe “Edit” could do the same also.

For Vim users though, Edit may not replace your beloved .vimrc overnight. But it’s worth watching and trying. Especially if you live in the Windows ecosystem and crave a native, powerful alternative that doesn’t come with a legacy learning curve.

As Edit evolves, it could become the bridge between the raw power of Vim and the modern UX of tools like Helix or VS Code. It might just be the best of both worlds. I’m very optimistic and eager to see where this goes.

If you like this article, give it a reaction.

If you have a question or an opinion or controversy, drop a comment.

If you want to read about other programming tips. Check out my other article. You will definitely learn something new from there.

Thanks for reading. 🙂

Mastering TypeScript’s Omit—Beginner to Advanced (With Visuals)

Mayowa Obisesan — Fri, 23 May 2025 01:15:02 +0000

If you're tired of repeating types just to exclude a few fields? Omit is your best friend for handling this.

I wrote a breakdown of TypeScript’s Omit for anyone who wants to clean up their types, avoid duplication, and stay DRY. This article ramps up from beginner basics to best practices with real code and visuals to help it stick.

In this article, I walk through:
• What Omit is (in plain English)
• Practical use cases for APIs & UI
• Common mistakes to avoid
• Code examples & diagrams

Read it here → Understand Omit in TypeScript: Beginner-friendly Deep Dive

typescript #webdev #beginners #cleanCode #javascript

TypeScript Tip: When, Why and How to Use Partial

Mayowa Obisesan — Mon, 19 May 2025 08:13:05 +0000

If you’re working with TypeScript and find yourself updating forms or doing partial API requests, you need to understand Partial.

I wrote a deep but beginner-friendly article explaining:
• What Partial really does under the hood
• When it shines (and when it doesn’t)
• How to use DeepPartial for nested objects
• Code samples, visuals, and a cheat sheet

👉 [Read the full article on Medium] https://mayowaobisesan.medium.com/understanding-partials-in-typescript-what-why-and-how-4ec697d09693

STELLAR BLOCKCHAIN -YOUTUBE TUTORIAL PLAYLIST

Mayowa Obisesan — Sun, 18 Aug 2024 23:23:09 +0000

This is a submission for the Build Better on Stellar: Smart Contract Challenge: Create a Tutorial

Your Tutorial

Here is the tutorial I created about the Stellar blockchain.
Stellar Blockchain Network Tutorial Series

Stellar Blockchain Series - YouTube

Welcome to the Stellar Blockchain series. This series aims to help onboard developers to the stellar blockchain and into web3 in general by providing the nee...

youtube.com

What I Created

I created a playlist about the stellar blockchain network. Starting from the basics of Stellar network.

I created a playlist that delves into the Stellar blockchain network, beginning with the fundamentals of the Stellar network. The playlist is designed to provide a comprehensive understanding of Stellar's infrastructure, starting from its basic principles and gradually advancing to intermediate and then to more complex concepts. The playlist currently contains 8 uploaded videos of about 3 hours. It's an ideal starting point for anyone looking to grasp the essentials of the Stellar blockchain and its capabilities.

My submission is to help make the stellar blockchain as understandable as possible. Providing references to real-life scenarios, other blockchains and diagrams to make the concepts about Stellar network as understandable as possible. The videos I created and have compiled into a playlist follows a progression so that whoever watches the video will have a good and deep knowledge of what the stellar blockchain network is all about. The videos build on themselves similar to how Stellar ledgers build on themselves. I also ensure that major points I discussed during the videos are properly shown and where applicable explained with diagrams. These videos will support developers who need better understanding about the Stellar blockchain and for developers who want to build Dapps on Stellar. From the videos, you learn about the rules that govern the Stellar blockchain, what Stellar blockchain is best equipped for, how smart contracts work on Stellar blockchain, from the conversion of Soroban contracts to WASM to deployment on the blockchain, you will learn about all of this and more from this compiled playlist about Stellar.

Journey

The motivation behind creating the videos was when I was going through the docs. Though the docs were explanatory enough to understand, because I have good knowledge about the blockchain and various other blockchains and because I also teach in physical location about blockchain and web3, I thought of changing my approach to teaching about blockchain by making videos to share my knowledge about what I am currently learning about Stellar blockchain. This month of August is my first time exploring the Stellar blockchain and since I found Stellar interesting and that I found it's features much appealing. I thought of sharing my knowledge about the Stellar blockchain in moving pictures and not just through physically classes as I would normally do.

I would like to credit my friend that told me about this hackathon about Stellar blockchain. She picked my interest about Stellar and got me interested in learning and exploring Stellar. Though she couldn't complete the hackathon and make her submission. I am crediting her in this post.
Faith Roberts: @faytey7

Thank you for reading.
Kudos to the SDF (Stellar Development Foundation), they are doing a good job.
Kudos to the Stellar Community. I'm happy to be a part of that community now.

Thank you for reading.
Happy hacking everyone. 🙂

Forem: Mayowa Obisesan

Why JavaScript's Object.assign()?

What Exactly Is Object.assign()?

Example: Cloning and Merging

Use Case 1: Shallow Cloning

Use Case 2: Merging Multiple Objects

Pitfalls and Cons

1. Shallow Copying Only

2. Enumerability

3. No Prototype Transfer

How Object.assign() Works

Alternatives to Object.assign()

1. Spread Operator (...)

2. structuredClone()

When to Use Object.assign()

Some Real-World Applications

Final Thoughts

TypeScript has a Required Utility Type.

What Is the Required Utility Type?

A Quick Example

Why Is This Useful?

So, Where Should You Use It?

1. Validation Layers

2. Default Merging Utilities

3. Testing & Mock Data

Limitations of Required

Final Thoughts

Did you Learn Something?

NPM vs Yarn vs PNPM: Why so many?

The Core of the Problem: Managing Node Modules

NPM: The Original, the Default, the Standard

Yarn: Speed, Determinism, and Better UX

PNPM: Speed + Storage Efficiency = Game Changer

Real-World Performance Benchmarks

Developer Preferences in 2025

So, Which One Should You Use?

Conclusion

Enjoyed This Article?

What is Pick in TypeScript? Do you know? 🤔

What is Pick in TypeScript?

A Simple Example

Why Use Pick ?

1. Avoid Code Duplication

2. Improve Type Safety

3. Enable Reusable Components

4. Clear Intent

How to Use Pick Dynamically

Let’s go over the Best Practices once more.

1. Use Pick to Build Read-Only Interfaces for UI Components

2. Combine with Omit for Precision

3. Use Named Utility Types

4. Pair with keyof to Create Dynamic Helpers

Visualizing Pick

Conclusion

TL;DR of this Article:

Enjoyed This Article?

Microsoft "Edit" vs Vim: Is Vim dethroned?

A Fresh Take on a Legacy Problem

Key Features of Microsoft Edit

Why Now? Why Windows?

For Vim Veterans: Should You Switch?

For Windows Developers: A Game-Changer

The Bigger Picture: Microsoft Loves the Terminal Again

Final Thoughts

Mastering TypeScript’s Omit—Beginner to Advanced (With Visuals)

typescript #webdev #beginners #cleanCode #javascript

TypeScript Tip: When, Why and How to Use Partial

STELLAR BLOCKCHAIN -YOUTUBE TUTORIAL PLAYLIST

Your Tutorial

Stellar Blockchain Series - YouTube

What I Created

Journey

What Exactly Is `Object.assign()`?

How `Object.assign()` Works

Alternatives to `Object.assign()`

4. Pair with `keyof` to Create Dynamic Helpers