DEV Community: Priya Pandey

JavaScript Isn’t Broken — Your Closure Placement Is

Priya Pandey — Thu, 11 Dec 2025 08:47:12 +0000

Now and then, JavaScript quietly teaches me something, sitting under the surface. Recently, that lesson came from a tiny custom iterator I was writing just out of curiosity.

I wasn't trying to solve anything deep.
But while experimenting, I bumped into a pattern that shows up in so many places:

Where you put your closure state determines whether your function/object becomes reusable or single-use.

It's a deeper concept that affects half the JavaScript patterns we write without even thinking.

Let me show you how I discovered it.

Example 1: A Custom range() Iterator — Not Wrong, Just Interesting

Here's the custom range() iterator I wrote:

function range(from, to) {
  let nextIndex = from;  // this state lives in the closure of range()

  return {
    next() {
      if (nextIndex <= to) {
        return { value: nextIndex++, done: false };
      }
      return { done: true };
    },
    [Symbol.iterator]() {
      return this;  // this object IS the iterator
    },
  };
}

Using it:

const r = range(1, 4);

for (let x of r) console.log(x);
// -> 1 2 3 4

for (let x of r) console.log(x);
// -> (nothing)

And here's the thing:

This is not a bug.
This is exactly how generator functions behave.

Generators are intentionally single-use.
Once their internal state moves forward, it stays moved.
My custom iterator behaves the same way.

So nothing is "wrong".

But this led me to a deeper realization:

The single-use behavior has nothing to do with iterators being tricky.

It's simply because:

The state (nextIndex) lives in the outer closure
And [Symbol.iterator] returns the same object every time

Which means the iterator cannot restart - the internal state never resets.

This is where the real pattern shows up.

If You Want a Reusable Iterable…

…you only need to change where the state lives:

function range(from, to) {
  return {
    [Symbol.iterator]() {
      let nextIndex = from;  // fresh state per iterator instance
      return {
        next() {
          if (nextIndex <= to) {
            return { value: nextIndex++, done: false };
          }
          return { done: true };
        },
      };
    },
  };
}

Now:

for (let x of r) console.log(x); // 1 2 3 4
for (let x of r) console.log(x); // 1 2 3 4   (restarts)

Fresh iterator -> fresh nextIndex -> reusable iterable.

And that's when I realized:

This isn't about iterators.
It's about closure state and how we structure our functions.

To test the theory, I tried something completely different - a pipe() function.

And it exposed the same pattern.

Example 2: A Pipe Function That Accidentally Became Single-Use

If you haven't used pipe() before:
It's a small functional helper that takes a list of functions and runs them in sequence:

pipe([f1, f2, f3])(value)

is basically:

f3(f2(f1(value)))

Here's the first version I wrote:

function pipe(funcs) {
  let i = 0; // state stored OUTSIDE merged()

  return function merged(...args) {
    if (funcs.length === 0) return args[0];

    const out = funcs[i](...args);

    if (i === funcs.length - 1) {
      return out;
    }

    i++;
    return merged(out);
  };
}

Usage:

const fn = pipe([x => x * 2, x => x + 3]);

console.log(fn(5));  // 13
console.log(fn(5));  // 8 (state leaked across calls)

And then I laughed because this is the same pattern as the iterator example:

'i' lives in the outer closure
The returned function shares that 'i' across invocations
Which means the whole pipeline is single-use

Exactly like the iterator.

Fixing It (Again) By Moving State Inside

function pipe(funcs) {
  return function merged(...args) {
    function helper(i, val) {
      if (i >= funcs.length) return val;
      return helper(i + 1, funcs[i](val));
    }
    return helper(0, ...args);  // fresh state per call
  };
}

Now:

fn(5); // 13
fn(5); // 13

The Actual Pattern

After seeing this in both examples, the pattern became very clear:

If your state lives in the outer closure, you create a single-use function/object.
If your state is created inside a nested function or factory, you get a reusable function/object.

This applies to:

iterators
generators
pipes
debounce/throttle
decorators
memoization
middleware
event callback wrappers

Basically, half of JavaScript.

What This Taught Me

I used to look at nested functions and think:

"Why do people put functions inside functions? Just flatten it!"

Now I understand why:

Nested functions give you fresh closure state
Fresh state gives you reusable behavior
Outer closure state gives you single-use behavior

What About You?

Have you ever written something that mysteriously worked only once?
Or something that behaved "weirdly" because of closure state placement?

I'd love to hear other examples - this pattern is everywhere once you learn to see it.

Memoization in JavaScript: How Not to Be Dumb About It

Priya Pandey — Sun, 23 Feb 2025 13:59:09 +0000

Have you ever met someone who asks the same question repeatedly even though they already got the answer? Yeah, don’t let your JavaScript functions be that person.

Memoization is a fancy saying: “Remember the answer so you don’t have to redo the work.” It’s one of those concepts that sounds simple but can go hilariously wrong if not done right.

In this article, we’ll explore:

How memoization works (without boring you to death).
The different ways to implement it (closures vs function properties).
The biggest mistakes people make (like using bad keys). By the end, you’ll have a bulletproof memoization function that doesn’t make dumb mistakes. Let’s go!

So, why do we even need memorization?

Let’s say you have a super slow function — something like this:

function slowSquare(n) {
    console.log(`Calculating square of ${n}... ⏳`);
    // Simulating a slow computation
    for (let i = 0; i < 1e9; i++) {}  
    return n * n;
}

console.log(slowSquare(5));  
console.log(slowSquare(5));

Memoization Without Closures? Meet Function Properties!

So, we know closures work great for memoization, but did you know you can store cache directly on the function itself? Yep, functions in JavaScript are objects, meaning they can hold properties like an object does.

function memoizedSquare(n) {
    if (!memoizedSquare.cache) {
        memoizedSquare.cache = {};  // Initialize cache on first run
    }

    if (memoizedSquare.cache[n]) {
        console.log("Memoized call!");
        return memoizedSquare.cache[n];
    }

    console.log("New call!");
    return (memoizedSquare.cache[n] = n * n);
}

console.log(memoizedSquare(4));  // New call!
console.log(memoizedSquare(4));  // Memoized call!

Why does this work?

Every function in JavaScript is an object, so we can store a cache inside it.
The cache is persistent across function calls, just like in closures.
Less memory overhead compared to returning a whole new function.

Why you should avoid this?

If you need to memoize multiple functions, they will each need their own cache property.
Function properties can be accidentally modified or deleted, leading to unpredictable behavior.
Another issue is this memory can’t be shared if you are extending the function if that is what you want. Let’s get deeper into that in next method.

Prototype Pollution: A Dangerous Mistake

Some developers might think, "Hey, let's store cache in the function prototype instead!" but this is a disaster waiting to happen.

function memoizedSquare(n) {
    if (!memoizedSquare.prototype.cache) {
        memoizedSquare.prototype.cache = {};  // Initialize cache on first run
    }

    if (memoizedSquare.prototype.cache[n]) {
        console.log("Memoized call!");
        return memoizedSquare.prototype.cache[n];
    }

    console.log("New call!");
    return (memoizedSquare.prototype.cache[n] = n * n);
}

console.log(memoizedSquare(5));  // New call!
console.log(memoizedSquare(5));  // Memoized call!

Why is this very very bad?

Pollutes all instances of the function — every function that uses the prototype will share the same cache by that I mean the functions that extend the above function will have access to the cache.
Can be accidentally modified or overwritten by other parts of the code or even other functions extending them.
Prototype pollution exploits exist, where malicious code can hijack properties stored in the prototype.

Moral of the story? Never store caches in the prototype! Use function properties only when necessary and be mindful of scope.

Now that we’ve covered this unusual method, let’s move on to the classic closures approach in the next section!

The Classic Approach: Closures for Memoization

If you’ve worked with memoization before, this is probably the method you’ve seen. Closures allow us to keep a cache inside a function without polluting the global scope or modifying function properties.

function square(val){
  return val*val;
}
function memoizedFn(fn) {
    let cache = new Map();  // using Map DS as its faster

    return function(arg) {
        if (cache.has(arg)) {
            console.log("Memoized call!");
            return cache.get(arg);
        }

        console.log("New call!");
        const value = fn(arg);
        return cache.set(arg,value);
        return value;
    };
}

const betterSquare = memoizedFn(square);

console.log(betterSquare(5));  // New call!
console.log(betterSquare(5));  // Memoized call!

Why Is This The Standard Approach?

No global variables — cache is fully enclosed inside the function.
Safe from modification — unlike function properties, this cache isn’t exposed.
Ideal for multiple instances — you can create multiple memoized functions without interference.

Downsides of Closures

Function Wrapping Required — you must return a new function every time.
Memory Growth — The cache can grow indefinitely if not handled properly. Cache eviction strategies help tackle this, but let’s keep that discussion for another day—I'm yet to explore that myself! 😂

Bonus: Handling Key Generation

So far, we’ve only used numbers as keys, but what if the function takes other values like strings boolean?

function memoizedFn(fn) {
    let cache = new Map(); 

    return function(arg) {
        if (cache.has(arg)) {
            console.log("Memoized call!");
            return cache.get(arg);
        }

        console.log("New call!");
        const value = fn(arg);
        return cache.set(arg,value);
        return value;
    };
}

const betterFn = memoizedFn(fn);
console.log(betterFn(1));  // New call!
console.log(betterFn('1'));  // Memoized call!

Oh no! Those are two different values. You might have heard that before using a value as a key they converted it into strings. That’s exactly what happened here.

What is the solution? One of the solutions here is to generate key with the typeof that value. Something like this:

function generateKey(key){
  return key+`${typeof key}`;
}

In the above case, our keys would look something like this:

cache = {
  '1number': "something",
  '1string': "something",
}

Hold it isn’t over. What if we have multiple arguments? We still have our protector rest operator and we will be using the apply method to give our function its context and our arguments.

function sum(a,b,c){
  return a+b+c;
}
function generateKey(key){
  const cacheKey=key.map(k=> (k+`${typeof k}`));
  return cacheKey.join("_");
}
function memoizedFn(fn) {
    let cache = new Map(); 

    return function(...arg) {
        const key=generateKey(arg);
        if (cache.has(key)) {
            console.log("Memoized call!");
            return cache.get(key);
        }

        console.log("New call!");
        const value = fn.apply(this, arg);
        cache.set(key,value);
        return value;
    };
}

const betterSum = memoizedFn(sum);
console.log(betterSum(1,3,5));  // New call!
console.log(betterSum(1,3,5));  // Memoized call!

Memoization is a powerful technique that boosts performance by caching previously computed results. But the way you implement it depends on your use case!

The above memoization function can be very complex and can be modified to cover various use cases and edge cases. I have provided a basic generalized function to help you guys learn the concept. You can extend to generate your versions of memoized function and yes do share with me so that I can learn with you.

Debouncing vs. Throttling: Don't Let Your Code Misbehave! 🍕🚀

Priya Pandey — Mon, 10 Feb 2025 20:57:43 +0000

Have you ever clicked a button multiple times and suddenly realized your app glitched or made too many API calls? Maybe you've typed in a search bar, and it kept sending requests after every letter?

That’s when debouncing and throttling come to the rescue! 🚀

These two JavaScript techniques control how frequently your function executes, making your app faster, smoother, and bug-free. Today, we’ll break them down in a fun, pizza-themed way—because who doesn’t love pizza? 🍕🔥

🍕 Debouncing: "Ek Baar Bolna, Baar Baar Nahi!" (Say it once, not again and again!)

Imagine you're at a pizza restaurant, and you have a habit of changing your order every second:

"Ek Margherita dedo!"(Give me one Margherita!)
"Nahi nahi, ek Pepperoni dedo!" (No no, give me one Pepperoni!)
"Wait, ek Farmhouse dedo!"(Wait, give me one Farmhouse!)
"Arey, nahi! Cheesy Burst chahiye!"(Oh no! I want Cheesy Burst!)

What happens? 🤦‍♂️
The waiter gets confused and doesn't place the order until you're finally done deciding. He waits for you to stop changing your mind before sending the order to the kitchen.

This is Debouncing. 💡

function debounce(orderFunction, delay) {
  let timer;
  return function () {
    clearTimeout(timer);
    timer = setTimeout(orderFunction, delay); // Execute after delay
  };
}
function acceptOrder() {
  console.log("Pizza order accepted! 🍕");
}

const orderButton = document.getElementById("orderButton");
orderButton.addEventListener("click", debounce(acceptOrder, 3000));

Don't ask how timer is still available for our order. Please have a proper closure with THE CLOSURE from the one and only Akshay Saini

📝 What Happens?

If you click multiple times within 3 seconds, the function won’t execute.
It only executes after you stop clicking for 3 seconds.
✅ Perfect for search bars, form submissions, or anything that shouldn’t trigger too frequently!

⏳ Throttling: "Limit Cross Mat Karo Bhai!"(Don't Cross the Limit, Bro!)

Now imagine another scenario:

You’re super hungry and start shouting at the waiter every second:

"Bhai, pizza lao!"(Bro, bring the pizza!)
"Bhai, pizza lao!"(Bro, bring the pizza!)
"Bhai, pizza lao!"(Bro, bring the pizza!)

The waiter finally loses patience and tells you:
👉 "Aap jitni baar bhi bolo, main sirf har 5 second me ek baar order loonga!"(No matter how many times you ask, I'll only take one order every 5 seconds!)

This is Throttling—even if you keep spamming the button, the function will only execute once in a fixed time interval.

function throttle(orderFunction, duration) {
  let lastExecutionTime = 0;
  return function () {
    const currentTime = Date.now();
    if (currentTime - lastExecutionTime >= duration) {
      orderFunction();
      lastExecutionTime = currentTime;
    }
  };
}
function acceptOrder() {
  console.log("Pizza order placed! 🍕");
}

const orderButton = document.getElementById("orderButton");
orderButton.addEventListener("click", throttle(acceptOrder, 5000));

📝 What Happens?

If you click 10 times within 5 seconds, the function runs only ONCE.
After 5 seconds, the function runs again if clicked.
✅ Perfect for API rate limiting, scrolling, or any function that should execute at fixed intervals!

For our readers who want more like our pizza customers.

👉 That’s what our basic debounce function did. But now, introducing Debounce 2.0 – The Advanced Edition! 🚀

function debounce(func, delay) {
  let timer;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => func.apply(this, args), delay);
  };
}

😒Don't fuss I have Throttle SUPERCHARGED Version as well.

function throttle(func, limit) {
  let lastCall = 0;
  return function (...args) {
    const now = Date.now();
    if (now - lastCall >= limit) {
      func.apply(this, args);
      lastCall = now;
    }
  };
}

Try it out and save your CPU from unnecessary drama.😮‍💨

The Talk Show: Where Speech Meets Spectacle

Priya Pandey — Sun, 24 Nov 2024 17:36:47 +0000

This is a submission for the AssemblyAI Challenge : Sophisticated Speech-to-Text.

What I Built

I built a Conversation Visualizer- a fun and interactive way to bring conversations to life!

This project animates real-time dialogues by transforming speakers into expressive avatars that react to the conversation visually. Each avatar represents a participant, showcasing their emotions and activity dynamically. Whether it’s a heated debate, a casual chat, or a storytelling session, this tool captures and visualizes the essence of the conversation in an engaging and visually appealing way.

Demo

Website Demo
You can try with these sample audios.
Audio Sample 1
Audio Sample 2
Audio Sample 3

Backend Code
Frontend Code
Video Demo

Journey

Universal-2, AssemblyAI’s Speech-to-Text model, was instrumental in building my Conversation Visualizer. It provided speaker identification and insightful summaries to enrich the experience.

How I Used AssemblyAI:

1. Speaker Diarization: This feature identified individual speakers, segmenting the audio into distinct utterances. These utterances were then mapped to animated avatars, creating an engaging and real-time dialogue visualization.
2. Summarization: I utilized the "catchy" summary model with the headline type to generate a concise and captivating conversation overview. This summary acts as a quick takeaway for viewers, encapsulating the essence of the dialogue in a single, impactful headline.
3. Seamless Integration: By combining diarization with summarization, I provided users not only with a dynamic, visual representation of conversations but also a high-level overview for quick context, making the tool versatile for various use cases like podcasts, meetings, or storytelling.

The combination of AssemblyAI's diarization and summarization made it possible to turn ordinary audio conversations into visually compelling and insightful narratives, enhancing functionality and creativity.

Navigating the Directed Maze: Finding the Minimum Spanning Tree

Priya Pandey — Tue, 05 Nov 2024 08:45:46 +0000

When we think of graphs, we often picture the vast and intricate networks connecting cities, data points, or even social interactions. But what happens when we add direction to our edges? Enter directed graphs, where the edges have a one-way street feel.

The Dilemma: Can We Have an MST in Directed Graphs?

(I know, I know we already have famous algorithms for the same but let's not go that way and explore other options too😁)

The traditional MST focuses on undirected graphs, ensuring that every node is reachable from every other node. However, in directed graphs, we face a fork in the road. Directed graphs can be categorized into two types:

Strongly Connected Graphs: Here, every node can reach every other node. No problem—finding an MST is straightforward!
Weakly Connected Graphs: In this scenario, while the graph is connected when we ignore direction, not all nodes can reach each other directly. This raises a question: How do we find an MST when we have multiple starting points?

In weakly connected graphs, we must begin our journey from a root node that can reach all other nodes. But wait—there might be several potential roots that satisfy this condition! Our goal is to determine the minimum weight spanning tree, so we need a strategy to compare these roots and pick the one that gives us the least weight.

My solution works for strongly connected ones but for weakly connected ones we have to modify this solution.

#include <iostream>
#include <bits/stdc++.h>
using namespace std;

int spanningTreeForDirectedGraphs(int V, vector<vector<int>> adj, int e) {
    vector<int> weight(V, INT_MAX);
    vector<vector<int>> mat(V, vector<int>(V, -1));

    // Construct the adjacency matrix
    for (int i = 0; i < e; i++) {
        mat[adj[i][0]][adj[i][1]] = adj[i][2];
    }

    priority_queue<pair<int, int>, vector<pair<int, int>>, greater<pair<int, int>>> q;
    // Assuming source node 0 if not given
    q.push({0, 0});
    weight[0] = 0;
    int ans = 0;

    while (!q.empty()) {
        int node = q.top().second;
        int dis = q.top().first;
        q.pop();

        for (int i = 0; i < V; i++) {
            int wei = mat[node][i];
            if (weight[i] > wei && wei != -1) {
                q.push({wei, i});
                if (weight[i] != INT_MAX) {
                    ans -= weight[i];
                }
                weight[i] = wei;
                ans += wei;
            }
        }
    }
    return ans;
}

int main() {
    int v, e;
    cin >> v >> e;
    vector<vector<int>> adj(e);

    for (int i = 0; i < e; i++) {
        int u, v, wt;
        cin >> u >> v >> wt;
        adj[i].push_back(u);
        adj[i].push_back(v);
        adj[i].push_back(wt);
    }

    cout << spanningTreeForDirectedGraphs(v, adj, e);
    return 0;
}

Let’s Test Our Method with a Simple Case

Imagine a directed graph with 3 vertices and the following edges:

This represents a graph where:

An edge goes from node 0 to node 2 with a weight of 5.
An edge goes from node 2 to node 1 with a weight of 3.
An edge goes from node 1 back to node 0 with a weight of 1.

After running our algorithm, we see that by removing the edge (1,0), we create a spanning tree with a total weight of 8. Voilà! We have successfully navigated through the directed maze!

Here’s the challenge💪: Can we find an MST for weakly connected ones too? Feel free to modify my solution or come up with your own unique approach(remember new and unique is the trend🤌).

Minimum Spanning Trees Breaking the Norm

Priya Pandey — Fri, 25 Oct 2024 17:19:12 +0000

It is common for engineers to follow the trend, often overlooking the potential of re-creating solutions. I have a unique approach to a Minimum Spanning Tree (MST) problem using principles inspired by Dijkstra’s algorithm. By stepping away from conventional practices and exploring creative adaptations, we can unlock new pathways for innovation.

The core idea behind my approach is reminiscent of Dijkstra's algorithm. I maintain a check on all nodes in the graph to ensure that we select the edge that provides the minimum weight for each specific node. This strategy allows us to build the Minimum Spanning Tree (MST) incrementally by always considering the lightest edge connected to any node.

Here’s how it works:

1. Node Connection: At each step, I focus on adding a single edge that connects a new node to the growing MST. By selecting the edge with the minimum weight for that node, we effectively ensure that each addition contributes to minimizing the overall tree weight.
2. Edge Count: This process continues until we have added n−1 edges, where n is the total number of nodes in the graph. Since each node must connect to at least one other node(considering it doesn't have an unconnected component) to be included in the tree, we can be confident that all nodes will eventually be connected. As we select the lightest edge for each node, there will never be a scenario where a node is left unconnected; every node reaches another through some edge and we take the minimum one.
3. Limitations: It’s important to note that this approach does not handle negative cycles. Since we rely on the assumption of non-negative edge weights, any negative cycle could disrupt the tree structure and lead to incorrect results.

 int spanningTree(int V, vector<vector<int>> adj[])
    {
        vector<int> weight(V,INT_MAX);
        vector<vector<int>> mat(V,vector<int>(V,-1));
        for(int i=0;i<V;i++){
            for(auto it: adj[i]){
                mat[i][it[0]]=it[1];
            }
        }
        priority_queue<pair<int,int>,vector<pair<int,int>>,greater<pair<int,int>>> q;
        q.push({0,0});
        weight[0]=0;
        int ans=0;
        while(!q.empty()){
            int node=q.top().second;
            int dis=q.top().first;
            q.pop();
            for(int i=0;i<V;i++){
                int wei=mat[node][i];
                if(weight[i]>wei && wei!=-1){
                    q.push({wei,i});
                    if(weight[i]!=INT_MAX){
                        ans-=weight[i];
                    }
                    weight[i]=wei;
                    ans+=wei;
                    //this statement ensures that we don't add the bidirectional edge
                    mat[i][node]=-1;
                }
            }
        }
        return ans;
    }

I welcome any thoughts on its correctness and potential edge cases that might challenge its validity. Let's discuss how we can further refine this solution and explore scenarios where it may or may not hold up. Your insights and critiques are invaluable in this journey of exploration!

Pinata Food Recipe Collaborator

Priya Pandey — Sun, 13 Oct 2024 19:44:20 +0000

This is a submission for the The Pinata Challenge

What I Built

Being a food lover, I have built a recipe-sharing website where users can upload their recipes, checkout other people recipes and rate them.

Features

Authentication: Users are required to authenticate themselves.
Upload Recipe: They can upload there recipes by a form.
Update and Delete recipe
Rate recipes

Demo

Link to the website

My Code

Frontend
Backend

More Details

I have used the pinata API for uploading the food image and video files.

Negative cycle with Dijskta(Possible but not optimal)

Priya Pandey — Thu, 10 Oct 2024 04:57:33 +0000

I decided to experiment with Dijkstra’s algorithm to solve a problem that may involve negative cycles. While Dijkstra’s algorithm isn't optimal for graphs with negative weights, I found that it can be adapted with some modifications.

Thought Process Behind Using Dijkstra's Algorithm for Negative Cycles:

The core issue with negative cycles is that they can lead to continuously decreasing distances, causing incorrect results. Normally, Dijkstra's algorithm works by updating the distance to a node when a shorter path is found, which happens within an 'if' block that compares the new distance to the previously calculated one. However, with a negative cycle, this comparison will keep returning true because the total distance keeps decreasing as we go around the cycle.

To handle this, my approach stores the paths for each node. The next time we visit a node, we check whether the node itself is already part of the path leading to it. If the node is found in its own path, it indicates a cycle. This means we are revisiting the node through a cycle that potentially decreases the distance, leading us into the if block where we detect the negative cycle. On the other hand, if we find a shorter path that doesn’t form a cycle, the node's distance is updated as usual.

Here’s my code implementation, which adapts Dijkstra’s algorithm while incorporating path tracking:

vector<int> bellman_ford(int V, vector<vector<int>>& edges, int S) {
    vector<vector<pair<int,int>>> adj(V);
    for(int i=0;i<edges.size();i++){
        adj[edges[i][0]].push_back({edges[i][1],edges[i][2]});
    }
    vector<int> dist(V,1e8);
    dist[S] = 0;
    vector<vector<int>> path(V);
    path[S] = {S};
    queue<pair<int,int>> q;
    q.push({S,0});

    while(!q.empty()) {
        int node = q.front().first;
        int dis = q.front().second;
        q.pop();

        for(auto it: adj[node]) {
            if(dis + it.second < dist[it.first]) {
                vector<int> temp = path[node];

                // Check if the node is already in its path (cycle detection)
                if(find(temp.begin(), temp.end(), it.first) != temp.end()) {
                    return {-1}; // Negative cycle detected
                }

                temp.push_back(it.first);
                path[it.first] = temp;
                q.push({it.first, dis + it.second});
                dist[it.first] = dis + it.second; // Update distance
            }
        }
    }
    return dist;
}

This approach ensures that the block is entered only when a reducing distance is detected, either due to a linear path or a negative cycle. If a cycle is found in the path, the function returns -1 to indicate the presence of a negative cycle. Otherwise, it updates the distance accordingly.

Let me know your thoughts on this.

Frontend Challenge v24.09.04-Space Edition

Priya Pandey — Sun, 15 Sep 2024 15:11:22 +0000

This is a submission for Frontend Challenge v24.09.04, Glam Up My Markup: Space

What I Built

I have built the solar system using three js and it's my first time using the tool. My idea was to represent those bits pieces of space on a 3D plane.

Demo

GitHub code link

Journey

I always wanted to do something one day with three js. I have heard about this a lot from YouTubers and other forums. Never really got a chance to build something so tried the challenge using the same. I wish to elaborate this to make a portfolio of my life integrating the idea of the space couldn't do this here because had to use the markup given in the challenge.

Frontend Dev Challenge

Priya Pandey — Sun, 04 Aug 2024 17:14:07 +0000

This is a submission for Frontend Challenge v24.07.24, CSS Art: Recreation.

Inspiration

I like to binge-watch things when I have the time to do so. This recreation showcases my Netflix journey. What could be more relaxing than watching your favorite show with your favorite snacks?

Demo

GitHub Code Link :- Code

Journey

I usually don't have time as I am a working professional. But I clearly enjoy watching K-Dramas, C-Dramas, Thai Dramas, and many more. Apart from these I also enjoy creating quirky things with CSS. I had no idea we could build literally everything with CSS just like with pen and paper until I tried it myself. I enjoyed building my imagination thanks to the challenge.