DEV Community: Arpy Vanyan

Being a lead sometimes means you work all day, but no single line of code is committed. Does it mean nothing valuable was done? Well, no... Sometimes, the invisible work we do is much more valuable for the future than you'd think.

Arpy Vanyan — Mon, 14 Apr 2025 14:25:11 +0000

Arpy Vanyan

Apr 10 '25

The Invisible Work of a Frontend Lead (And Why It Matters)

#frontend #leadership #mentorship #agile

Comments

5 min read

The Invisible Work of a Frontend Lead (And Why It Matters)

Arpy Vanyan — Thu, 10 Apr 2025 13:09:06 +0000

When I first stepped into a frontend lead role, I thought my biggest contributions would come from writing cleaner code, refactoring smart components, and shaping the architecture.

And sure, those things mattered.

But over time, I realized something unexpected: the work that made the biggest difference wasn't visible in Git history. It wasn't in the commits, or even on the JIRA board.

It was in the quiet things, the moments between coding, that kept the team moving forward.

This is about that work. The kind that doesn't make it into changelogs but still changes everything.

📌 TL;DR

Being a frontend lead isn't just about writing better code; it's about enabling others to write better code, too.
Much of the real work happens outside of pull requests: unblocking teammates, guiding architecture decisions, mentoring quietly, and translating between product and dev.
Documentation, process, and internal advocacy often feel thankless, but they compound over time and keep the team moving.
You become the calm in the chaos: protecting focus, providing clarity, and making sure people have what they need to do their best work.
It doesn't always look like leadership from the outside, but the impact is real.

You're not just leading code, you're leading clarity

A big part of the job is just helping the team know what the hell is going on.

Product wants X. Design gives you a Figma file full of "magic." Developers are deep in PRs. Everyone's moving but not always in the same direction.

🗣️ As a lead, you're the translator. You speak product, design, and dev, and you help each side make sense to the others.

You break vague desires into actionable work.
You catch misaligned assumptions before they burn.
You fill in the gaps that everyone assumed someone else would fill in.
You explain "why we're doing this now" five different ways to five different people.

Some days, this feels like being the only one who read the manual. Other days, it's more like writing the manual while the game is already in progress.

📝 Invisible task: maintaining the team wiki or architecture docs that everyone forgets until they're absolutely lost.

Architecture isn't just diagrams, it's social

Yes, architecture is components and state management and API boundaries.

But it's also culture.

It's in how people write code when no one's watching. It's in whether developers follow the "good" pattern or the one that got them through the ticket fastest. It's in how much mental resistance a new dev feels when opening a feature folder.

✍🏻 As a lead, you're nudging the architecture constantly. Not with sweeping rewrites, but with comments like:

"Let's move this to a hook"
"This feels like it belongs in a feature module"
"We should wrap this in our reusable API pattern"

Architecture decisions are easy. Getting people to consistently use them is the real work.

Mentorship hides in the gaps

It's not always about talks or pair-programming (though those help). It's in the extra context you add to a code review comment. The time you take to rewrite a confusing ticket. That moment you decide not to fix something yourself so a junior dev can learn how.

Sometimes, mentoring means stepping back, even when it would be faster to just do it yourself.

Other times, it's listening to someone rant about a weird bug just long enough for them to solve it out loud.

🧠 Invisible work is being the person who makes the team smarter without making them feel smaller.

Documentation is boring until it saves the day

I've spent hours writing internal docs that no one noticed... until the one time someone onboards, or breaks a deployment, or asks "where's the config for that?"

📖 Maintaining a team wiki or system overview isn't a perk, but it's the kind of work that pays off over and over again.

A shared architecture overview
Deployment steps with edge cases included
Clear standards for component structure, file naming, API access
Clear steps of branching and commit messages and git flow

Writing it down gives the team fewer reasons to block you and gives you more time to lead, not babysit.

📚 Bonus points if you actually remember to update the docs after a refactor.

You become a developer advocate inside your team

👩🏻‍💼 One of the most valuable (and underestimated) parts of being a frontend lead is standing up for developer experience.

That might mean pushing back on:

UX decisions that ignore real-world behavior
Product deadlines that leave no time for testing
Platform or tooling decisions made without frontend in the room

It also means saying: "We need time to clean this up." Or "This quick fix will become tech debt in a sprint." Or just: "Let me explain how this impacts DX."

💬 You end up being the voice that helps non-devs understand why dev things matter and helps devs feel heard.

The process isn't sexy, but it scales

When you help shape how the team runs (standups, reviews, deployments, testing), you're not just "keeping things organized."

🧘🏻‍♀️ You're reducing cognitive load. You're avoiding bugs before they happen. You're letting people focus on their work instead of wondering what's expected.

Some of the best improvements I've seen came from small process tweaks:

Async check-ins instead of daily calls
Using staging deployments for QA
Making Storybook part of the release flow
Automating changelogs
Creating a checklist for Definition of Done

🛠️ Process isn't about control. It's about flow.

Defending focus is part of the job

🔔 Focus is fragile. Slack pings, vague priorities, "quick requests" - it all adds up.

Sometimes, your job as a lead is simply protecting space for others to work. Saying "not now" so someone can finish what they're building. Blocking distractions. Asking the product team to hold off while the devs finish the current release.

🏅 You might not write a line of code that day, but if your team gets to ship without interruption, you've done your job.

Final thoughts: the best work doesn't always have a commit hash

A lot of frontend leadership isn't about bold architecture changes or fancy patterns.

It's about the dozens of quiet decisions that help the team ship better software.

It's nudging, guiding, unblocking, translating, listening, writing, and occasionally... just staying out of the way.

This work is invisible. But its impact is everywhere.

💬 What kind of "invisible work" do you find yourself doing as a lead?

React Performance: Small Fixes That Made a Big Impact

Arpy Vanyan — Mon, 07 Apr 2025 10:49:15 +0000

When you're building the first version of a React app, performance usually isn’t your top concern. Things feel snappy. It’s just React, right?

Then, the app grows. New features get added, state becomes more complex, components nest deeper, and before you know it, something that used to be smooth starts to feel... sluggish.

I’ve been there. Below are some of the most practical performance lessons I’ve learned while scaling React apps—things I wish I’d done earlier, and fixes that made a noticeable difference without overcomplicating the codebase.

1️⃣ Measure Before You Optimize

It sounds obvious, but it’s often skipped. I used to reach for useMemo or React.memo way too early without knowing what was actually slowing things down.

What actually helps:

🔍 React DevTools Profiler – Spot unnecessary re-renders.

📦 why-did-you-render – Understand what's rendering and why.

⚙️ Lighthouse – Useful for performance audits and slow paints.

🧪 Real user feedback – Often the best indicator something’s off.

Takeaway: Don’t guess. Measure first, then optimize what’s actually slow.

2️⃣ Too Many Renders? Check Your State

One of the biggest performance drains I’ve seen is over-rendering caused by lifted state. It’s tempting to keep things high up in the tree “just in case” other components need access, but that can end up re-rendering the entire subtree.

What helped:

Keep state as close to where it’s used as possible.
Use derived state with memoization.
Apply React.memo only where it helps (after profiling).

Takeaway: Overlifting state leads to over-rendering. Start local, move it up only if needed.

3️⃣ `useEffect` Isn't Your Friend (Most of the Time)

In early projects, I used useEffect for everything: fetching data, syncing state, firing side effects. It worked, but it led to complexity and subtle bugs.

What I changed:

Stopped using effects for things that could be derived or handled declaratively.
Moved server state logic to State Manager.
Created custom hooks to isolate repeated logic.

Takeaway: Reach for useEffect only when there's no better alternative.

4️⃣ Initial Load Times Matter More Than You Think

If your app feels slow to open, users notice. I’ve seen apps load the entire dashboard even when the user just needs the login screen.

What helped:

✂️ Code splitting routes using dynamic import() and React.lazy.
🧹 Tree shaking unused code and libraries.
⚛️ Breaking up giant components into smaller, focused ones.
📊 Using tools like webpack-bundle-analyzer to see what’s in your bundle.

Takeaway: Don’t serve the whole app upfront. Load what the user needs, when they need it.

5️⃣ Lists Are a Performance Trap

Large lists rendered the wrong way will quietly wreck performance. One project had a simple dropdown with 1000+ items rendered without virtualization—it completely froze the UI.

What helped:

Used react-window to only render visible list items.
Avoided anonymous functions inside .map() calls.
Used unique keys (not index) to avoid re-rendering issues.

Takeaway: Lists need extra care. Optimize them early.

6️⃣ Real Debug Example: The Mystery Re-Render

The same seemingly innocent Dropdown component was triggering re-renders across the whole page. It was tied to a parent’s state via props, and every dropdown change re-rendered multiple unrelated charts.

Fix:

Memoized the dropdown to isolate re-renders.
Split state into smaller, targeted slices.
Removed lifted state chain and used shared redux state.

Result: Charts became responsive again, and interaction time dropped by ~200ms.

🧠 Final Thoughts

React performance isn’t about overusing useMemo or blindly adding caching. It’s about understanding how your app renders, keeping things simple, and avoiding unnecessary work.

Start small. Measure. Fix what matters first.

Often, it’s basic architectural decisions—where state lives, how components are composed, how data flows—that have the biggest impact over time.

I've learned things the hard way so you don't have to 👩🏻‍💻

Arpy Vanyan — Mon, 10 Mar 2025 10:59:24 +0000

Things I Wish I Knew Before Scaling a Frontend Codebase 🚀

Arpy Vanyan ・ Mar 7

#javascript #webdev #scaling #react

Things I Wish I Knew Before Scaling a Frontend Codebase 🚀

Arpy Vanyan — Fri, 07 Mar 2025 13:54:59 +0000

Introduction: The Growing Pains of a Frontend Codebase

Every frontend project starts small and simple—a few components, some state management, maybe a couple of API calls. Fast forward a year, and suddenly:

❌ Code reviews take forever
❌ Making a small UI change breaks unexpected parts of the app
❌ Deployments become stressful, debugging is a nightmare
❌ Onboarding new developers takes weeks

I’ve been through multiple frontend projects that hit these exact roadblocks. Looking back, there are things I wish I had done earlier to avoid the mess.

In this article, I’ll share 10 key lessons I’ve learned about scaling frontend codebases the hard way.

1️⃣ Keep the Codebase Modular From Day One

The mistake: Everything was dumped into a single components/ folder with zero structure.
The fix: Organize by feature, not type (e.g., features/dashboard/ instead of components/).
Takeaway: A modular codebase scales better, and refactoring later is painful.

✅ Best Practice:
📌 Use feature-based architecture
📌 Keep components small & reusable
📌 Separate UI, state, and logic early

2️⃣ Choose the Right State Management Approach Early

The mistake: We started with a custom state manager, which worked until it didn’t.
The fix: Use the simplest state management solution that fits your needs (Context API, Zustand, Redux, or React Query).
Takeaway: Overcomplicated state management is a tech debt time bomb.

✅ Best Practice:
📌 Keep local state inside components whenever possible
📌 Use React Query for server state instead of Redux
📌 Avoid prop drilling hell with Context or Zustand

3️⃣ CI/CD & Automated Deployments Are Not an Afterthought

The mistake: Manual deployments led to human errors and broken releases.
The fix: Automate the entire process (testing, builds, deployments) using CI/CD tools.
Takeaway: If you don’t automate early, you’ll regret it when your team grows.

✅ Best Practice:
📌 Set up NX or Turborepo for efficient builds
📌 Use feature flags to safely deploy unfinished features
📌 Run automated tests before merging

4️⃣ Performance Optimization Is Important

The mistake: We didn’t care about performance until users started complaining.
The fix: Optimize early by monitoring bundle sizes and network requests, note any unnecessary re-renders.
Takeaway: Performance bottlenecks are much harder to fix later.

✅ Best Practice:
📌 Use lazy loading & code splitting (React’s Suspense)
📌 Optimize bundle size with tree shaking
📌 Minimize re-renders with React.memo & useCallback

5️⃣ Proper Testing Saves You From Deployment Nightmares

The mistake: We relied on manual testing instead of automating tests.
The fix: A solid test strategy includes unit, integration, and E2E tests.
Takeaway: The best time to start writing tests was yesterday.

✅ Best Practice:
📌 Write unit tests for critical business logic
📌 Use React Testing Library for component tests
📌 Add Cypress or Playwright for E2E tests

6️⃣ Avoid Over-Engineering: Simple Is Better

The mistake: We overcomplicated everything with abstractions and unnecessary layers.
The fix: Build for today’s needs, but design with tomorrow in mind.
Takeaway: Complexity grows fast; keep it as simple as possible.

✅ Best Practice:
📌 Don't abstract too early—wait until patterns emerge
📌 Avoid unnecessary custom hooks if built-in hooks work fine
📌 Keep dependencies minimal to reduce tech debt

7️⃣ Documentation Is a Lifesaver

The mistake: The codebase relied on tribal knowledge, making onboarding painful.
The fix: Keep lightweight, useful documentation (not just API specs).
Takeaway: Well-documented projects are easier to scale.

✅ Best Practice:
📌 Use Storybook for UI documentation
📌 Maintain a simple README with architecture decisions
📌 Write code comments where necessary (but don’t overdo it)

8️⃣ TypeScript Will Save You From a Lot of Debugging

The mistake: Started with plain JS, then struggled with undefined errors everywhere.
The fix: Adopted TypeScript to reduce runtime errors.
Takeaway: Types catch issues before they become bugs.

✅ Best Practice:
📌 Use TypeScript from day one
📌 Type function props and API responses properly
📌 Keep types clean (avoid any at all costs!)

9️⃣ API Communication Should Be Standardized

The mistake: Different parts of the app handled API requests inconsistently.
The fix: Created a unified API service with consistent response types and error handling.
Takeaway: Standardized API calls reduce bugs & improve maintainability.

✅ Best Practice:
📌 Use React Query or SWR for fetching
📌 Centralize API logic in a single module
📌 Use error boundaries to catch failures gracefully

🔟 Scaling a Frontend Isn’t Just About Code; It’s About Process

At the end of the day, a scalable frontend isn’t just good architecture—it’s also about workflow, automation, and team collaboration.

If I could go back in time, I’d tell myself:
✅ Plan for modularization early
✅ Keep things simple
✅ Invest in automation, testing, and CI/CD before they become pain points

💡 What’s your biggest lesson from scaling a frontend? Let’s discuss in the comments!

From Spaghetti to Scalable: How I Modularized a Growing Frontend Codebase

Arpy Vanyan — Mon, 24 Feb 2025 10:27:48 +0000

Introduction: The "Oh No" Moment

At some point in my career, I took over a large React app that seemed fine at first — until it wasn't. 😅

The project had evolved over time, but instead of growing gracefully, it became an unmanageable beast:

❌ A custom state manager — hard to debug & scale.
❌ Massive UI components — mixing business logic, API calls, and UI.
❌ Multiple UI versions for different clients — but all versions lived in the same codebase.
❌ Releases were painful — changing one part could break something completely unrelated.

At some point, I realized: This is unsustainable.

👉 This is the story of how I refactored that messy frontend into a modular, scalable, and maintainable system without breaking everything along the way.

🎯 TL;DR

Messy frontend code? Modularization is the key!
Break down your code into components, features, and domains.
Keep UI, logic, and data handling separate.
NX monorepos solve interdependency issues.
Start small, refactor in steps, and enforce structure with tools.

Phase 1: The Giant Monolithic App Era

At the start, our React app was an all-in-one monolith:

Custom state management. We had built our own instead of using Redux or anything else (Context API was not that powerful yet).
UI + logic bundled together. a single component could be over 500 lines long.
Multiple UI versions in one repo. Each client required a slightly different UI, but instead of separating them, all versions coexisted in the same codebase.
A single repo handled everything. State, API calls, business logic, and UI, making it hard to maintain and even harder to onboard new developers.

Biggest Pain Points:

🚨 Scaling was impossible. As we added more clients, the complexity multiplied.
🚨 Code duplication was everywhere. Reusing functionality meant lots of copy-pasting.
🚨 UI modifications were a nightmare because each client had different design needs, we had tons of if statements handling different layouts.

Lesson Learned:

A single repository containing everything isn't just inefficient — it's a ticking time bomb.

Phase 2: Splitting the Monolith — The First Step to Modularization

Realizing the mess, I decided to refactor the app into separate repositories, each handling a specific concern.

The New Modular Structure:

✅ A React component library 📦

Contained state, API interactions, and core functionality.
Single source of truth for all logic — no more duplication.

✅ A separate UI module 🎨

A pure extension of Bootstrap CSS — no JavaScript, just styling.
Clients could now have different layouts without affecting the app logic.

✅ A React app for pages & UX 🏗️

Handled routing, layouts, and page composition.
Different apps could now be built using the same API + component library.

What Changed?

🚀 More flexibility — we could create apps with different layouts without duplicating code.
🚀 Easier maintenance — frontend developers could work on UI without touching business logic.
🚀 Cleaner separation of concerns — each module had a clear responsibility.

👉 The refactor was a game-changer. But it introduced a new challenge: managing interdependent packages.

Phase 3: The NPM Link Hell & How NX Saved the Day

After splitting the project into multiple repos, we ran into another problem:

⚠️ Local development became painful. We relied on npm linking to work across multiple co-dependent packages.
⚠️ Syncing changes was slow. Any update to one package had to be manually managed in others.
⚠️ Onboarding became complicated. New developers had to manually set up multiple repos just to get started.

I realized that managing separate repos was becoming its own problem.

The Solution: NX Monorepo

To simplify development, we moved all modules into an NX workspace:

✅ Unified repository structure — All projects lived in one place.
✅ Built-in dependency graph — NX automatically understood how modules were connected.
✅ Faster builds — NX only rebuilt the parts of the code that changed.

👉 The migration strategy was key. To avoid disruption, we:

Created the app from scratch in the NX workspace.
Copied the existing React component library without changing logic, just refactored class components into hooks.
Introduced two additional modules to improve the architecture and add features.

What Changed?

🚀 Modular, scalable development — each team could now work on their own package without affecting others.
🚀 Faster iteration — no more npm linking headaches!
🚀 Better collaboration — dedicated teams worked on separate parts of the frontend.

👉 With NX, we finally had a system that was both modular and manageable.

Next Steps: Refining the NX Architecture 🚀

While migrating to an NX monorepo significantly improved our workflow, there's still room for further modularization. The next phase will focus on enhancing maintainability and scalability by:

✅ Breaking Down Features into Micro Packages
Currently, our React component library contains both core functionality and feature-specific logic. To better align with NX's best practices, we'll:

Extract feature-specific modules into standalone NX packages (e.g., @myorg/task-list, @myorg/profile).
Ensure each feature package is independent and reusable across multiple applications.
Reduce interdependencies between features to simplify development and deployment.

✅ Introducing Documentation with NX Storybook
To improve*developer experience and collaboration, we'll:

Integrate NX Storybook for our UI components and feature modules.
Provide interactive documentation where developers can preview and test components.
Standardize our design system and API contracts to maintain consistency across projects.

With these improvements, our NX workspace will become even more scalable, well-documented, and developer-friendly — allowing teams to work more efficiently with clearly defined boundaries between features.

Final Takeaways: Lessons I Learned the Hard Way 😅

1️⃣ Start modularizing early. Don't wait until the project is too big to handle.
2️⃣ Separate UI, logic, and state from the beginning. This saves countless hours of refactoring later.
3️⃣ Avoid unnecessary complexity. Modularization should make things easier, not harder.
4️⃣ Consider a monorepo for interdependent projects. NX solved many problems for us.
5️⃣ Migrating gracefully is key. Doing it step by step prevented downtime.

Conclusion: Keep It Simple, Keep It Scalable 🚀

Modularization isn't about making things complex — it's about making them manageable.

💡 If I were to start a frontend project today, I would:

✅ Use a component-based architecture from day one.
✅ Decouple UI from business logic immediately.
✅ Consider a monorepo for interconnected projects.
✅ Ensure teams have ownership over separate modules.

🔹 Have you ever had to refactor a messy frontend codebase?
🔹 What's your go-to strategy for keeping your projects modular?

💬 Drop a comment — I'd love to hear your experiences!

📌 Want to Learn More?

🔗 Here is more of my experience in scaling forntend apps:

Things I Wish I Knew Before Scaling a Frontend Codebase 🚀

Arpy Vanyan ・ Mar 7

#javascript #webdev #scaling #react

🔥 Like this post? Share it with your dev friends!

Iterators in JavaScript Explained with Coffeeshops

Arpy Vanyan — Tue, 18 Feb 2025 12:51:04 +0000

An Iterator is an Iterable of Itself

Wait… What?! 🤯

Yeah, I know—it sounds like a weird riddle from a programming wizard. But trust me, once you get it, you’ll never forget it.

JavaScript Iterators are often misunderstood, but the truth is:

"An Iterator is just an Iterable of itself."

💡 Let’s break down this concept with a fun analogy, some visual aids, and real-life relatable examples. If you’ve ever waited in line at a coffee shop, you already know how iterators work. ☕🔄

🎯 TL;DR

Iterables have a Symbol.iterator() method.
Iterators have a next() method that returns { value, done }.
If an iterator returns itself from Symbol.iterator, it becomes an iterable of itself.
Coffee queues act like iterables. ☕

☕ Imagine a Coffee Queue

Picture this: you walk into your favorite coffee shop and see a queue of people waiting to order.

This queue of customers is like a JavaScript iterable—a collection of people you can go through one by one.

And guess what? The person serving the line (the barista) is like the iterator.

☕ The queue = Iterable (the collection)
👩‍🍳 The barista = Iterator (the one going through the collection)

🧠 Here’s the key insight:

The barista (iterator) is also part of the queue (iterable).

🤯 Wait… How?

In JavaScript:

An iterator is an object that knows how to access items one-by-one.
An iterable is an object that has a special method (Symbol.iterator) that returns an iterator.

💡 The twist:

If an iterator returns itself when Symbol.iterator is called, it’s both an iterator and an iterable. 🤯

🎯 Code Time! Let's See It in Action

Here's a simple custom iterator in JavaScript that iterates over coffee orders:

const coffeeOrders = {
  orders: ["Latte", "Espresso", "Cappuccino"],
  index: 0,

  // Iterator next() method
  next() {
    if (this.index < this.orders.length) {
      return { value: this.orders[this.index++], done: false };
    }
    return { value: undefined, done: true };
  },

  // Make the object an iterable of itself
  [Symbol.iterator]() {
    return this;
  }
};

// Iterating through coffee orders
for (const order of coffeeOrders) {
  console.log(`☕ Order: ${order}`);
}

🧠 What's Happening Here?

next() Method: The barista (iterator) goes through each coffee order one by one.
Symbol.iterator() Method: Returns this, meaning the iterator is also the iterable.

📌 Output:

☕ Order: Latte ☕ Order: Espresso ☕ Order: Cappuccino

💡 See what we did there?
By returning this inside Symbol.iterator(), we made the same object act as both the iterator and the iterable.

🖼️ Visualizing the Concept

Imagine this coffee queue visually:

+---------------------+
|  ☕ Latte            |
+---------------------+
|  ☕ Espresso         |
+---------------------+
|  ☕ Cappuccino       |
+---------------------+
|  👩‍🍳 Barista (Iterator)|
+---------------------+

The Barista (iterator) moves through each order.
But... the Barista is also in the queue.

The barista is both:

Serving the orders (iterator)
Part of the queue (iterable)

🧠 So... Why Does This Matter?

Understanding that "An Iterator Is an Iterable of Itself" helps when:

✅ Creating custom iterators like the coffeeOrders example.
✅ Working with generator functions (which return themselves as iterators).
✅ Debugging confusing iterator-related bugs.

🔍 Built-in Iterators That Follow This Rule

JavaScript already does this with arrays, sets, maps, and strings.

Check this out:

const drinks = ["Tea", "Coffee", "Juice"];

// The array is both iterable and has an iterator
console.log(drinks[Symbol.iterator]() === drinks[Symbol.iterator]()); // false (new iterator each time)

// But calling next() works just like with our custom iterator:
const drinkIterator = drinks[Symbol.iterator]();
console.log(drinkIterator.next()); // { value: 'Tea', done: false }
}

Arrays don't return themselves directly but generate a new iterator.
But our coffeeOrders object does---making it both an iterator and an iterable of itself.

🤓 The Takeaway (with Coffee!) ☕

"An Iterator is Just an Iterable of Itself" means:

An iterator must implement a next() method.
If Symbol.iterator returns the same object, it becomes an iterable as well.
The same object can both produce items and represent the collection being iterated over.

☕ Final Thought: Coffee and JavaScript are Both Better When Shared!

Next time you wait in a coffee queue, remember:

The barista isn't just serving customers---they're also part of the system.
Just like an iterator that iterates over its own collection.

💬 Did this analogy help the concept click?
Drop a comment below and share your own JavaScript insights! 🚀

💡 Happy coding! 🔄☕

Building a Scalable Delivery Pipeline for Small Teams 🚀

Arpy Vanyan — Wed, 12 Feb 2025 13:13:11 +0000

Introduction

A well-structured delivery pipeline ensures that software is shipped smoothly, reliably, and with confidence. Whether you're working in a small team or a large enterprise, having a clear, repeatable process is critical for delivering high-quality software.

This article breaks down a delivery pipeline setup I implemented for a project, optimizing it for small teams. It includes staging best practices, automated deployments, package management, and a ticketing system that simplifies releases.

If you're setting up a CI/CD workflow or refining your software deployment process, this guide is for you! 🚀

🎯 TL;DR

✔️ Always deploy to staging first before production.
✔️ Use nightly builds to test new features early.
✔️ Automate package publishing and CI/CD deployments.
✔️ Keep staging clients on staging APIs to prevent conflicts.
✔️ Use Jira statuses like "Ready for Deploy" to improve workflow.

1️⃣ The Importance of Staging

Why Staging?

Before any new feature or fix goes live, it must be tested in an environment that closely mimics production.

A staging environment serves as a sandbox for QAs and stakeholders to validate changes before they reach real users.

Golden Rule:

Never ship any new code to production if it has not yet been tested and approved for deployment!

But how should the testers access the changes if they exist only on the developer’s local system?

As the testers should act like end-users and not a part of the dev team, they should be able to access the final products in an environment that replicates the live version and includes all the latest changes that are ready to be tested. That is the staging environment.

So, the dev team should always deploy the latest finished changes to the staging environment and ask the QA to test them. Normally, the deployment might include some issues and bugs (which doesn’t mean that the dev shouldn't test everything locally first), which the testers will notice and report.

When the testers and the PO approve the current state of the staging environment, the team prepares for a release on production.

Deployment to Staging

Developers push their latest changes to staging.
Testers (QA) validate everything as end-users would.
Product Owners (POs) approve before release.
If it’s good, it goes live!

2️⃣ Think of Your Product Like a Pizza 🍕

Your product is like a pizza—it’s made up of different slices (components), and they all need to come together seamlessly when deployed. In most cases it is like a 3-slice pizza in fact:

In this case, a deployment includes:

1️⃣ Packages (code libraries and dependencies)

2️⃣ The Server (backend APIs)

3️⃣ The Client (front-end applications)

Each of these components must be properly staged, tested, and released together for a smooth rollout.

3️⃣ Managing Packages Efficiently

Most modern development relies on package management to handle dependencies. Here’s how to keep it clean:

Staging Packages with Nightly Builds 🌙

When developing a new feature, testers should have access to pre-release versions. A nightly build ensures the latest changes are packaged daily.

📌 How to publish a nightly build:

npm publish --tag nightly

✅ Benefits:

Allows early testing before an official release.
Ensures integration issues are caught early.
Automates packaging, reducing manual effort.

Production packages, on the other hand, should be versioned properly using semantic versioning (semver) for clarity.

4️⃣ Deployment Workflow: From Code to Production 🚀

Note: Remember to set the dependency packages in nightly builds to refer to their nightly versions.

The Server

Runs in cloud or dedicated server, hosting the backend APIs.
New code is deployed to staging first before production.
The CI/CD pipeline automates deployment.

The Client

Any changes in the front-end must be deployed in sync with the backend.
If a client instance depends on a new API, it must be tested in staging first before being moved to production.

5️⃣ Streamlining Task Management with Jira 📋

As we want the testers to have something already deployed to Staging for them to start testing and avoid doing it locally, we need to have a new state on for the tickets called “Ready for deploy”.

It would mean the following: “The code was written and reviewed and is ready to be delivered to the testers”.

Old Ticket Flow:

To Do → In Progress → Code Review → Testing → Done

New & Improved Workflow:

✅ To Do → In Progress → Code Review → Ready for Deploy → Testing → Done

After the sprint is finished and all the Done tasks are approved, the PO will identify the features that are ready to be delivered to the customers. For this kind of work, we will have separate deployment tasks that would skip the 3d and 4th steps during realization.

💡 Why this change?

Before, testers had to wait and guess when developers manually deployed the latest version to staging.
Now, with "Ready for Deploy", testers know when a feature is available in staging.
This reduces bottlenecks and improves release efficiency.

🚀 Result: Faster deployments, happier testers, and smoother releases!

6️⃣ Final Steps to a Cleaner Pipeline

To fully optimize the delivery process, these improvements should be implemented:

[Task Management] Add a "Ready for Deploy" status in Jira.
[Automation] Improve CI/CD scripts to auto-publish nightly builds.
[Versioning] Use semantic versioning for clarity in releases.
[CI/CD Improvements] Automate deployment of server and client to both staging and production.
[Environment Fix] Ensure all staging clients use staging APIs only.

🚀 By implementing these best practices, small teams can maintain a highly efficient delivery pipeline without unnecessary delays or confusion.

Conclusion: Why This Works for Small Teams 🏆

A structured delivery pipeline isn't just for large teams---it's critical for small teams too!

By automating testing and deployments, keeping environments clearly separated, and simplifying task tracking, you can:

✅ Ship faster
✅ Catch bugs earlier
✅ Reduce deployment stress

If you're setting up a CI/CD process for your team, start with these principles---they will save you a ton of headaches in the long run!

💬 What challenges have you faced with setting up a delivery pipeline? Let's discuss in the comments! 🚀

The Prototype Chain Explained with a Library System 📚

Arpy Vanyan — Sun, 09 Feb 2025 12:44:42 +0000

Ever borrowed a book from a library? Good. You already understand JavaScript Prototypes.

Imagine you walk into your neighborhood library looking for a rare book on "The Secrets of JavaScript Sorcery." You ask the librarian, but—oops!—your library doesn’t have it.

But don’t worry! Instead of sending you home empty-handed, the librarian calls up the central city library to check if they have it. If they do, you get your book. If not, the search continues up the chain… maybe to the National Library Archive. And if even they don’t have it? Sorry, no book for you.

This is exactly how JavaScript’s prototype chain works! 🚀

📌 TL;DR

Objects in JavaScript can inherit properties from other objects.
When a property isn't found in an object, JavaScript climbs up the prototype chain to check its prototype.
Object.create() is like opening a new library branch connected to the central library.
If a property isn't found anywhere, JavaScript returns undefined.

🏛 Libraries = JavaScript Objects

In JavaScript, objects can borrow properties and methods from other objects, just like a library can request books from a bigger library system. Let’s break it down:

1️⃣ Local Library (Your Object)

Your library has its own collection—books it directly owns.

const localLibrary = {
  specialCollection: ["Ancient Maps", "Rare Manuscripts"]
};

console.log(localLibrary.specialCollection);  
// ["Ancient Maps", "Rare Manuscripts"]

2️⃣ Central Library (Prototype)

But what if your local library doesn't have a specific book? It asks the Central Library, which has a much bigger collection.

const centralLibrary = {
  lendBook: function() {
    console.log("Here's your book from the central archive!");
  }
};

3️⃣ Connecting Them (Prototype Chain)

Now, let's link your local library to the central one using Object.create(). This way, whenever your local library doesn't have something, it automatically looks in the central library!

const cityLibrary = Object.create(centralLibrary);
cityLibrary.specialCollection = ["Ancient Maps", "Rare Manuscripts"];

console.log(cityLibrary.specialCollection);
// ["Ancient Maps", "Rare Manuscripts"]

cityLibrary.lendBook();
// "Here's your book from the central archive!"

Even though lendBook wasn't defined in cityLibrary, it still worked! That's because JavaScript climbed up the prototype chain and found it in the centralLibrary.

🛤 The Search Path (Prototype Chain in Action)

Let's add another library: a small-town library that borrows from the city library.

const smallTownLibrary = Object.create(cityLibrary);
console.log(smallTownLibrary.specialCollection);
// ["Ancient Maps", "Rare Manuscripts"]

Boom! Even though smallTownLibrary doesn't have a specialCollection directly, it inherits it from cityLibrary, which inherited it from itself.

And it can still borrow books from the central library:

smallTownLibrary.lendBook();
// "Here's your book from the central archive!"

🔗 JavaScript keeps searching up the chain until it finds what it needs---or gives up!

❌ What Happens If a Book Doesn't Exist?

Let's say you ask for a mystery book that no one owns:

console.log(smallTownLibrary.rareBook);
// undefined

JavaScript checks:

1️⃣ smallTownLibrary → ❌ (Doesn't have it)\
2️⃣ cityLibrary → ❌ (Doesn't have it either)\
3️⃣ centralLibrary → ❌ (Nope!)\
4️⃣ Object.prototype → ❌ (Last stop---if it's not here, it doesn't exist)

Since no one has it, you get undefined.

📌 This is exactly how JavaScript searches for properties in objects.

🖼 Visualizing the Prototype Chain

💡 Want an easier way to visualize the Prototype Chain?\
Here's what our example looks like behind the scenes:

smallTownLibrary  --->  cityLibrary  --->  centralLibrary  --->  Object.prototype  --->  null

Every object in JavaScript follows this chain all the way up to Object.prototype, which is like the National Library Archive---the place where common methods like .toString() exist.

🎯 Final Thoughts

Next time you're borrowing a book from a library, think about JavaScript's prototype chain working in the same way. Your local branch (object) might not have a book (property), but it always knows where to look!

This is what makes JavaScript so powerful and flexible---objects can share behavior without copying everything manually.

Now that you've cracked the mystery of Prototypes, where should we go next? 🤔

💡 Thinking about writing an article on how new works in JavaScript? Let me know!

💬 What do you think?

Have you encountered prototype chains in your projects? Let me know your thoughts and experiences in the comments below! 🚀

JavaScript Array.reduce() explained with LEGO bricks

Arpy Vanyan — Thu, 20 Sep 2018 14:03:26 +0000

We all must agree that JavaScript is great! But you know what? LEGO is even greater! Why? Because you can explain and model so many ideas and behaviors and algorithms using this amazing toy 🚀.

“assorted-color plastic toy lot” by Rick Mason on Unsplash

Definition

The Mozilla Developers Network defines the reduce method in Array object prototype like this:

The reduce() method executes a reducer function (that you provide) on each member of the array resulting in a single output value.

Your reducer function’s returned value is assigned to the accumulator, whose value is remembered across each iteration throughout the array and ultimately becomes the final, single resulting value.

All right, but when and how I can use this function? Is it only for summing all the numbers in an array? Is there a real-world example? And what do this Accumulator (acc), Current Value (cur), Current Index (idx) and Source Array (src) stand for?

🧒🏻 Let’s dive into the kid’s room for a nice explanation.

The colorful blocks

Let’s be honest, I’m a totally incorrigible LEGO addict 🤪. Ah, those colors, shapes, and possibilities to build anything you can imagine out of them…

Now, as I don’t have so much time to spend on them, I prefer to have all the sets built up and displayed on a shelf as they should look like according to the model. But, from time-to-time (especially when the kids get their hands over my precious collection) all of my sets get mixed up and thrown in a big container altogether. Oh, what a mess… And then comes the time for me to gather all my supplies, strength and motivation to bring them back onto their shelves.

But wait, what about reducers? Okay, so before I can restore my displayed collection, I need to build them, and to do that, I need to know which piece belongs to which set. Then I would be able to construct the sets with their instructions (as if I don’t know the instructions by heart 😁).

And here comes the time for my brain to use a perfect array reducer!

Let’s reduce the bricks

Okay, so for the ease of the example, let’s assume that there are no shared blocks among the different sets. So I know, that if I see a black 2x2 block, I know that it belongs to my Star Wars B-Wing Fighter and all my red windows belong to an old family house set. Let’s assume I have only 3 LEGO sets: a B-Wing, a Harry Potter forbidden corridor room and a simple old house with white walls and red roof.

So, here is my container of all the bricks messed up together.

const bricks = [
    {set: 'b-wing', type: 'brick', size: '2x2', color: 'black'},
    {set: 'house', type: 'roof', size: '4x2', color: 'red'},
    {set: 'hp', type: 'spider', size: '1x1', color: 'black'},
    {set: 'b-wing', type: 'panel', size: '4x8', color: 'gray'},
    {set: 'b-wing', type: 'brick', size: '2x2', color: 'black'},
    {set: 'house', type: 'brick', size: '6x1', color: 'white'}
]

I want to arrange them into boxes with LEGO sets like this:

{"b-wing": [], "house": [], "hp": []}

📥📥📥 I haven't prepared the labeled boxes, so I will do it along the way, as soon as I stumble upon a piece that doesn’t have a box yet.

So, what I am going to do, is to loop through all the bricks and put each of them into the corresponding box. Here are some statements from the process:

Initially , I have no boxes prepared for each set, but I know that I am going to put the boxes on a special shelf.
I take out a new brick from the initial container, process it in mind, decide where it belongs to, and put the current brick into its set box.
If there is no box for the set of my current piece, I create and label a new box and put it on the shelf.
Each time I take a brick from the initial container, I reduce the number of all bricks left to arrange.
Finally, when there is no brick left in the initial container to process, I look at my shelf and see that my mixed pile of LEGO bricks got transformed into a structured arrangement of labeled boxes on my shelf.

So, in other words (or in visual), I will transform the pile on the left into the organized structure on the right:

The transformation result

👩🏻‍💻 If someone would have coded this whole process in JavaScript using the Array.reduce() method, it would look like this:

const bricks = [....]; //the pile of bricks defined above

const shelf = bricks.reduce((shelfOfBoxes, brick, brickNumber, pile) => {

    console.log(`Checking the brick number ${brickNumber + 1}`);

  if(!shelfOfBoxes.hasOwnProperty(brick.set)) {
        shelfOfBoxes[brick.set] = []; //add a new box if needed
    }
    shelfOfBoxes[brick.set].push(brick); //put the brick in its box

    console.log(`Bricks left: ${pile.length - (brickNumber + 1)}`)
}, {} ); //the empty shelf

console.log(shelf);

And what do we have here?

Initially I have a mixed pile of bricks stored in an array
Initially my shelf is empty. The second argument in the reduce function is the initial value of the shelf, which is an empty object: {}
I loop through the array with the reduce method
In each iteration of the loop I know the following: the current situation on the shelf (shelfOfBoxes), the current brick I’m processing (brick), which is the current index of the brick/how many I have already processed (brickNumber) and the initial bunch of bricks (pile)
During each loop, I check if there is a box with the set name for my current brick on the shelf: if(!shelfOfBoxes._hasOwnProperty_(brick.set))
In case there is no box, I add a new empty box with the label of current brick’s set to the shelf: shelfOfBoxes[brick.set] = [];
Then I put the current brick into the box for its set: shelfOfBoxes[brick.set]._push_(brick);
I note to myself how many bricks are left in the pile: console.log(Bricks left: ${pile.length — (brickNumber + 1)})
In the end I have a shelf of boxes filled with all the bricks that belong to each set box

So I used a reducer function to transform an array of objects into something completely different. That is the purpose of the Array.reduce() method.

Done

Cool, now you should have a clue on what is the reduce method, what are its arguments, and what is a real world example when our brain works like a reducer 🧠.

Of course there are other possibilities and use cases for the Array.reduce() method. You should also know that the initial value of the transformation is optional. I already know another brick-related example for that case. Stay tuned for another article with the detailed explanation coming soon 📢.

And, of course:

How to log out when using JWT

Arpy Vanyan — Sun, 17 Jun 2018 10:46:42 +0000

The wonder of JSON Web Tokens

JSON Web Tokens (JWT) is a way of statelessly handling user authentication. What does it mean? Well, JWT helps to organize authentication without storing the authentication state in any storage be it a session or a database. Thus, when checking user’s authentication status you do not need to access the session or perform a database query. Instead, you generate a token based on the user payload of your choice and use it in requests from client side to identify the user on server. 🛂

So, basically, whenever a token is created, it can be used forever, or until it is expired. JWT generator can get an option to invalidate the token after specified time.

But what to do if you want to invalidate an existing token? What you actually need to do when the user opts to log out, or let’s say change password? 🤔

Let’s log out

Okay, so usually, when using JWT authentication, the client side stores the token somewhere and attaches it to every request that needs authentication. So, the first thing to do when logging out, is just delete the token you stored on the client (e.i. browser local storage). In that case the client won’t have a token to put in the request, thus causing unauthorized response status. But is that enough? Well, that specific client (browser, app) won’t be authenticated any more, but the token still exists somewhere and it is still valid! If someone has copied the token from the request before, he/she would still be able to perform requests on behalf of the user! 👾 You can easily try this out on your own.

“Okay, so let’s log out the user from the backend!” you would say. But hold down the horses. It’s not that simple with JWT. You cannot delete the session or cookie and get going.

Actually, JWT serves a different purpose than a session and it is not possible to forcefully delete or invalidate an existing token.

Expiring a token?

Yes, the tokens can be expired. No, you cannot do it on demand.

When signing a user payload for a JWT you are allowed to pass an expiration time to it. You can provide it as a field called exp in the payload like this:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516234022,
  "exp": 1516239022
}

The expiration field takes number of milliseconds since the start of Unix epoch. As the iat field here stands for “issued at”, this token is set to expire 5 seconds after it was issued. ⏰

Note: If you are using one of the JWT libraries listed here, most likely you can also pass an expiration time in the signing method options.

If you don’t want to have forever valid tokens, you should always set a reasonable expiration time on you JWT. The amount of time really depends on your application. We’ll go with one day tokens here and generate them in our login action. For a NodeJS app the code should look something like this:

const jwt = require('jsonwebtoken');

const payload = {
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516234022
}

const token = jwt.sign(payload, 'your-secret', {expiresIn: '1d'})

So, when the token expires, the validator will return an error and you backend will respond with an unauthorized response status as soon as it gets a request that needs authorization. Usually, you will unset the token from the client side and redirect the user to the login page. So, with this example, all users will be automatically logged out after 1 day of using your app.

“Cool, but I still want to log out!” ➡️

As already said, you cannot manually expire a token after it has been created. Thus, you cannot actually log out with JWT on the server side 🙀Or, unless, you can…

It is said that using JWT should be stateless, meaning that you should store everything you need in the payload and skip performing a DB query on every request. But if you plan to have a strict log out functionality, that cannot wait for the token auto-expiration, even though you have cleaned the token from client side, then you might need to neglect the stateless logic and do some queries.

An implementation would probably be, to store a so called “blacklist” of all the tokens that are valid no more and have not expired yet. You can use a DB that has TTL option on documents which would be set to the amount of time left until the token is expired. Redis is a good option for this, that will allow fast in memory access to the list. Then, in a middleware of some kind that runs on every authorized request, you should check if provided token is in The Blacklist. 🕵️‍ If it is you should throw an unauthorized error. And if it is not, let it go and the JWT verification will handle it and identify if it is expired or still active.

Conclusion

One does not simply log out with JWT…

As it seems, creating a clean log out flow when using JSON Web Tokens is not so straightforward. You should either let a token be active until it is expired by itself, or opt to use a storage for logged out tokens if you want to restrict the usage of a token when a user logs out. To sum it all up, simply follow this 4 bullet points:

Set a reasonable expiration time on tokens
Delete the stored token from client side upon log out
Have DB of no longer active tokens that still have some time to live
Query provided token against The Blacklist on every authorized request

image credit: cartermatt.com

HTML5 form validation in React

Arpy Vanyan — Sun, 18 Feb 2018 16:47:47 +0000

“Colorful lines of code on a computer screen” by Sai Kiran Anagani on Unsplash

Best data is a validated data

Users… Data collection… Forms… I’m sure you know that user input is good when it is valid ✅. That is why websites must encourage the users to fill in the best fitting data whenever possible.

There are various libraries like jQuery Validation or Validate.js, that help with form input validations. All of them implement the idea of performing predefined checks on each of the form fields before it is submitted. Then, they display error messages, if there are fields that do not qualify.

But there is also the powerful HTML5 validation API. And it’s awesome. Modern browsers almost fully support the API. Of course, each of them implemented its own way of performing the validation and displaying error messages. And sometimes it looks really nasty 🙈

So, why not implement our own layout for the validation errors? Sounds doable. We will use the following aspects from the HTML5 constraint validation API: the checkValidity method and the :valid/:invalid states of a form, and the validity property of form elements. If curious, they are explained in detail in this superb MDN Web Docs (Mozilla Developer Network) page. What I am going to do is to implement custom validation messages using the API for a React app. Let’s go! 🏁 🚗

The React Component

Well, React means Components! We surely need to create one for this task. And, surprisingly, it will be a custom stateful Form component with its corresponding styles file.

First of all, let's define how we want to display our validation errors. I prefer to have separate messages next to each form field. For our ease, we will assume, that every input field is assigned with .form-control class, and each of them has a sibling <span> with an .invalid-feedback class. Each span will hold the error message of its relevant form element. In this implementation, each form element will have its own error message container next to it. Of course, you are free to define your own error containers and even have only one container for displaying all of the messages in one place.

As you might already know, the validity of a form element is identified by a CSS pseudo class. If the element (input, textarea, checkbox,…) passes the defined rules, it is assigned with :valid pseudo class. Otherwise it gets :invalid pseudo class. We will use this behavior do decide whether an error message should be displayed next to an element or not. We’ll define a style in our Form.css that will hide the messages of valid elements.

.form-control:valid~.invalid-feedback {display: none;}

The idea of the component is the following. In React, typically, we don’t want to reload the page on form submission. Instead, we want to send the data with ajax request. It doesn’t matter for our validation component how and what data is submitted. We just handle validation. That is why it will receive a property named submit, which is a function, that should be called whenever the form is allowed to be submitted. The component will override the native form submit event in the following way. First, it will check the overall form validity with the checkValidity method. If no errors found, it will perform the submission by calling the submit method from props. If there was at least one invalid element, it will show the corresponding messages and cancel the form submission. And, of course, the component will render a regular <form> tag, with all the child elements nested inside.

Sounds pretty straightforward, right? Let’s see how it looks like as a code 😉

import React, {Component} from 'react';
import PropTypes from 'prop-types';
import './Form.css';

class Form extends Component {
    state = {
        isValidated: false
    }

    validate = () => {
        const formLength = this.formEl.length;

        if (this.formEl.checkValidity() === false) {
            for(let i=0; i<formLength; i++) {
                const elem = this.formEl[i];
                const errorLabel = elem.parentNode.querySelector('.invalid-feedback');

                if (errorLabel && elem.nodeName.toLowerCase() !== 'button') {
                    if (!elem.validity.valid) {
                        errorLabel.textContent = elem.validationMessage;
                    } else {
                        errorLabel.textContent = '';
                    }
                }
            }

            return false;
        } else {
            for(let i=0; i<formLength; i++) {
                const elem = this.formEl[i];
                const errorLabel = elem.parentNode.querySelector('.invalid-feedback');
                if (errorLabel && elem.nodeName.toLowerCase() !== 'button') {
                    errorLabel.textContent = '';
                }
            };

            return true;
        }
    }

    submitHandler = (event) => {
        event.preventDefault();

        if (this.validate()) {
            this.props.submit();
        }

        this.setState({isValidated: true});
    }

    render() {
        const props = [...this.props];

        let classNames = [];
        if (props.className) {
            classNames = [...props.className];
            delete props.className;
        }

        if (this.state.isValidated) {
            classNames.push('.was-validated');
        }

        return (
            <form ref={form => this.formEl = form} onSubmit={this.submitHandler} {...props} className={classNames} noValidate>
                {this.props.children}
            </form>
        );
    }
}

Form.propTypes = {
    children: PropTypes.node,
    className: PropTypes.string,
    submit: PropTypes.func.isRequired
};

export default Form;

Let’s dig into it starting from the bottom ⬆️. So, we render a regular <form> that includes all the children passed to our component. It also gets a .was-validated class in case we have no errors. We can use this class for styling for example. We also hold a reference to our form element in our component. Thus we would be able to work with it with JavaScript methods. Also, we assign a submit handler function to the form with the onSubmit event.

When the form is submitted (typically with a submit button), we call the component method called validate(). It’s not hard to guess that this is the method where our component’s main functionality is hidden. So, if it returns true, the form is valid, and we are free to call the component’s submit method. Now, how does the validation work 🤔?

The Validate method

In HTML5, a form validity is checked with the checkValidation() method. It returns true if all the form elements qualify defined rules and false, if at least one validation rule fails. We’ll use this behavior in our component.

In case the form is valid, we will loop through its elements and remove the text of their corresponding error containers.

If the form is invalid, we need to show messages for each of the erred elements. If a form element is invalid, its validity.valid property would be false. In such case, we will fill the .invalid-feedback <span> with the corresponding error message. The error message provided by the API is accessible through the validationMessage property of an element. We will use that message as it is pretty much detailed and already localized with the browser locale. If you want to use your custom error messages, you should assign the errorLabel.textContent with your value instead of elem.validationMessage. As simple as that.

Note, that we skip an element if it is a button. This is because a form refers to all of its elements that a user can interact with, including buttons.

Now, all our invalid fields have error messages next to them and our form is not submitted until all errors are fixed 👍 The only thing left to do is styling! But I guess I’ll leave the funny part to you, as “I want to believe” (👽) in your creativity 😜

Thanks for reading this far, hope you had fun and learned something new here.

Here is a full working CodePen that I created as a playground 🎮 Enjoy, coders!

And one more thing…

Secure yourself from both sides

Remember, validating user input in client side is not enough. A smarty like you can always find a way to avoid the validation. That is why always do checks also in your backend. Believe me, you’ll thank yourself for that ☺️

DEV Community: Arpy Vanyan

Being a lead sometimes means you work all day, but no single line of code is committed. Does it mean nothing valuable was done? Well, no... Sometimes, the invisible work we do is much more valuable for the future than you'd think.

The Invisible Work of a Frontend Lead (And Why It Matters)

The Invisible Work of a Frontend Lead (And Why It Matters)

📌 TL;DR

You're not just leading code, you're leading clarity

Architecture isn't just diagrams, it's social

Mentorship hides in the gaps

Documentation is boring until it saves the day

You become a developer advocate inside your team

The process isn't sexy, but it scales

Defending focus is part of the job

Final thoughts: the best work doesn't always have a commit hash

React Performance: Small Fixes That Made a Big Impact

1️⃣ Measure Before You Optimize

2️⃣ Too Many Renders? Check Your State

3️⃣ useEffect Isn't Your Friend (Most of the Time)

4️⃣ Initial Load Times Matter More Than You Think

5️⃣ Lists Are a Performance Trap

6️⃣ Real Debug Example: The Mystery Re-Render

🧠 Final Thoughts

I've learned things the hard way so you don't have to 👩🏻‍💻

Things I Wish I Knew Before Scaling a Frontend Codebase 🚀

Arpy Vanyan ・ Mar 7

Things I Wish I Knew Before Scaling a Frontend Codebase 🚀

Introduction: The Growing Pains of a Frontend Codebase

1️⃣ Keep the Codebase Modular From Day One

2️⃣ Choose the Right State Management Approach Early

3️⃣ CI/CD & Automated Deployments Are Not an Afterthought

4️⃣ Performance Optimization Is Important

5️⃣ Proper Testing Saves You From Deployment Nightmares

6️⃣ Avoid Over-Engineering: Simple Is Better

7️⃣ Documentation Is a Lifesaver

8️⃣ TypeScript Will Save You From a Lot of Debugging

9️⃣ API Communication Should Be Standardized

🔟 Scaling a Frontend Isn’t Just About Code; It’s About Process

From Spaghetti to Scalable: How I Modularized a Growing Frontend Codebase

Introduction: The "Oh No" Moment

🎯 TL;DR

Phase 1: The Giant Monolithic App Era

Biggest Pain Points:

Lesson Learned:

Phase 2: Splitting the Monolith — The First Step to Modularization

The New Modular Structure:

What Changed?

Phase 3: The NPM Link Hell & How NX Saved the Day

The Solution: NX Monorepo

What Changed?

Next Steps: Refining the NX Architecture 🚀

Final Takeaways: Lessons I Learned the Hard Way 😅

Conclusion: Keep It Simple, Keep It Scalable 🚀

📌 Want to Learn More?

Things I Wish I Knew Before Scaling a Frontend Codebase 🚀

Arpy Vanyan ・ Mar 7

Iterators in JavaScript Explained with Coffeeshops

Wait… What?! 🤯

🎯 TL;DR

☕ Imagine a Coffee Queue

🧠 Here’s the key insight:

🤯 Wait… How?

🎯 Code Time! Let's See It in Action

🧠 What's Happening Here?

🖼️ Visualizing the Concept

🧠 So... Why Does This Matter?

🔍 Built-in Iterators That Follow This Rule

🤓 The Takeaway (with Coffee!) ☕

"An Iterator is Just an Iterable of Itself" means:

☕ Final Thought: Coffee and JavaScript are Both Better When Shared!

Building a Scalable Delivery Pipeline for Small Teams 🚀

Introduction

🎯 TL;DR

1️⃣ The Importance of Staging

Why Staging?

Golden Rule:

Deployment to Staging

2️⃣ Think of Your Product Like a Pizza 🍕

3️⃣ Managing Packages Efficiently

Staging Packages with Nightly Builds 🌙

4️⃣ Deployment Workflow: From Code to Production 🚀

The Server

3️⃣ `useEffect` Isn't Your Friend (Most of the Time)