projects - freeCodeCamp.org

How to Become an Analytical Programmer – Solve the "Rock, Paper, Scissors" Game 5 Ways Using JavaScript & Mermaid.js

evaristo.c — Mon, 12 May 2025 14:06:25 +0000

Over the past year, I’ve explored tools and practices that help developers build an analytical mindset. One recurring theme is how experienced programmers often describe understanding code as forming a mental picture – a conceptual map of the program’s flow.

When it comes to software development, finding ways to visualize these mental models is a common thread. Many developers describe sketching workflows or imagining them mentally to reason through code. And in my own experience working with senior developers and software architects, this visualization habit is extremely common.

A 2013 Quora post captures this well:

“A top coder sees a program graphically (…) A data structure as a hierarchy of relationships, a program as a network of data pipes… The first and only time he reduces pictures to words is when he writes code.” —Rober Wagner

So it appears that developing our ability to recognize patterns in code could help us to develop our expertise. But programming is rarely that straightforward – there are often multiple ways to solve the same problem. It also reflects a developer’s personal habits, experiences, and styles. So which patterns matter, then?

Imagine you assign the same task to five developers: build a small game using HTML, CSS, and JavaScript. Each solution should follow the same functional rules. What are the chances their code will look the same?

You’d expect that their implementations might differ, but the underlying mental workflow – the internal logic they follow – might be remarkably similar. If you can reconstruct this mental flow from each codebase, you can create a shared referential point for comparison. Once this conceptual diagram is in place, you can “overlay” it on each codebase to identify where they diverge in structure, logic, or abstraction.

Ever since I started coding, spotting “patterns” while comparing other people’s code has fascinated me. I’ve found the process of comparing code not only educational but also enjoyable.

Up until now, I’ve approached it mostly by intuition – but I’ve always felt the need for a more structured method. This article explores a more systematic approach to code comparison, reflecting on what works well and what can be improved.

How to Read this Article

This article is intentionally extensive. Instead of just showing the end result, I’ll walk you through the methodology so you can recreate or adapt it for your own code comparisons.

That said, there are different ways you might approach this article, depending on your interests:

Just curious about the idea? The core argument is already laid out in the introduction. Maybe read the conclusion too, and that might be enough for your needs.
Looking to improve your portfolio? Skim through the analyses. If you're working on a game project, you’ll find comparisons of five JavaScript implementations of Rock, Paper, Scissors. These may give you practical ideas for your own code.
Interested in code analysis? Read the whole thing. This article goes deeper into why analyzing code is valuable and presents a practical methodology – including tools – you can apply.

Here’s what we’ll cover:

Visual Tools for Code Comparison: In this part, we’ll talk about diagrams and focus on the one we’ll use for this project – the use case-driven system block diagram.
What we are going to do: here, we reveal the focus of our analysis, what we expect to do, what we will consider when making the diagrams, and a short intro to the tool we will use for this, Mermaid.js.
Five Code Examples of Rock, Paper, Scissors: Next, we’ll assess the JavaScript code of five CodePen projects, starting from the simplest one and finishing with the most complex one. At each assessment, we’ll make a comparison against the preceding projects.
Final Thoughts

Now, let’s dive in!

Visual Tools for Code Comparison

There are many tools and approaches for code analysis, and although there are more and more “automatic” ways of doing it, flow diagrams are still incredibly useful. Unfortunately, while they’re widely used in programming education and analysis, their use for comparing different implementations is rarely discussed or illustrated in tutorials.

Still, the potential is clear. Flow diagrams capture structure and logic in a compact, readable form. They're heavily used in compiler design for analyzing control flow, optimizing logic, and identifying bugs.

When applied to comparative analysis, they can highlight differences in:

Modularity and abstraction
Execution flow
Separation of concerns or unnecessary complexity

But not all diagram types are equally effective for this purpose. Traditional flowcharts often dive too deep into the nitty-gritty, repeating low-level logic like if-else branches already visible in the source. While helpful for understanding a single script, they may obscure broader design patterns when comparing multiple implementations.

When comparing codebases, a better option is to focus on code structure: how functions, modules, and scopes relate and interact. For that, system block diagrams are a better fit.

Why Use System Block Diagrams?

System block diagrams visualize a program at a higher level. They use labeled blocks to represent major components (functions, classes, modules) and arrows to show how data or control flows between them. This lets you focus on architecture: which part does what, and how do they work together?

Used for code comparison, placing two system block diagrams side by side immediately highlights structural and design differences. You can see at a glance how one solution favors modularity, another embeds logic in fewer blocks, or which one better separates concerns.

Still, system block diagrams can be drawn in different ways – some emphasizing structure, others workflow. Is there a format that combines both?

The Use Case-Driven System Block Diagram

A strong candidate is the use case-driven system block diagram. An example of this variant is suggested as part of the resources for a computer science curriculum (“Advanced Object-Oriented Programming and Design” COMP310) of Rice University.

Unlike use case diagrams (which focus only on actors and goals), use case-driven system block diagrams are more implementation-focused. They still show modules and data flow, but through the lens of system functionality and user-driven logic.

Interestingly, the example above effectively exemplifies its usage for evaluating existing architectures. This confirms the suitability of this type of diagram for comparisons between codebases. Simply draw one diagram per implementation, striving to find their same functional goal. Then, compare their workflows and structures side by side. You’ll quickly spot which solution is more modular, more efficient, or easier to maintain.

What We Are Going to Do

To elaborate upon the suitability of this methodology for code analysis, we’ll apply the fundamentals of use case-driven system block diagram methodology to analyze five JavaScript projects’ code – each created by a different developer – implementing the Rock, Paper, Scissors game on CodePen.

The Rock, Paper, Scissors (RPS) game is a simple two-player challenge where each participant simultaneously shows either a “rock”, a “paper”, or “scissors” depicted by one of their hands, usually after a countdown. Then they apply the following rule to decide the “winner”:

Rock beats scissors
Scissors beats paper
Paper beats rock

If both players choose the same option, it’s a tie.

In most programming versions, the player faces off against the computer, which makes random (or pseudo-random) choices. It’s a favorite beginner’s project because it’s easy to understand and fun to build.

The Code Examples

We are going to compare the (vanilla) JavaScript code for the following 5 projects, ordered by complexity:

“CPC Rock Paper Scissors” by Amit (@ghaste in CodePen)
“Rock Paper Scissor game using native drag & drop” by Hmz C (@HmZ2 in CodePen)
“Rock Paper Scissors“ by Brad Traversy (@bradtraversy in CodePen)
“Rock Paper Scissors OOP“ by Damian (@CvtS in CodePen)
“Recurrent Neural Network - Rock, Paper, Scissors“ by Andrew Worscerter (@amwmedia in CodePen)

In order to keep the article shorter, the full code won’t be provided here, except for some exceptional cases. You are encouraged to visit the corresponding projects in CodePen to have a look at the code alongside the analysis. Because the authors can update or even delete the code in CodePen at any time, I’ll also add links to Gists with the code I analyzed at the time I wrote the article.

Follow this link: https://gist.github.com/evaristoc/81dc9f508aa54c355f3f89b08a2450d5 if you want to find the copy of the JavaScript codes used for this article.

How to Choose Your Projects

To find the projects, I searched CodePen for any pen about “Rock Paper Scissors”. Then I checked out the edits of some of them, and chose the ones I found the most interesting. I made a point to choose ones with varying complexities.

The Scope

First of all, our goal here isn’t to judge the quality of the codebases. Instead, it’s to demonstrate how we can use this diagram-based methodology to compare them.

CodePen projects often include quick demos, experiments, or even AI-generated snippets. Some developers might be more interested in the HTML/CSS of the project. But while they don’t always follow best practices, that’s what makes this exercise interesting – the diversity of approaches reveals valuable contrasts worth analyzing.

The Methodology

For the comparison, we’re using a methodology inspired by Rice University’s COMP310 course, which suggests the following high-level steps for constructing use case-driven system block diagrams:

Add all system use cases to a single diagram. These use cases will be similar to “steps in a workflow”.
Group related cases within conceptually – or functionally – related operations.
Encapsulate groups into modules (or blocks) based on roles and responsibilities. Start drawing the relationships (note: what we should understand for encapsulation here shouldn’t be confused with other definitions like the one given in OOP).
Decouple operations as much as possible – refine scope and minimize interconnections.

In order to allow the comparison between code examples, we will try to find cases (or steps), modules, and relations that are consistently similar between each code example, independently of the “architecture”.

Although UML compliance is encouraged in the original course, we’ll take a lighter approach – preserving the intent and structure without strictly following every UML rule.

How We’ll Build the Diagrams

The Rice course focuses more on what the diagram should show, but not so much on how to actually build it. For that, I refer to a previous article where I broke down the diagram creation process. Here’s how the two approaches align:

Step (from earlier article)	Corresponds to (Rice methodology)
Define a scope	Identify the goal and context for your diagram
Find the start and end of the workflow	Identify use cases (actually, a general scanning of the workflow)
Identify deep-dive vs. generalized sections	Identify groups of cases. Prepare for modular encapsulation
Iterative refining and generalization	Applied throughout to improve module clarity and decoupling
Enhance and extend	Equivalent to fine-tuning and breaking dependencies

Feel free to revisit that article if you want a more detailed walkthrough of these steps.

Our Tool: Mermaid.js

To create the diagrams, we’ll use Mermaid.js, a JavaScript library that converts text into diagrams. It’s Markdown-compatible, which makes it especially handy for online projects, blog posts, and documentation.

The main reason I chose Mermaid.js is that diagrams are easily editable, so we can:

Focus on defining relationships instead of worrying about layout
Easily iterate and update as we discover more structure in the code
Allows code reusability

Mermaid.js is also highly configurable, allowing a certain level of customization. It was also made for the web, so it’s compatible with JavaScript, CSS and Markdown. But it’s not a perfect tool, and its use poses challenges both because of the limitations of the tool itself and even because of the limitations of using visual diagrams for code analysis.

If you aren’t familiar with using Mermaid.js, I wrote an extensive tutorial about the tool, along with its pros and cons. Although I will refrain from talking in-depth about Mermaid.js here, I will make use of some other tricks that were not included in previous articles.

Be aware that to keep consistency in sizing and titling all resulting diagrams were subjected to post-treatment, which also included color filtering to improve contrast.

Five Code Examples of Rock, Paper, Scissors

1. “CPC Rock Paper Scissors” by Amit: A project with fireworks animations

Amit is a prolific CodePen user who has been uploading about 2-3 projects per week since as early as 2021. Their most recent projects (year 2025) have increased in complexity and quality while maintaining the high productivity rate.

But in Sept 2024, Amit made a simple (JavaScript) version of the Rock, Paper, Scissors game. This code is a lightweight, user-friendly implementation with fun visual elements like result display, animations, and visual feedback for wins and losses.

Key features of this project are:

It provides a complete Rock, Paper, Scissors game with a visual spinning effect when the computer is selecting its choice.
The game has animated fireworks to celebrate wins and changes the background color to red for losses.
The game keeps the interface interactive and fun through the use of emoji, quick animations, and visual feedback for the player’s performance.

Analysis of the Project

Quickly discovering of the start and end of the workflow

The code of this pen runs immediately once it’s called. Several variables are initialized (the animationContainer, the choices, the emojiMap, and so on).

Amit also made three separate functions for each item (that is, “rock”, “paper” and “scissors”). Each of them will be added as a click event to the interface (the HTML) and they all run the same function after clicking (playGame) each with a different argument based on what the user clicked.

After the interface is cleared, some variables are initialized, and the click event is added to the different emoji. The interface will wait for click interactions from the user, which will trigger the playGame function.

Let’s make a quick diagram showing this high level of generalization:

---
title: “CPC Rock Paper Scissors” by Amit - Simple SB-Diagram
config:
    theme: dark
    layout: "elk"
    flowchart:
        nodeSpacing: 50
        rankSpacing: 50
---
flowchart TD
subgraph _
subgraph main
init
subgraph clickEventListener[Click Event]
    eventHandler@{shape: fr-rect, label: "event handler\n(*playGame*)"}
end
end
init --> |"(1) initialize values
clean interface
add event listeners (event handler:**playGame**)"|interface
clickEventListener --> stop@{shape: framed-circle}
start@{shape: start} --> init@{shape: hex, label: "Initial Settings"}
choices --> |"(2) user choice: either paper, rock or scissors"| clickEventListener
clickEventListener --> |"(3) animations, results"| interface
end
style start fill:black
style stop fill:black, fill-stroke:white

The `playGame` Event Handler

Let’s take a closer look at the playGame function:

  function playGame(playerChoice) {
    const computerChoice = choices[Math.floor(Math.random() * choices.length)];
    const animationDiv = document.getElementById("animation");
    const resultDiv = document.getElementById("result");

    clearInterval(animationInterval);
    let currentIndex = 0;

    animationInterval = setInterval(() => {
      animationDiv.textContent = emojiMap[choices[currentIndex]];
      currentIndex = (currentIndex + 1) % choices.length;
    }, 100);

    setTimeout(() => {
      clearInterval(animationInterval);
      animationDiv.textContent = emojiMap[computerChoice];
      displayResult(playerChoice, computerChoice);
    }, 1500);
  }

It seems that there is a lot going on only in this function that could be assumed as separated functionalities. Although not explicit, there are different sections in it:

one dedicated to calculating the computer’s choice
then a setInterval to handle an animation
then a setTimeout to clear the previous animation and run the displayResult function

The first functionality operation that’s easy to identify within the whole code, and that could be set apart, is the one in charge of displaying the results: the displayResult func.

But we need to clarify the relationships in our diagram. The displayResult function is not coming after the event handler but is called from the event handler itself. We could argue that the event handler uses the displayResult function. Let’s clarify these definitions on the diagram, and also add a legend:

---
title: “CPC Rock Paper Scissors” by Amit - SB Diagram Refinement 01
config:
    theme: dark
    layout: "elk"
    flowchart:
        nodeSpacing: 50
        rankSpacing: 50
---
flowchart TD
subgraph _
subgraph main
init
subgraph clickEventListener[Click Event]
    eventHandler@{shape: fr-rect, label: "event handler\n(*playGame*)"}
end
displayFunc@{shape: fr-rect, label: "display func\n(*displayResult*)"} -.-o eventHandler
end
init -.-o |"(1) initialize values
clean interface
add event listeners (event handler:**playGame**)"|interface@{shape: curv-trap, label: "interface display"}
clickEventListener --> stop@{shape: framed-circle}
start@{shape: start} --> init@{shape: hex, label: "Initial Settings"}
choices@{shape: rounded} --> |"(2) user choice: either paper, rock or scissors"| clickEventListener
clickEventListener --> |"(3) animations, results"| interface

subgraph legend
      direction LR
      start1[ ] -->|"next step"| stop1[ ]
      style start1 height:0px;
      style stop1 height:0px;
      start2[ ] -.-o|"assignation"| stop2[ ]
      style start2 height:0px;
      style stop2 height:0px; 
end

end

interface ~~~ legend

style start fill:black
style stop fill:black, fill-stroke:white

Similarly, the displayResult function uses two functions dedicated to the animations: triggerFireworks and triggerLossBackground. All the functions are declared on the main scope.

---
title: “CPC Rock Paper Scissors” by Amit - SB Diagram Refinement 02
config:
    theme: dark
    layout: "elk"
    flowchart:
        nodeSpacing: 50
        rankSpacing: 50
---
flowchart TD
subgraph _
subgraph main
data@{shape: lean-r, label: "constants"} --> eventHandler
init
subgraph clickEventListener[Click Event]
    eventHandler@{shape: fr-rect, label: "playGame
event handler"}
end
    displayFunc@{shape: fr-rect, label: "displayResult
display func"} -.-o |"(3) the event handler calls the display function"| eventHandler
    display01@{shape: fr-rect, label: "triggerFireworks
animation"} -.-o displayFunc
    display02@{shape: fr-rect, label: "triggerLossBackground
animation"} -.-o displayFunc
end
init -.-o |"(1) initialize values
clean interface
add event listeners (event handler:playGame)"|interface@{shape: curv-trap, label: "interface display"}
clickEventListener --> stop@{shape: framed-circle}
start@{shape: start} --> init@{shape: hex, label: "Initial Settings"}
choices@{shape: rounded} --> |"(2) user choice: either paper, rock or scissors"| clickEventListener
eventHandler --> |"(4) animations, results"| interface

subgraph legend
      direction LR
      subgraph flowlines
        start1[ ] -->|"next step"| stop1[ ]
        style start1 height:0px;
        style stop1 height:0px;
        start2[ ] -.-o|"assignation"| stop2[ ]
        style start2 height:0px;
        style stop2 height:0px;
      end
      subgraph shapes
      variable["variable"]
      style variable width:135px, fill:none, stroke:none, color:#f1ce32
      subprocess[subprocess]
      end
end
end
interface ~~~ legend

style start fill:black
style stop fill:black, fill-stroke:white

Imperative Programming

This code is very much imperative. Here’s a definition of imperative programming from Wikipedia:

Imperative programming focuses on describing how a program operates step by step (generally order of the steps being determined in source code by the placement of statements one below the other), rather than on high-level descriptions of its expected results

Finding that the project follows an imperative paradigm is helpful as it provides some general idea of what we can expect in terms of how the code is organized and the type of logic we might use. We can expect that the computation logic will follow a certain workflow.

Finalizing the diagram

Now that we have uncovered the most explicit modules and their relationships, we can work on identifying sections of the code that might be considered separated functional/operational units. These separate units can be defined as “use cases” and will become the steps of the workflow.

As a way of enhancing the diagram, I have differentiated between steps and process blocks to prevent confusion between “modules” and “cases”.

---
title: “CPC Rock Paper Scissors” by Amit - Final SB Diagram
config:
    theme: dark
    layout: "elk"
    flowchart:
        nodeSpacing: 50
        rankSpacing: 50
---
flowchart TD
subgraph _
choices ~~~ stop
subgraph main
init
data@{shape: lean-r, label: "constants"} --> eventHandler
subgraph clickEventListener[Click Event]
    subgraph eventHandler["playGame
event handler"]
       subgraph step03[step03 - result handling and presentation]
        delay01
        delay02
        delay01 ~~~ nonode01[ ]
        style nonode01 fill:none,stroke:none;
       end
       step01@{label: "step01 - compute computer choice"} --> step02@{label: "step02 - prepare display"}
       step02 --> delay01@{shape: delay, label: setInterval}
       delay01 --> delay02@{shape: delay, label: setTimeout}
    end
end
    subgraph displayFunc["displayResult
display func"]
       step04@{label: "step01 - compute winner"} --> step05@{label: "step02 - show results"}
    end
    displayFunc -.-o |"(3) the event handler calls the display function"| delay02
    display01@{shape: fr-rect, label: "triggerFireworks
animation"} -.-o step05
    display02@{shape: fr-rect, label: "triggerLossBackground
animation"} -.-o step05
end
init -.-o |"(1) initialize values
clean interface
add event listeners (event handler:playGame)"|interface@{shape: curv-trap, label: "interface display"}
clickEventListener --> stop@{shape: framed-circle}
start@{shape: start} --> init@{shape: hex, label: "Initial Settings"}
choices@{shape: rounded} --> |"(2) user choice: either paper, rock or scissors"| clickEventListener
step05 --> |"(4) animations, results"| interface

subgraph legend
      direction LR
      subgraph flowlines
        start1[ ] -->|"next step"| stop1[ ]
        style start1 height:0px;
        style stop1 height:0px;
        start2[ ] -.-o|"assignation"| stop2[ ]
        style start2 height:0px;
        style stop2 height:0px;
      end
      subgraph shapes
      variable["variable"]
      style variable width:135px, fill:none, stroke:none, color:#f1ce32
      subprocess[subprocess]
      stepLegend["----step----"]
      style stepLegend fill:#474949, stroke: #CCC, color:#CCC
      end
end
end

interface ~~~ legend

style start fill:black
style stop fill:black, fill-stroke:white
classDef subProc fill:#1f2020, stroke: #CCC, color:#CCC
class eventHandler,displayFunc subProc
classDef step fill:#474949, stroke: #CCC, color:#CCC
class step01,step02,step03,step04,step05,step06 step

Let’s summarize what’s happening here:

In this project, a function acting as an event handler contains most of the project logic and it assumes full execution responsibility over some of the steps of the workflow.
Once the event handler is triggered, the choice of the user is passed to it and the same function calculates the choice of the computer.
That calculation is followed by part of the preparation of the interface, then an animation managed by an Interval – followed by a nested Timeout JavaScript method.
The Timeout method has the displayResult function as a callback function. This function will take the responsibility of the remaining steps.
It is inside the displayResult where the calculation of the winner takes place. The same function controls the rest of the display of results with different displays delegated to two other functions based on who wins the game.

2. “Rock paper scissors game using native drag & drop” by Hmz C: A project using the HTML Drag element

Hmz C has not been so active as Amit, with just 7 projects in CodePen across 10 years since 2014. The pen we are going to analyze is his very first contribution to CodePen. The project appears to be a demo of the HTML Drag and Drop API that came with HTML5 by the time of its release. The game provides a clean and interactive experience of "Rock, Paper, Scissors" using intuitive drag-and-drop gestures, visual effects, and live score updates. It focuses on user experience and interactivity.

Key features of this project are:

The drag and drop interaction, with simple but clean animations.
The scoring is central to this application. Both user and computer scores are updated and displayed in real-time.
The game provides a very clean, easy-to-understand interface without looking static.

Analysis of the Project

Quickly discovering of the start and end of the workflow

By inspecting the code, you will be able to realize that this code follows a similar general pattern as the code we previously examined:

Variables and states are initialized immediately when the project is accessed.
Similarly, an event handler is added to elements in the interface, but this time they won’t respond to click events but to drag and drop events.
That event handler is the one that starts and coordinates the workflow.
The workflow ends by showing results on the interface.

Given the similarities between this project and the previous at this level of analysis, I reused the script I created for the previous chart and modified it accordingly.

---
title: “Rock paper scissors game using native drag & drop” by Hmz C - Simple SB-Diagram
config:
    theme: dark
    layout: "elk"
    flowchart:
        nodeSpacing: 50
        rankSpacing: 50
---
flowchart TD
subgraph _
subgraph main
init
subgraph dropEventListener[Drop Event Listener]
    eventHandler@{shape: fr-rect, label: "anonymous func
event handler"}
end
end
init -.-o |"(1) initialize values and functions
clean interface
add event listeners (event handlers for: dragstart dragenter dragleave dragover drop)"|interface
dropEventListener --> stop@{shape: framed-circle}
start@{shape: start} --> init@{shape: hex, label: "Initial Settings"}
choices@{shape: rounded, label: dragged choice} --> |"(2) user drag a choice to an area: either paper, rock or scissors"| dropEventListener
dropEventListener --> |"(3) animations, results"| interface@{shape: curv-trap, label: "interface display"}

subgraph legend
      direction LR
      subgraph flowlines
        start1[ ] -->|"next step"| stop1[ ]
        style start1 height:0px;
        style stop1 height:0px;
        start2[ ] -.-o|"assignation"| stop2[ ]
        style start2 height:0px;
        style stop2 height:0px;
      end
      subgraph shapes
        variable["variable"]
        style variable width:135px, fill:none, stroke:none, color:#f1ce32
        subprocess[subprocess]
      end
end
end
interface ~~~ legend

style start fill:black
style stop fill:black, fill-stroke:white

IIFE

This project is the only one that uses an IIFE (Immediately Invoked Function Expression) pattern to register the drag and drop listeners. It is inside that IIFE (user) where the drop listener is also declared.

(function user() {

    for (var i = 0; i < hand.length; i++) {
        hand[i].ondragstart = dragStart;
    }

    function dragStart() {
        userChoice = this.getAttribute("data-hand");
    }

    userArea.addEventListener('dragenter', function(e) {
        e.preventDefault();
        this.style.borderColor = "red";
        user_icon.style.visibility = "hidden";
    });

    userArea.addEventListener('dragleave', function(e) {
        e.preventDefault();
        this.style.borderColor = "#dedede";
        user_icon.style.visibility = "initial";
    });

    userArea.addEventListener('dragover', function(e) {
        e.preventDefault();
    });

    userArea.addEventListener('drop', function(e) {
        e.preventDefault();
        computerChoice = cpu();
        user_icon.classList.remove("fa-spin");
        user_icon.className = "fa fa-hand-" + userChoice + "-o fa-2x fa-fw";
        computer_icon.className = "fa fa-hand-" + computerChoice + "-o fa-2x fa-fw";
        this.style.borderColor = "#dedede";
        user_icon.style.visibility = "initial";
        whowins(computerChoice, userChoice);
    });
})();

This project was completed before the release of ES6 in 2015. One of the uses of the pattern is to keep the variables and functions within the IIFE isolated from the global scope. Although the IIFE is still a valid syntax, in modern JavaScript most of the functional operations where the IIFE pattern is applicable can now be implemented with the use of special keywords, special operations, and standards.

Apart of the event handler, there are two other functions – the cpu function and the whowins function – that will take care of other aspects of the functionality. Those functions are declared in the global scope.

---
title: “Rock paper scissors game using native drag & drop” by Hmz C - SB-Diagram Refinement
config:
    theme: dark
    layout: "elk"
    flowchart:
        nodeSpacing: 50
        rankSpacing: 50
---
flowchart TD
subgraph _
subgraph main
init
subgraph dropEventListener[Drop Event Listener]
    eventHandler@{shape: fr-rect, label: "anonymous func
event handler"}
end
cpu@{shape: fr-rect, label: "cpu
computer choice calc"} -.-o eventHandler
whowins@{shape: fr-rect, label: "whowins
winner calc / update / display func"} -.-o eventHandler
changeColor@{shape: fr-rect, label: "changeColor
animation func"} -.-o whowins
end
init -.-o |"(1) initialize values and functions
clean interface
add event listeners (event handlers for: dragstart dragenter dragleave dragover drop)"|interface
dropEventListener --> stop@{shape: framed-circle}
start@{shape: start} --> init@{shape: hex, label: "Initial Settings"}
choices@{shape: rounded, label: dragged choice} --> |"(2) user drag a choice to an area: either paper, rock or scissors"| dropEventListener
dropEventListener --> |"(3) animations, results"| interface@{shape: curv-trap, label: "interface display"}

subgraph legend
      direction LR
      subgraph flowlines
        start1[ ] -->|"next step"| stop1[ ]
        style start1 height:0px;
        style stop1 height:0px;
        start2[ ] -.-o|"assignation"| stop2[ ]
        style start2 height:0px;
        style stop2 height:0px;
      end
      subgraph shapes
        variable["variable"]
        style variable width:135px, fill:none, stroke:none, color:#f1ce32
        subprocess[subprocess]
      end
end
end
interface ~~~ legend

style start fill:black
style stop fill:black, fill-stroke:white

Now that we have an overview of how the declared functions are related, let’s identify the functional operations they are taking care of and have a better idea of the full workflow.

Finalizing the diagram and comparison to previous project

After inspecting the code and making several iterations over the previous diagram, I came up with the following final result. Reusing parts of the script I made for the previous project helped me reduce the number of iterations.

---
title: “Rock paper scissors game using native drag & drop” by Hmz C - Final SB-Diagram
config:
    theme: dark
    layout: "elk"
    flowchart:
        nodeSpacing: 50
        rankSpacing: 50
---
flowchart TD
subgraph __
subgraph main
init
data@{shape: lean-r, label: "userScore computerScore variables"} -.-o whowins
step05 --> data
subgraph dropEventListener[Drop Event Listener]
    subgraph eventHandler["anonymous func
event handler"]
        step01@{label: "step01 - compute\ncomputer choice"} --> step02@{label: "step02 - prepare\ndisplay"}
        step02 --> step03@{label: "step03 - result handling\nand presentation"}
    end
end
cpu@{shape: fr-rect, label: "cpu
computer choice calc"} -.-o step01
subgraph whowins["whowins
winner calc / update / display func"]
    step04@{label: "step01 - calculate winner"} -->
    step05@{label: "step02 - update stored data"} -->
    step06@{label: "step03 - update interface"}
end
whowins -.-o step03
changeColor@{shape: fr-rect, label: "changeColor
animation func"} -.-o step06
end
init -.-o |"(1) initialize values and functions
clean interface
add event listeners (event handlers for: dragstart dragenter dragleave dragover drop)"|interface
dropEventListener --> stop@{shape: framed-circle}
start@{shape: start} --> init@{shape: hex, label: "Initial Settings"}
choices@{shape: rounded, label: dragged choice} --> |"(2) user drag a choice to an area: either paper, rock or scissors"| dropEventListener
step06 --> |"(3) animations, results"| interface@{shape: curv-trap, label: "interface display"}

subgraph legend
      direction LR
      subgraph flowlines
        start1[ ] -->|"next step"| stop1[ ]
        style start1 height:0px;
        style stop1 height:0px;
        start2[ ] -.-o|"assignation"| stop2[ ]
        style start2 height:0px;
        style stop2 height:0px;
      end
      subgraph shapes
      variable["variable"]
      style variable width:135px, fill:none, stroke:none, color:#f1ce32
      subprocess[subprocess]
      stepLegend["----step----"]
      style stepLegend fill:#474949, stroke: #CCC, color:#CCC
      end
end

interface ~~~ legend
end

style start fill:black
style stop fill:black, fill-stroke:white
classDef clTopr fill:#1f2020, stroke: #CCC, color:#CCC
class eventHandler,whowins clTopr
classDef step fill:#474949, stroke: #CCC, color:#CCC
class step01,step02,step03,step04,step05,step06 step

Notice the strong similarities between this project and the previous one:

The order of the steps
The imperative code structure
The event handler delegates the final steps to another function
That function (whowins) executes the calculation of the winner
That same function delegates the display of the results to a different function (changeColor)
There is a preference for using functions and variables declared in the global scope

What is different in this project is:

The event handler is declared as an anonymous callback function directly in the listener
This event handler delegates the execution of the calculation of choice of the computer to a different function, the cpu function.
There are no async functionalities in this project
Different from the previous project, this one has a slightly more advanced data handling. Data were stored in global variables (userScore, computerScore) that are updated just after the calculation of the winner.

If you started self-learning JavaScript at some point between 2015 and today (2025), you might have heard of this guy. Brad Traversy is a legend among those learning to code and has also made his own learning program.

The number of resources produced by Brad is immense. His first contribution to CodePen dates back to 2017. His activity in CodePen has declined with the time, but he has been posting valuable resources nonetheless.

In 2019 he made this Rock Paper Scissors game. This code delivers a straightforward but engaging implementation with a dynamic user interface. The integration of a randomized computer choice, score tracking, and modal result display creates an interactive and visually appealing experience for users.

Key features of this project are:

Randomized opponent choice: The computer's move is randomized each round to simulate an unpredictable opponent.
Dynamic modal display: A modal window shows round results for a polished, user-friendly experience.
Re-starting the game.
Score persistence across rounds: The scoreboard tracks scores until the game is manually reset, allowing for continuous gameplay.

Analysis of the Project

Quickly discovering of the start and end of the workflow

Inspecting this other code reveals a definitive pattern in the way the game is set. Similarly to the previous projects, in this one:

it initializes variables and states immediately after the project is accessed
it has event handlers added to the corresponding HTML elements in the interface
a function is usually associated to the event handler which is the one that coordinates the workflow – in this case the play function.
the workflow ends by showing results on the interface

Also, this project in particular involves a second event handler with a function to close a modal used to show the results. A third event handler is added to restart the game.

Again, given the similarities between this project and the previous ones at this level of analysis, I reused the script I created and modified it accordingly.

---
title: “Rock Paper Scissors” by B. Traversy - Simple SB-Diagram
config:
    theme: dark
    layout: "elk"
    flowchart:
        nodeSpacing: 50
        rankSpacing: 50
---
flowchart TD
subgraph _
subgraph main
init
subgraph clickEventListener[Click Event]
    eventHandler@{shape: fr-rect, label: "play
event handler"}
end
end
init --> |"(1) initialize values and functions
clean interface
add event listeners (event handlers:playGame clearModal restartGame)"|interface
clickEventListener --> stop@{shape: framed-circle}
start@{shape: start} --> init@{shape: hex, label: "Initial Settings"}
choices --> |"(2) user choice: either paper, rock or scissors"| clickEventListener
clickEventListener --> |"(3) animations, results"| interface
end
style start fill:black
style stop fill:black, fill-stroke:white

This project takes a step forward in designing an event handler, the play function. Its sole responsibility would be to delegate operations to other functions.

Three functions are called from this event handler:

getComputerChoice
getWinner
showWinner

Notice that again, all those functions are declared in the global scope – but this time, the play function is also in the same scope.

---
title: “Rock Paper Scissors” by B. Traversy - SB-Diagram Refinement
config:
    theme: dark
    layout: "elk"
    flowchart:
        nodeSpacing: 50
        rankSpacing: 50
---
flowchart TD
subgraph _
subgraph main
getComp@{shape: fr-rect, label: "getComputerChoice
computer choice func"} -.-o eventHandler
getWinner@{shape: fr-rect, label: "getWinner
winner calc func"} -.-o eventHandler
displayFunc@{shape: fr-rect, label: "showWinner
display func"} -.-o eventHandler
init
subgraph clickEventListener[Click Event]
    eventHandler@{shape: fr-rect, label: "play
event handler"}
end
end
init -.-o |"(1) initialize values and functions
clean interface
add event listeners (event handlers:playGame clearModal restartGame)"|interface@{shape: curv-trap, label: "interface display"}
clickEventListener --> stop@{shape: framed-circle}
start@{shape: start} --> init@{shape: hex, label: "Initial Settings"}
choicess@{shape: rounded} --> |"(2) user choice: either paper, rock or scissors"| clickEventListener
clickEventListener --> |"(3) animations, results"| interface

subgraph legend
      direction LR
      subgraph flowlines
        start1[ ] -->|"next step"| stop1[ ]
        style start1 height:0px;
        style stop1 height:0px;
        start2[ ] -.-o|"assignation"| stop2[ ]
        style start2 height:0px;
        style stop2 height:0px;
      end
      subgraph shapes
      subprocess[subprocess]
      end
end
end
interface ~~~ legend

style start fill:black
style stop fill:black, fill-stroke:white

The `play` event handler as a Controller

In this project, the play function resembles more the idea of a controller. The tasks of this event handler are reduced to act as a delegator, something that we have not seen fully implemented in the previous projects.

// Play game
function play(e) {
  restart.style.display = 'inline-block';
  const playerChoice = e.target.id;
  const computerChoice = getComputerChoice();
  const winner = getWinner(playerChoice, computerChoice);
  showWinner(winner, computerChoice);
}

The Controller Pattern is a common architectural pattern used in interactive applications to manage user input by directing it to other components for processing and coordination. The play controller will be the one coordinating the actions once the user calls the function from the interface.

Modularity and Separatation of Concerns (SoC)

However, this one is very modular, following a structured procedural flow.

That modularity could be associated to achieving a better Separation of Concerns, or SoC. SoC involves designing code so each section of the code is handled by a different operational unit. Despite its size, this code shows attention to that principle in the form of functions.

Procedural Programming

Procedural programming is a form of imperative programming where procedures are delegated to functions. The way the project is designed is more in accordance to those practices.

Finalizing the diagram and comparison to previous projects

The functional operations of the functions called by the controller are more evident from the final diagram for this project:

---
title: “Rock Paper Scissors” by B. Traversy - Final SB-Diagram
config:
    theme: dark
    layout: "elk"
    flowchart:
        nodeSpacing: 50
        rankSpacing: 50
---
flowchart TD
subgraph _
subgraph main
init
data@{shape: lean-r, label: "scoreboard object"} -.-o displayFunc
step05 --> data
subgraph clickEventListener[Click Event]
    subgraph eventHandler["play
event handler"]
        step01@{label: "step01 - prepare display"} --> step02@{label: "step02 - compute\ncomputer choice"}
        step02 --> step03@{label: "step03 - compute winner"} --> step04@{label: "step04 - result handling and presentation"}
    end
end
getComp@{shape: fr-rect, label: "getComputerChoice
computer choice func"} -.-o step02
getWinner@{shape: fr-rect, label: "getWinner
winner calc func"} -.-o step03
subgraph displayFunc["showWinner
display func"]
    step05@{label: "stpp01 - update stored data"} --> step06@{label: "step02 - show results\nin a modal"}
end
displayFunc -.-o step04
end
init -.-o |"(1) initialize values and functions
clean interface
add event listeners (event handlers:playGame clearModal restartGame)"|interface@{shape: curv-trap, label: "interface display"}
clickEventListener --> stop@{shape: framed-circle}
start@{shape: start} --> init@{shape: hex, label: "Initial Settings"}
choices@{shape: rounded} --> |"(2) user choice: either paper, rock or scissors"| clickEventListener
step06 --> |"(3) animations, results"| interface
restartGame@{shape: rounded} --> |"(4a) restart data"| data
restartGame --> |"(4b) clean interface"| interface

subgraph legend
      direction LR
      subgraph flowlines
        start1[ ] -->|"next step"| stop1[ ]
        style start1 height:0px;
        style stop1 height:0px;
        start2[ ] -.-o|"assignation"| stop2[ ]
        style start2 height:0px;
        style stop2 height:0px;
      end
      subgraph shapes
      variable["variable"]
      style variable width:135px, fill:none, stroke:none, color:#f1ce32
      subprocess[subprocess]
      stepLegend["----step----"]
      style stepLegend fill:#474949, stroke: #CCC, color:#CCC
      end
end
end

interface ~~~ legend

style start fill:black
style stop fill:black, fill-stroke:white
classDef subProc fill:#1f2020, stroke: #CCC, color:#CCC
class eventHandler,displayFunc subProc
classDef step fill:#474949, stroke: #CCC, color:#CCC
class step01,step02,step03,step04,step05,step06 step

Let’s point out the different steps carried out by the delegated functions:

The getComputerChoice is in charge of calculating the computer’s choice.
Results are collected by the controller and passed to another function, getWinner, which is in charge of calculating the winner.
Then the results of the getWinner function are collected by the controller and passed to the next function, showWinner.
The showWinner function has a similar design as the one made by Hmz C for his project. It will have just one less responsibility, and will take only responsibilities for data handling of a slightly more complex data type for the capture and maintance of the current score (the scoreboard object), as well as displaying results.

Despite of the differences in the way the code was designed, the order of the steps is very similar to the projects we have discussed before.

Other features different from the previous code examples are the existence of a modal for result presentation and a reset functionality. We are not discussing them as they fall outside of the scope of the analyses, which is the design of the Rock, Paper, Scissors game.

4. “Rock Paper Scissors OOP” by Damian: A project written in OOP

Damian has 3 projects on CodePen, all of them made in 2020. One of them is this game. The JavaScript code implements another variation of the "Rock, Paper, Scissors" game but with a more object-oriented approach using classes to manage the game logic, player choices, and statistics.

This is a well-organized, object-oriented version of the "Rock, Paper, Scissors" game with a clean separation of concerns (result calculation, player/computer choice, and game statistics). The use of animations and UI interactions enhances the user experience.

Key features of this project are:

Object-oriented design: The code is structured into classes, making it modular, reusable, and easier to maintain.
Interactive UI: It dynamically updates the player’s and computer’s choices using visual cues (CSS classes) and shows animations for draws.
Statistics: The game tracks and updates the number of wins, draws, and losses, which are displayed in real-time.

Analysis of the Project

Quickly discovering the start and end of the workflow

This code seems more complex than what we’ve previously examined. But a closer look suggests certain resemblance to the previous ones, at least at a high level of generalization:

Again, variables and states are initialized once the project is accessed.
One of the variables that’s initialized when the project is accessed is an instance of a class, the Game class. The instance is called newGame.

---
title: “Rock Paper Scissors OOP” by Damian - Simple SB-Diagram 01
config:
    theme: dark
    layout: "elk"
    flowchart:
        nodeSpacing: 50
        rankSpacing: 50
---
flowchart TD
subgraph _
subgraph main
    gameInst@{shape: fr-rect, label: "Game instance"}
end
gameInst -.-o |"(1) instantiate classes, values, and functions
clean interface
add event listeners (events: startGame method bound to this)"|interface
gameInst --> stop@{shape: framed-circle}
start@{shape: start} --> gameInst
choices@{shape: rounded} --> |"(2) user choice: either paper, rock or scissors"| gameInst
gameInst --> |"(3) animations, results"| interface@{shape: curv-trap, label: "interface display"}

subgraph legend
      direction LR
      subgraph flowlines
        start1[ ] -->|"next step"| stop1[ ]
        style start1 height:0px;
        style stop1 height:0px;
        start2[ ] -.-o|"assignation"| stop2[ ]
        style start2 height:0px;
        style stop2 height:0px;
      end
      subgraph shapes
      instance[-instance-]
      style instance stroke:violet, stroke-width: 3px;
      end
end
end
interface ~~~ legend

style start fill:black
style stop fill:black, fill-stroke:white
classDef inst fill:#1f2020, color:#87f134, stroke:violet, stroke-width: 3px
class gameInst inst

Again, we can see aspects of this workflow that coincide with what we found in the previous projects – but this time those similarities are more difficult to capture. As in the previous code, the controller pattern is prevalent in this code, but instead of being associated with an anonymous function or a global one, it is now a class’s module.

The instantiation of the class runs the constructor which includes the immediate assignment of click event handlers into the interface (just as with the other projects). They use a module of the class, the startGame module, as a callback function.

The (syntactic) approach that Damian chose adds additional complexities to the code in terms of scope definition. You can spot some of the complexities by realizing the need to use the JavaScript bind method in order to keep the this context of the module function the same as the one of the instance when assigned to the event.

class Game {
  constructor() {
    this.optionsImg = document.querySelectorAll('.img');
    this.optionsBtns = document.querySelectorAll('button');

    this.optionsBtns.forEach(option => option.addEventListener('click', 
                                                                this.startGame.bind(this) //see the bind here
                                                                )
                            )

    this.youWins = document.querySelector('.results > .you-win');
    this.draw = document.querySelector('.results > .draw');
    this.PcWins = document.querySelector('.results > .pc-win');

    this.stats = new Stats(0, 0, 0);

    this.render.call(this, this.stats.getStats());
  }

In order to represent that, I used a colored link, indicating that the game instance (through the constructor) is set to be the this context of the module.

---
title: “Rock Paper Scissors OOP” by Damian - Simple SB-Diagram 02
config:
    theme: dark
    layout: "elk"
    flowchart:
        nodeSpacing: 50
        rankSpacing: 50
---
flowchart TD
subgraph _
subgraph main
    subgraph gameInst[Game instance]
        gameConstrt@{shape: fr-rect, label: "Game constructor"}
        startGame@{shape: fr-rect, label: "startGame
method / event handler"}
        gameConstrt -.-o startGame 
    end
end
gameConstrt -.-o |"(1) instantiate classes, values, and functions
clean interface
add event listeners (events: startGame method bound to this)"|interface
startGame --> stop@{shape: framed-circle}
start@{shape: start} --> gameInst
choices@{shape: rounded} --> |"(2) user choice: either paper, rock or scissors"| startGame
gameInst --> |"(3) animations, results"| interface@{shape: curv-trap, label: "interface display"}

subgraph legend
      direction LR
      subgraph flowlines
        start1[ ] -->|"next step"| stop1[ ]
        style start1 height:0px;
        style stop1 height:0px;
        start2[ ] -.-o|"assignation"| stop2[ ]
        style start2 height:0px;
        style stop2 height:0px;
        start3[ ] -.-o|"context of"| stop3[ ]
        linkStyle 8 stroke:yellow, stroke-width:5px
        style start3 height:0px;
        style stop3 height:0px;
      end
      subgraph shapes
      subprocess[subprocess]
      instance[-instance-]
      style instance stroke:violet, stroke-width: 3px;
      end
end
end
interface ~~~ legend

style start fill:black
style stop fill:black, fill-stroke:white
classDef subProc fill:#1f2020, stroke: #CCC, color:#CCC
class eventHandler,gameConstrt subProc
classDef inst fill:#1f2020, color:#87f134, stroke:violet, stroke-width: 3px
class gameInst inst
linkStyle 0 stroke:yellow, stroke-width: 5px

By adding the evaluation of the classes, the flow diagram gets more detailed but also more complicated.

Damian defined 4 classes for this project: Result, which was just a static method, Choice, Stats and Game:

class Result {
  static whoWin(yourChoice, PCchoice) {
    ...
  }
}

class Choice {
  constructor(yourChoice) {
    ...
  }

  getYourChoice = () => this.yourChoice;
  getPcChoice = () => this.PCchoice;

  drawPcChoice() {
    ...
  }
}

class Stats {
  constructor(wins, draws, loses) {
    ...
  }
  getStats = () => this.status;

  refreshStats(result) {
    ...
  }
}

class Game {
  constructor() {
    ...
  }

  startGame(e) {
    ...
  }

  render(stats) {
    ...
  }
}

const newGame = new Game();

The best way to keep the diagram simpler is not to detail all the steps of the functionalities. But since I’m mentioning instances, I also felt the urgency to relate those to the corresponding class. I did it using a different line type and color.

---
title: “Rock Paper Scissors OOP” by Damian - SB-Diagram Refinement
config:
    theme: dark
    layout: "elk"
    flowchart:
        nodeSpacing: 50
        rankSpacing: 50
---
flowchart TD
subgraph _
subgraph main
    subgraph gameInst[Game instance]
        gameConstrt@{shape: fr-rect, label: "Game constructor"}
        startGame@{shape: fr-rect, label: "startGame
method / event handler"}
        render@{shape: fr-rect, label: "render\ndisplay method"}
        gameConstrt -.-o startGame
    end
    classGame@{shape: rounded, label: "Game class"} -.- gameInst
    classStat@{shape: rounded, label: "Stat class"} -.-o gameConstrt
    classResult@{shape: rounded, label: "Result class"} -.-o startGame
    classChoice@{shape: rounded, label: "Choice class"} -.-o startGame
    classStat -.-o render
end
gameConstrt -.-o |"(1) instantiate classes, values, and functions
clean interface
add event listeners (events: startGame method bound to this)"|interface
gameInst --> stop@{shape: framed-circle}
start@{shape: start} --> gameInst
choices@{shape: rounded} --> |"(2) user choice: either paper, rock or scissors"| startGame
gameInst --> |"(3) animations, results"| interface@{shape: curv-trap, label: "interface display"}

subgraph legend
      direction LR
      subgraph flowlines
        start1[ ] -->|"next step"| stop1[ ]
        style start1 height:0px;
        style stop1 height:0px;
        start2[ ] -.-o|"assignation"| stop2[ ]
        style start2 height:0px;
        style stop2 height:0px;
        start3[ ] -.-o|"context of"| stop3[ ]
        linkStyle 13 stroke:yellow, stroke-width:5px
        style start3 height:0px;
        style stop3 height:0px;
        start4[ ] -.-|"instance of"| stop4[ ]
        linkStyle 14 stroke:skyblue, stroke-width:4px
        style start4 height:0px;
        style stop4 height:0px;
      end
      subgraph shapes
      subprocess[subprocess]
      instance[-instance-]
      style instance stroke:violet, stroke-width: 3px;
      stepLegend["----step----"]
      style stepLegend fill:#474949, stroke: #CCC, color:#CCC
      end
end
end
interface ~~~ legend

style start fill:black
style stop fill:black, fill-stroke:white
classDef isaclass fill:grey
class classGame,classChoice,classResult,classStat isaclass
classDef subProc fill:#1f2020, stroke: #CCC, color:#CCC
class eventHandler,gameConstrt subProc
classDef inst fill:#1f2020, color:#87f134, stroke:violet, stroke-width: 3px
class gameInst inst
linkStyle 0,5 stroke:yellow, stroke-width: 5px
linkStyle 1 stroke:skyblue, stroke-width:4px

With the diagram above, I tried to highlight some exceptional aspects of the architecture of this code. At some point, a Stats class’s instance will be context for the render method of the Game class’s instance. I added connections between classes and the workflow to indicate that the classes were used on those steps of the workflow.

OOP Encapsulation

One way to improve the SoC of your project is through encapsulation. Encapsulation is a concept usually related to OOP and it’s about keeping data and the methods that work with that data bundled in the same class.

This project shows efforts to achieve encapsulation:

The Stats instance it is the one that will store the data, and the methods are in accordance to its task:

  class Stats {
    constructor(wins, draws, loses) {
      this.status = {
        wins: wins,
        draws: draws,
        loses: loses,
      }
    }
    getStats = () => this.status;

    refreshStats(result) {
      switch (result) {
        case "win":
          this.status.wins++;
          break;
        case "draw":
          this.status.draws++;
          break;
        case "lose":
          this.status.loses++;
          break;
      }
    }
  }

The Choice instance will be dedicated to the calculation of the choices, and so it contains methods that respond to that task:

  class Choice {
    constructor(yourChoice) {
      this.yourChoice = yourChoice;
      this.PCchoice = this.drawPcChoice();
    }

    getYourChoice = () => this.yourChoice;
    getPcChoice = () => this.PCchoice;

    drawPcChoice() {
      const options = ["rock", "paper", "scissors"];

      return options[Math.floor(Math.random() * options.length)];
    }
  }

Finalizing the diagram and comparison to previous projects

For the final diagram of the project, I wanted to:

Emphasize the importance of the methods in the classes by mentioning them in their corresponding class, and
Indicate the apparent importance of the Stats instance in the workflow.

Here the final diagram of this project:

---
title: “Rock Paper Scissors OOP” by Damian - Final SB-Diagram
config:
    theme: dark
    layout: "elk"
    flowchart:
        nodeSpacing: 50
        rankSpacing: 50
---
flowchart TD
subgraph _
subgraph main
    subgraph gameInst[Game instance]
        subgraph gameConstrt["Game constructor"]
            init@{shape: hex, label: "Initial Settings"} --> statInst@{shape: fr-rect, label: "Stat instance"}
        end
        subgraph eventHandler["startGame
method / event handler"]
            step01[step01 - animation] --> step02[step02 - calculate computer choice]
            step02 --> step03[step03 - prepare display]
            step03 --> step04[step04 - calculate winner and update data]
            step04 --> step05[step05 - show result]
        end
        gameConstrt -.-o eventHandler
        statInst -.-o |"use calc'd winner to update status running refreshStats"| step04
        render@{shape: fr-rect, label: "render\ndisplay method"}
    end
    classGame@{shape: rounded, label: "Game class
---------------"} -.- gameInst
    classStat@{shape: rounded, label: "Stat class
-----------------------
+status (obj / data)
-----------------------
+refreshStats()
+getStats(result)"} -.- statInst
    classResult@{shape: rounded, label: "Result class
--------------------------
+whoWin(yourCh, pcCh)"} -.-o |"use Result static method to calculate winner"| step04
    classChoice@{shape: rounded, label: "Choice class
--------------------
+yourCh, pcCh
--------------------
+getYourChoice()
+getPcChoice()
+drawChoice()"} -.-o |use Choice instance to draw PC choice| step02
    statInst -.-o render
    render -.-o |"take Stat's status and show yourCh / pcCh
last score"| step05
end
gameConstrt -.-o |"(1) instantiate classes, values, and functions
clean interface
add event listeners (events: startGame method bound to this)"|interface
eventHandler --> stop@{shape: framed-circle}
start@{shape: start} --> init
choices@{shape: rounded} --> |"(2) user choice: either paper, rock or scissors"| eventHandler
eventHandler --> |"(3) animations, results"| interface@{shape: curv-trap, label: "interface display"}
subgraph legend
      direction LR
      subgraph flowlines
        start1[ ] -->|"next step"| stop1[ ]
        style start1 height:0px;
        style stop1 height:0px;
        start2[ ] -.-o|"assignation"| stop2[ ]
        style start2 height:0px;
        style stop2 height:0px;
        start3[ ] --o|"context of"| stop3[ ]
        linkStyle 20 stroke:yellow, stroke-width:5px
        style start3 height:0px;
        style stop3 height:0px;
        start4[ ] -.-|"instance of"| stop4[ ]
        linkStyle 21 stroke:skyblue, stroke-width:4px
        style start4 height:0px;
        style stop4 height:0px;
      end
      subgraph shapes
      variable["variable"]
      style variable width:135px, fill:none, stroke:none, color:#f1ce32
      subprocess[subprocess]
      instance[-instance-]
      style instance stroke:violet, stroke-width: 3px;
      stepLegend["----step----"]
      style stepLegend fill:#474949, stroke: #CCC, color:#CCC
      end
end
end
interface ~~~ legend

style start fill:black
style stop fill:black, fill-stroke:white
classDef isaclass fill:grey
class classGame,classChoice,classResult,classStat isaclass
classDef subProc fill:#1f2020, stroke: #CCC, color:#CCC
class eventHandler,gameConstrt subProc
classDef step fill:#474949, stroke: #CCC, color:#CCC
class init,step01,step02,step03,step04,step05 step
classDef inst fill:#1f2020, color:#87f134, stroke:violet, stroke-width: 3px
class statInst,gameInst inst
linkStyle 5,11 stroke:yellow, stroke-width: 5px
linkStyle 7,8 stroke:skyblue, stroke-width:4px

What makes this code similar to the previous ones is the following:

The order of the steps is very similar
A initial step is taken to set variables to initial stages and register an event handler function to the corresponding click events
This project is also imperative in its design

This project shares more similarities to the project by Brad Traversy.

The design of the event handler is closer to a controller pattern
Therefore, modularity and SoC seem to be concepts that guided the design.
The processing of the operations are organized according to procedural programming.

That’s where the similarities stop.

The initialization of the game is through the instantiation of a class:
```
  const newGame = new Game();
```
Different to all the previous projects, the event handler / controller is now a method of the instantiated class. The method is then registered as event handler of the click events right from the constructor when the class is instantiated.
Modularity occurs through calling methods of instantiated classes, instead of (globally declared) functions.
By using the OOP paradigm, this project shows a higher level of SoC by adding encapsulation.
There are special cases in this code where it was required to bind to the appropriate this context. Examples are the binding of the Game class methods.

5. “Recurrent Neural Network – Rock, Paper, Scissors” by Andrew Worcerster: A Project Implementing AI

Andrew Worcester hasn’t been a regular contributor to CodePen but has created about 50 projects since 2013. The project we are going to analyze was created in 2019, one year after the first release of brain.js.

This code implements a more advanced version of the "Rock, Paper, Scissors" game, which uses neural networks (via the brain.js library) to predict the player’s next move and even simulate emotions for the computer opponent based on its win/loss patterns.

This code creates an engaging, AI-driven version of "Rock, Paper, Scissors" with advanced features like move prediction and emotional simulation using neural networks.

Key features of this project are:

Neural Network for prediction: a model to predict the player’s next move based on their move history creates an adaptive gameplay experience, where the CPU adjusts its strategy.
Emotion simulation: another model simulating emotions based on the game results (win/loss history), and it displays appropriate emojis like 😫, 😊, and so on, next to its moves.
Interactive UI: The game uses DOM manipulation to display the player’s move, the CPU’s move, the result, and the CPU’s emotional state after each round.
Dynamic scoring: Both player and CPU scores are updated and displayed after each round.

Analysis of the Project

Quickly discovering of the start and end of the workflow

At a high level of generalization, this code follows the same pattern as the other projects, although the complexity of the functionalities has grown:

Again, variables and states are initialized once the project is accessed.
Apart from that, an event handler of the click event is assigned carrying an anonymous function as a callback function. The contoller pattern seems to reappear in this project too.

---
title: “Recurrent Neural Network – Rock, Paper, Scissors” by A. Worcerster - Simple SB-Diagram
config:
    theme: dark
    layout: "elk"
    flowchart:
        nodeSpacing: 50
        rankSpacing: 50
---
flowchart TD
subgraph _
subgraph main
init
subgraph clickEventListener["Click Event (forEach on options)"]
    eventHandler@{shape: fr-rect, label: "anonymous func
event handler"}
end
end
init --> |"(1) initialize values (dummies for cpuNextMove data) and functions (functions: brain.recurrent.LSTM net brain.NeuralNetwork emoNet, calcNextMove)
clean interface
add event listeners (event handlers: anoymous function)"|interface
clickEventListener --> stop@{shape: framed-circle}
start@{shape: start} --> init@{shape: hex, label: "Initial Settings"}
choices --> |"(2) user choice: either paper, rock or scissors"| clickEventListener
clickEventListener --> |"(3) animations, results"| interface
end
style start fill:black
style stop fill:black, fill-stroke:white

A key difference from previous projects is the training of the neural network operations. Some of those functionalities are initialized to a initial state even before the user clicks.

If we still keep a high level of generalization, we can see that several of the responsibilities of the workflow will be taken by functions and even operations outside the event handler.

The project has several brain.js functionalities in place. The most evident ones are:

The LSTM (Long Short Term Memory), which it is a neural network designed to capture associations and patterns that are separated in time or place - and it is the one associated with the prediction of the user’s next move.
A default feed-forward neural network of just one layer, designed to compare immediate patterns, and it is the one associated with the simulation of the emotions.

The LSTM is used by another function, calcNextMove, to provide an immediate result even before the user interacts with the click event: a value for the cpuNextMove variable.

cpuNextMove is indeed the calculation of the computer’s choice and it occurs before the user clicks, starting with a default value based on fake data.

---
title: “Recurrent Neural Network – Rock, Paper, Scissors” by A. Worcerster - SB-Diagram Refinement 01
config:
    theme: dark
    layout: "elk"
    flowchart:
        nodeSpacing: 50
        rankSpacing: 50
---
flowchart TD
subgraph _
subgraph main
init
constvar@{shape: lean-r, label: "constants and variables"} -.-o clickEventListener
LSTM@{shape: fr-rect, label: "net
LSTM"} -.-o calcNextMove
calcNextMove@{shape: fr-rect, label: "calcNextMove
computer choice"} --> cpuNextMove@{shape: lean-r, label: "cpuNextMove"}
NN@{shape: fr-rect, label: "emoNet
NN"} -.-o clickEventListener
cpuNextMove -.-o clickEventListener
subgraph clickEventListener["Click Event
(forEach on options)"]
    eventHandler@{shape: fr-rect, label: "anonymous func
event handler"}
end
end
init --> |"(1) initialize values (dummies for cpuNextMove data) and functions (functions: brain.recurrent.LSTM net brain.NeuralNetwork emoNet, calcNextMove)
clean interface
add event listeners (event handlers: anoymous function)"|interface
clickEventListener --> stop@{shape: framed-circle}
start@{shape: start} --> init@{shape: hex, label: "Initial Settings"}
choices --> |"(2) user choice: either paper, rock or scissors"| clickEventListener
clickEventListener --> |"(3) animations, results"| interface

subgraph legend
      direction LR
      subgraph flowlines
        start1[ ] -->|"next step"| stop1[ ]
        style start1 height:0px;
        style stop1 height:0px;
        start2[ ] -.-o|"assignation"| stop2[ ]
        style start2 height:0px;
        style stop2 height:0px;
      end
      subgraph shapes
      variable["variable"]
      style variable width:135px, fill:none, stroke:none, color:#f1ce32
      subprocess[subprocess]
      instance[-instance-]
      style instance stroke:violet, stroke-width: 3px;
      end
end
end
interface ~~~ legend

style start fill:black
style stop fill:black, fill-stroke:white
classDef inst fill:#1f2020, color:#87f134, stroke:violet, stroke-width: 3px
class NN,LSTM inst

This project has some complexities not seen in previous projects, so I will try to go through it slowly. Let’s first see another level of refinement where the steps are shown:

---
title: “Recurrent Neural Network – Rock, Paper, Scissors” by A. Worcerster - SB-Diagram Refinement 02
config:
    theme: dark
    layout: "elk"
    flowchart:
        nodeSpacing: 50
        rankSpacing: 50
---
flowchart TD
subgraph _
subgraph main
init
constvar@{shape: lean-r, label: "constants and variables"} -.-o clickEventListener
step05 --> data@{shape: lean-r, label: "data"}
data -.-o calcNextMove
subgraph step00["stepInit - calculate computer choice"]
    calcNextMove@{shape: fr-rect, label: "calcNextMove
computer choice"} --> cpuNextMove@{shape: lean-r, label: "cpuNextMove"}
    LSTM@{shape: fr-rect, label: "net
LSTM instance"} -.-o calcNextMove
    cpuNextMove -.-o Dout((A))
    cpuNextMove -.-o Eout((B))
end
NN@{shape: fr-rect, label: "emoNet
NN"} -.-o step03
subgraph clickEventListener["Click Event
(forEach on options)"]
    subgraph eventHandler["anonymous func
event handler"]
        step01["step01 - prepare a scoring table for that option"] --> step02["step02 - calculate winner"]
        step02 --> step03["step03 - calculate cpu emotion"]
        step03 --> step04["step04 - result handling and presentation: Winner"]
        step04 --> step05["step05 - update data"]
        step05 --> step06["step06 - recalculate winner and prepare display"]
        step06 --> step07["step07 - calc next move; result handling and presentation: Scores"]
        Din((A)) -.-o step02
        Ein((B)) -.-o step06    
    end
end
end
init --> |"(1) initialize values (dummies for cpuNextMove data) and functions (functions: brain.recurrent.LSTM net brain.NeuralNetwork emoNet, calcNextMove)
clean interface
add event listeners (event handlers: anoymous function)"|interface
clickEventListener --> stop@{shape: framed-circle}
start@{shape: start} --> init@{shape: hex, label: "Initial Settings"}
choices --> |"(2) user choice: either paper, rock or scissors"| clickEventListener
clickEventListener --> |"(3) animations, results"| interface

subgraph legend
      direction LR
      subgraph flowlines
        start1[ ] -->|"next step"| stop1[ ]
        style start1 height:0px;
        style stop1 height:0px;
        start2[ ] -.-o|"assignation"| stop2[ ]
        style start2 height:0px;
        style stop2 height:0px;
      end
      subgraph shapes
      variable["variable"]
      style variable width:135px, fill:none, stroke:none, color:#f1ce32
      subprocess[subprocess]
      instance[-instance-]
      style instance stroke:violet, stroke-width: 3px;
      end
end
end
interface ~~~ legend

style start fill:black
style stop fill:black, fill-stroke:white
classDef subProc fill:#1f2020, stroke: #CCC, color:#CCC
class eventHandler,gameConstrt subProc
classDef inst fill:#1f2020, color:#87f134, stroke:violet, stroke-width: 3px
class NN,LSTM inst
classDef step fill:#474949, stroke: #CCC, color:#CCC
class step00,step01,step02,step03,step04,step05,step06,step07 step
classDef connectorcpuNextMove fill:skyblue, color:black
class Dout,Din,Eout,Ein connectorcpuNextMove

We can see from the diagram that:

The cpuNextMove is pre-calculated, and so the calculation of the computer’s choice occurs before the user’s next click. I have referred to this step as “stepInit” to indicate that the first calculation occurs at initialization.
After the choice of the user is captured, its value and the value of cpuNextMove are eventually used to calculate the winner. The result is stored to keep the history of computer scoring.
The history of computer scoring is the input used for the calculation of the emotions using the emoNet.
The user’s choice is then used to create the next entry for data, which keeps the history of user scoring within the data in a dedicated format.
After calculating the winner and displaying the results, the project will use data to calculate the cpuNextMove before the user clicks again.

Finalizing the diagram and comparison to previous projects

We could have finished with the previous diagram as it is largerly refined, but I wanted to practice another level of refinement to reveal the role of that the data flow has in this project. This resulted in a more complex diagram that those previously shown:

---
title: “Recurrent Neural Network – Rock, Paper, Scissors” by A. Worcerster - Final SB-Diagram
config:
    theme: dark
    layout: "elk"
    flowchart:
        nodeSpacing: 50
        rankSpacing: 50
---
flowchart TD
subgraph _
subgraph main
init
constvar@{shape: lean-r, label: "constants and variables data@{shape: lean-r, label: "data"}
cpuWinLoss@{shape: lean-r, label: "cpuWinLoss"} -.-o Aout((A))
cpuWinLoss@{shape: lean-r, label: "cpuWinLoss"} -.-o Bout((B))
cpuWinLoss@{shape: lean-r, label: "cpuWinLoss"} -.-o Cout((C))
subgraph step00["stepInit - calculate computer choice"]
    calcNextMove@{shape: fr-rect, label: "calcNextMove
computer choice"} --> cpuNextMove@{shape: lean-r, label: "cpuNextMove"}
    LSTM@{shape: fr-rect, label: "net
LSTM instance"} -.-o calcNextMove
    cpuNextMove -.-o Dout((A))
    cpuNextMove -.-o Eout((B))
end
data -.-o calcNextMove
delay01 --> calcNextMove  
NN@{shape: fr-rect, label: "emoNet
NN instance"} -.-o step03
subgraph clickEventListener["Click Event
(forEach on options)"]
    subgraph eventHandler["anonymous func
event handler"]
        scoreValues@{shape: lean-r, label: "scoreValues"}
        step01["step01 - prepare a scoring table for this specific option"] --> step02["step02 - calculate winner and update of cpu history"]
        step01 -.-o scoreValues
        subgraph step03["step03 - calculate cpu emotion"]
           likely@{shape: fr-rect, label: "brain.likely
estimator func"} ~~~ nonode01[ ]
           style nonode01 height:0px;
        end

        Din((A)) -.-o step02
        scoreValues -.-o step02
        step02 --> step03
        step03 --> step04["step04 - result handling and presentation: Winner"]
        scoreValues -.-o step04
        step04 --> step05["step05 - update data"]
        step05 --> step06["step06 - recalculate of winner and prepare display"]
        subgraph step07["step07 - calc next move"]
             delay01@{shape: delay, label: outer setTimeout}
            subgraph step08["step08 - result handling and presentation: Scores"]
                delay02@{shape: delay, label: inner setTimeout}
            end
        end

        Cin((C)) -.-o delay02
        step06 --> delay01
        delay02 -.-o delay01
        Ain((A)) -.-o step02
        Bin((B)) -.-o likely
        Ein((B)) -.-o step04

    end
end
end
init --> |"(1) initialize values (dummies for cpuNextMove data) and functions (functions: brain.recurrent.LSTM net brain.NeuralNetwork emoNet, calcNextMove)
clean interface
add event listeners (event handlers: anoymous function)"|interface
eventHandler --> stop@{shape: framed-circle}
start@{shape: start} --> init@{shape: hex, label: "Initial Settings"}
choices --> |"(2) user choice: either paper, rock or scissors"| clickEventListener
clickEventListener --> |"(3) animations, results"| interface

subgraph legend
      direction LR
      subgraph flowlines
        start1[ ] -->|"next step"| stop1[ ]
        style start1 height:0px;
        style stop1 height:0px;
        start2[ ] -.-o|"assignation"| stop2[ ]
        style start2 height:0px;
        style stop2 height:0px;
      end
      subgraph shapes
      variable["variable"]
      style variable width:135px, fill:none, stroke:none, color:#f1ce32
      subprocess[subprocess]
      instance[-instance-]
      style instance stroke:violet, stroke-width: 3px;
      end
end
end
interface ~~~ legend

style start fill:black
style stop fill:black, fill-stroke:white
classDef subProc fill:#1f2020, stroke: #CCC, color:#CCC
class eventHandler,gameConstrt subProc
classDef step fill:#474949, stroke: #CCC, color:#CCC
class step00,step01,step02,step03,step04,step05,step06,step07,step08 step
classDef inst fill:#1f2020, color:#87f134, stroke:violet, stroke-width: 3px
class LSTM,NN inst
classDef connectorcpuWinLoss fill:white, color:black
class Aout,Ain,Bout,Bin,Cout,Cin connectorcpuWinLoss
classDef connectorcpuNextMove fill:skyblue, color:black
class Dout,Din,Eout,Ein connectorcpuNextMove

I think the use of the data in this project deserved additional explanation. In fact, it is not only the use of machine learning procedures that makes this project more complex – but also its associated use of more advanced data structures.

Here’s a selection of some possible values for some of the variables used to collect data at different points of the workflow:

data structures:

"cpuNextMove: " "👊"

"cpuEmotions: " // [object Array] (4)
["😟","😨","😕","🤨"]

"data: " // [object Array] (3)
[// [object Array] (4)
["✌️","👊","✋","✌️"],// [object Array] (4)
["👊","✋","✌️","✌️"],// [object Array] (4)
["✋","✌️","✌️","✋"]]

"scoreValues: " // [object Object] 
{
  "✋": 0.3,
  "✌️": 1,
  "👊": 0
}

"cpuWinLoss: " // [object Array] (5)
[0.3,0.3,0.3,1,0]

The way data is made (an array of arrays) is a requirement for the LSTM algorithm in this particular case.

Also interesting is the use of the scoreValues object.

        const scoreValues = {
            [options[myMoveIdx]]: 0.3,         // tie
            [options[(myMoveIdx + 1) % 3]]: 1, // cpu wins
            [options[(myMoveIdx + 2) % 3]]: 0  // cpu loses
        };

Notice how the user’s choice (myMoveIdx) is used to compute the different possible computer’s choices as key, with the values associated to each key being the potential result for the computer given that user’s choice. The values have the form of a “score”:

0 if the computer lost the match
0.3 if there was a tie
1 if the computer won the match

With this object, finding if the computer won, lost or drew consists in finding the value, or score, which key is equals to cpuNextMove. In other words, scoreValues is a template used to calculate the winner.

The computer’s score will be then saved in an array, cpuWindLoss:

cpuWinLoss.push(scoreValues[cpuNextMove]);

Values of the cpuWinLoss array will be eventually used to calculate the emotions. cpuEmotions is an array of emotion predictions based on the last 4 CPU scores. The predictions are obtained from a “table of emotions” that was arbitrarily suggested by the author (the emo object).

Aspects of this project that we can relate to previous ones are:

It is made using imperative programming.
The existence of a event handler with poor modularity makes it more comparable to the way the event handler was designed in the less advanced projects, where the event handler took most of the responsibilities of the operations and the variables and utilities were declared at the global scope.
At a high level of generalization, the essential steps of the game design stay the same:
- a function (calcNextMove) calculates the computer’s choice.
- another functionality (the operations around the emotion calculation) takes part in the realization of the “animation” associated with the corresponding display of the results.
- An operation to calculate the winner is also present.
- This project has also data handling logic, although much more advanced than previous projects

But how some of those steps are realized is very different in this project:

The computer’s choice is based on the user’s scoring history, not a random function.
The computer’s choice calculation occurs before the user clicks. While the calculation could have been done before user interaction in previous projects without affecting their outcomes (assuming the user wouldn’t have access to the value of the computer’s choice before playing), performing it at click time here might have caused performance issues due to its higher CPU demand compared to the simpler Math.random. Thus, performance likely influenced the design choices.
The calculation of the winner is based not on a typical conditional control flow (if-else) or even a ternary operator, but rather obtained from a search across a customized data structure.
Instead of using logic that generates feedback independently of previous results, this game uses a more advanced process that factors in both the computer’s move and recent game history to generate contextual UI feedback after each turn.
The different implementations for the operations carried out by this project required different types of data structures with different levels of complexity, so data handling was more complex.

If you were able to follow the analysis specifically for this project and want to compare it to a similar project implementing the same game, check the example provided by brain.js team. You might need to have a basic knowledge of Vue.js though.

Final Thoughts

As a developer, you will be exposed to many different lines of creative code yourself. Or how Robert C. Martin pointed it out in his book “Clean Code”:

“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code.”

So, learning to understand other people’s code is an essential skill that every programmer should develop. And this learning only happens by studying other people’s code and trying to reveal their tricks and bugs.

That is why finding good ways to reveal patterns when comparing code is so important. And that has been the main purpose of this project.

When I started, I still wasn’t sure about what to expect from the approach. Let me share with you what I learned.

What I found limiting from this approach was:

The more complex the code, the more complex the diagram gets, making it difficult to read. And the more difficult the diagram, the more difficult is to work out a diagram with Mermaid.js. You will also have to make more definitions, add more color, use more tricks, and so on in order to seek clarity. And the more “solutions” you have to find to clarify your diagram, the higher the risk of making it less clear.
It takes time and practice. This kind of technique is not something that you learn all at once. You might find yourself making a lot of changes before getting the “right” result. If you are doing this with Mermaid.js or any other scripting tool, you will have to learn to script with them, too.
This approach is not about visualizing algorithms or syntax. I suspect that if you read the analyses of this article with no knowledge about machine learning or object-oriented programming, this analysis likely didn’t teach you how to do machine learning or OOP. To understand those projects you have to already have internalized the “patterns” on how to do either OOP or machine learning, or be in the right moment of your learning curve, in order to be able to extract something from the code.

What I found beneficial from this approach:

Something that I learned the hard way was that good programming is not only about algorithms and syntax: it is also about structure and organization. And this approach will give you a lot of information about that.
It helps you break the code apart into functional operations. You adopt a “divide and conquer” approach to studying code.
Even if you are not visualizing the algorithms, you learn algorithms. Why? Because the approach forces you to understand the code. In order to find those functional operations, you will find yourself forced to study what some sections of the code are doing. So you will have to study more code.
You learn by comparison. That is an interesting by-product: once you have found different implementations for a similar functional operation, you learn by their differences. The diagrams will then guide you to the sections of the code that are solving that specific problem you are interested in and you’ll be able to compare it within the context of a larger codebase.
The diagrams acts as mnemotechnical artifacts to remember pieces of code. You can use those diagrams to recall a piece of code that was interesting to you, and then you’ll be able to find it more easily than by having to go through the whole code again.

What I found more interesting about this approach is the numerous questions that came to my mind during and after doing the analyses:

Why did the author follow this approach?
What drove their decisions?
How could I better organize it if I worked on it?
Which techniques would I like to combine?
What should I avoid for this project?

And so on.

Another effect was the feeling that I could now easily recognize the same “template” in other projects without having to make the diagrams. It starts to be more natural.

If you feel you want to implement this approach next time you come across several codebases you want to compare, I recommend you do the following:

Don’t stick only to visuals. Combine this with other tools. This is just one part of the whole process. For example, use AI to get a textual description of the code and use the diagrams to visualize the flow.
Always go to the code as it is the “source of truth”. You (or AI, if you’re using it) might have gotten it wrong at certain points, so always check.
Better to compare code examples that are at your level or just a bit higher, and be prepared to challenge yourself by studying new concepts. For example, if you have just the fundamentals of OOP clear in your head but you haven’t started to work on it, find simple examples at your current level and a few more made in OOP that solve similar problems and compare the approaches. I ensure you that you will start finding the patterns.
Come up with questions. The analysis might reveal structures and workflows and help you get into new programming techniques, but it won’t tell you if those structures or techniques were the “right” solution. You have to investigate more from that point. Then you can compare theory with practice. And then you will come up with more questions!
Select projects that are not subject to change.
Don’t worry about how old the projects are. Syntax is not what you are looking to learn from this analysis. It is code structure, organization, and logic. The “map in the mind of the developer”.
Keep it real. If your goal is to learn to code and your time is limited, bear in mind that this kind of analyses will take extra time. It won’t result in concrete code either. It might be good planning for analyzing new codebases at a high level of generalization. But even if it’s too general, I assure you that the time you devote to it will be worthy.

How to Talk to Any Database Using AI – Build Your Own SQL Query Data Extractor

Prankur Pandey — Wed, 08 Jan 2025 21:52:12 +0000

Recently, I took a break from writing to focus on my exams. During this time, I had an interesting experience: I had the chance to explain SQL (Structured Query Language) to my peers. While exploring SQL in-depth, I encountered a common frustration: writing SQL queries to fetch specific data from a database.

This sparked an idea. What if I could build a tool where I didn’t have to write SQL queries manually? Instead, I could type in plain, natural English and let the database do the heavy lifting for me.

Given that we live in the era of AI, leveraging artificial intelligence was the only way to turn this vision into reality.

In this tutorial, I’ll walk you through creating an AI-powered SQL query data extractor. This tool will enable you to fetch data from a database effortlessly, without writing a single line of SQL code.

Prerequisites & Tools

In this tutorial, we’ll build an AI-powered SQL query data extractor tool. It’ll allow us to interact with a database using natural language, like plain English, and receive the same results as if we had written SQL queries.

Here’s an overview of the tools we’ll use to create this cool app:

Database

The database is a critical component where we’ll store data and later extract it for our AI model to use when performing NLP operations. Instead of hosting a database locally, I chose a cloud-based free database that allows data extraction via REST APIs. For this project, I opted for restdb.io because it offers seamless SQL database provisioning and supports REST APIs.

AI Agent

An AI Agent will act as the intermediary between the database and the AI model. This agent will manage the AI model’s operations and facilitate seamless communication. For this, I am using CopilotKit, which simplifies the integration process.

AI (LLM) Model

The AI model translates plain English queries into SQL queries. For this, I am using GroqAI, which supports various popular AI models and provides the flexibility needed for this project.

Next.js

To develop a web application that supports both frontend and backend functionalities, I chose Next.js. It’s an ideal framework for building robust, scalable web apps with server-side rendering capabilities.

Deployment

For deployment, you can choose any service. I prefer Vercel, as it integrates seamlessly with Next.js and is free for hobby projects.

By combining these tools, we’ll build a powerful, user-friendly application that effortlessly bridges natural language and SQL databases.

What We’ll Do Here:

These are the steps we’ll follow in this tutorial to build our app:

Step 1 – Set Up the Database: Either set up the database locally, deploy it, and access it, or use an online database tool that allows data access and extraction via REST APIs.

Step 2 – Obtain Cloud API Keys: Get the necessary API keys for your AI model to enable seamless integration.

Step 3 – Build a Web App: Create a web application and set up the backend to integrate CopilotKit. Configure it within the app for optimal functionality.

Step 4 – Train CopilotKit on Your Database: Provide your database’s data to CopilotKit. It will read and understand the data to facilitate natural language processing.

Step 5 – Integrate CopilotKit Chat: Add the CopilotKit chat interface into your application and configure it to ensure smooth operation.

Step 6 – Test Locally: Test the app on your local machine to identify and fix any issues.

Step 7 – Deploy the App: Once everything is working as expected, deploy the application to a hosting platform.

How Does the App Work?

Have you ever wondered how writing plain English could allow you to fetch data from a SQL database?

The magic lies in CopilotKit. It lets you create AI-powered copilots that can perform operations on your applications. Think of CopilotKit as your personal AI assistant or chatbot. So how does it work?

Well, first we have CopilotKit which serves as our chatbot powered by advanced AI models.

Then when you provide data to the chatbot, it uses that data to train itself, building an understanding of your database structure and content.

Finally, when a natural language query (like "Who is using this email address?") is inputted, the AI model processes it, translates it into a corresponding SQL query, and retrieves the desired data from the database.

With CopilotKit’s powerful AI capabilities, your application can seamlessly bridge natural language and SQL, making database interactions more intuitive.

How to Set Up Your Tools

Now we’ll go through everything you need to set up the project.

1. Install Next.js and dependencies:

First, you’ll need to create a NextJS app. Go to the terminal and run the following command:

npx create-next-app@latest my-next-app

Replace my-next-app with your desired project name.

Navigate to the project folder:

cd my-next-app

Start the development server:

npm run dev

Open your browser and navigate to http://localhost:3000 to see your Next.js app in action.

2. Install CopilotKit and dependencies

Go to the project root folder through the terminal and run the below command. It will install all the important CopilotKit dependencies and other important packages like dotenv and Axios.

npm install @copilotkit/react-ui @copilotkit/react-core dotenv axios

The CopitlotKit dependency is solely for handling CopilotKit operations and configurations.
The Dotenv dependency is used to handle environment variables as we have to keep important keys in the project, such as environment variables.
Axios is for handling the API calls.

3. Set Up the Database

Visit RestDB.io and either login or create an account.

Above you can see the login page for RestDB.io you can either log in if you already have an account or create a new account .

Once logged in you will redirected to this page. There you’ll see the button to create a new database.

When you click on the Create New button, a pop will appear. There, you’ll have to enter the database name as shown in the image below:

When you enter the database name, then click “Go”. I have put demosql as the database name. At this point, you’ll get your newly created database link as shown in the image below:

Now Click on the database URL it will take you to this page shown in the image :

Now it is time to make an API Key for accessing the database. To do this, click on Settings and it will take you to a new page shown below:

On this page click on the Add New button it will open a pop up shown below in the image:

Now you can configure your API actions here like GET, POST, PUT, and DELETE, name it whatever you want, and save it. Your database is now ready to interact via the REST API.

Copy the database URL and API KEY and put it into the .env file.

You can add tables, define the schema with columns and data types (for example, VARCHAR, INTEGER), and populate data manually or via uploads (Excel, CSV, or JSON). For this project, we’ve added 21 records.

4. Set Up the LLM for Action:

This part is pivotal for the project, as we’re setting up the LLM (Large Language Model) to handle the conversion of NLP (plain English) queries into SQL queries.

Numerous LLMs are available in the market, each with its strengths. While some are free, others are paid, which made selecting the right one for this project a challenge.

After extensive experimentation, I chose the Groq Adapter because:

It consolidates various LLMs under a single platform.
It provides access through a unified API key.
It’s compatible with CopilotKit.

How to Set Up Groq Cloud

To get started with Groq Cloud, visit its website and either login if already have an account or create a new account if you’re new. Once logged in, navigate to the Groq Dashboard.

This is the homepage of groq cloud:

Once logged in, a new page will open that’ll look like this:

As you can see, the sidebar has an API Keys link. Click on it, and it will open a new page as shown in the image below. You can also select any LLM of your choice which is given at the top right before the view code option.

Here, click on the Create API Key button it will open a pop up like you see below. Just enter the name of your API key and click on Submit it will create a new API key for you. Then copy this API key and paste it inside your .env file.

To enable seamless access to various LLMs on Groq Cloud, generate an API key by going to the Groq API Keys section. Create a new API key specifically for the LLM, ensuring that it is properly configured.

With the LLM set-up and all components ready, you are now prepared to build the project.

Structure and Features of the App

We will approach this project in a straightforward way, focusing on simplicity and functionality. The primary goal is to create a basic webpage that allows us to:

Verify if our API calls were successful.
View the data received from the API.
Interact with the CopilotKit chatbot integrated into the front end.

Webpage Structure

Since we have already set up the Next.js app, the next step is to build a minimalistic webpage comprising:

Header Section: Displays the title of the application.
Main Area:
- Tables: Show the data fetched from the database.
- Status Indicators: Show the status of API calls and database operations. If there are any issues, such as API or database failures, errors will be displayed in red text for clarity.

Key Features

Error Handling: Any failures, such as API or database issues, will be clearly marked with red text for immediate visibility.
Data Presentation: For demonstration purposes, the entire database will be displayed in neatly structured tables.
CopilotKit Chatbot Integration: This chatbot will be configured to allow natural language interactions with the database. The blue-colored ball on the page represents the CopilotKit chatbot. This chatbot is the key interface for interacting with the database.
- Using natural language queries, we can ask questions about the database data.
- The chatbot processes these queries, converts them into SQL queries, and fetches the results seamlessly.

The frontend will look something like this:

How to Build the Back End

Before we start building the back end, you’ll need to put all important credentials into your .env file which will look something like this:

NEXT_PUBLIC_COPILOTKIT_BACKEND_URL=http://localhost:3000/api/copilotkit
NEXT_PUBLIC_GROQ_CLOUD_API_KEY=
NEXT_PUBLIC_RESTDB_API_KEY=
NEXT_PUBLIC_RESTDB_BASE_URL=https://demosql-fdcb.restdb.io/rest/demo-data

So what are all these? Let’s go through them one by one:

NEXT_PUBLIC_COPILOTKIT_BACKEND_URL=http://localhost:3000/api/copilotkit: This specifies the base URL for the CopilotKit backend API.
- The NEXT_PUBLIC_ prefix makes this variable accessible both on the server side and in the client-side code of a Next.js application.
- The value http://localhost:3000/api/copilotkit indicates the API is running locally during development.
NEXT_PUBLIC_GROQ_CLOUD_API_KEY=: This variable is intended to store an API key for a GROQ Cloud service. GROQ Cloud could be related to querying or data processing you will have to paste your own Groq API key.
- The variable is empty, indicating the API key is not set yet. It will likely need to be filled in with the appropriate value before the application can access the GROQ Cloud service.
NEXT_PUBLIC_RESTDB_API_KEY=: Intended to hold the API key for accessing a RESTdb service. You will have to paste your own Groq API key.
- RESTdb is a database service that provides APIs for database interactions.
- The variable is also empty, meaning the key must be filled in with a valid API key for the application to authenticate and interact with the RESTdb service.
NEXT_PUBLIC_RESTDB_BASE_URL=https://demosql-fdcb.restdb.io/rest/demo-data: Defines the base URL for interacting with the RESTdb database. This URL will be created when you make your database. Here, I have given the URL of my database.
- The value https://demosql-fdcb.restdb.io/rest/demo-data points to a specific RESTdb database endpoint called demo-data.
- This could be the endpoint where the application fetches or manipulates demo data for testing or development.

We have successfully added the environment variables to our project. Now, it’s time to configure the CopilotKit API backed.

How to Configure the CopilotKit Back End

Open your Next.js app in any code editor – I prefer VSCode – and go to the root folder, which looks like this:

Inside the app folder, make a new folder called api. Inside the API folder, make another folder called copilotkit. Then in there, make a new file called route.js and inside the file paste this code:

import {
  CopilotRuntime,
  GroqAdapter,
  copilotRuntimeNextJSAppRouterEndpoint,
} from "@copilotkit/runtime";

import Groq from "groq-sdk";

const groq = new Groq({ apiKey: process.env.NEXT_PUBLIC_GROQ_CLOUD_API_KEY });
console.log(process.env.NEXT_PUBLIC_GROQ_CLOUD_API_KEY);
const copilotKit = new CopilotRuntime();

const serviceAdapter = new GroqAdapter({
  groq,
  model: "llama-3.1-70b-versatile",
});

export const POST = async (req) => {
  const { handleRequest } = copilotRuntimeNextJSAppRouterEndpoint({
    runtime: copilotKit,
    serviceAdapter,
    endpoint: "/api/copilotkit",
  });

  return handleRequest(req);
};

Here’s a detailed explanation of each part:

This code defines a server-side handler for a Next.js API route using CopilotKit and Groq SDKs. It sets up a runtime environment to process requests to a specified endpoint.

1. Imports:

import {
  CopilotRuntime,
  GroqAdapter,
  copilotRuntimeNextJSAppRouterEndpoint,
} from "@copilotkit/runtime";

import Groq from "groq-sdk";

CopilotRuntime and GroqAdapter: These are classes from the CopilotKit library used to set up and configure the runtime environment and adapters for AI-based services.
- CopilotRuntime: A runtime environment to manage the CopilotKit operations.
- GroqAdapter: Adapts and connects a Groq service (used for querying or data processing) with CopilotKit.
copilotRuntimeNextJSAppRouterEndpoint: A utility function to create a handler for a Next.js App Router API endpoint that integrates CopilotKit.
Groq from "groq-sdk": A library for interacting with Groq services is initialized here for querying or processing data.

2. Initialize Groq:

const groq = new Groq({ apiKey: process.env.NEXT_PUBLIC_GROQ_CLOUD_API_KEY });
console.log(process.env.NEXT_PUBLIC_GROQ_CLOUD_API_KEY);

Groq Initialization:
- The Groq an object is created with an API key (NEXT_PUBLIC_GROQ_CLOUD_API_KEY) fetched from environment variables.
- This key authenticates the app with the Groq Cloud service.
console.log(process.env.NEXT_PUBLIC_GROQ_CLOUD_API_KEY): Logs the API key to the server console. Note: Avoid logging sensitive data in production to ensure security.

3. Initialize CopilotKit Runtime

const copilotKit = new CopilotRuntime();

CopilotRuntime Initialization: Creates an instance of CopilotKit's runtime environment to manage CopilotKit's features and services.

4. Configure Service Adapter

const serviceAdapter = new GroqAdapter({
  groq,
  model: "llama-3.1-70b-versatile",
});

GroqAdapter:
- Configures an adapter to connect CopilotKit with Groq.
- The model parameter specifies the AI model to use. Here, it is "llama-3.1-70b-versatile", a versatile language model with 70 billion parameters.

5. Exported POST Handler

export const POST = async (req) => {
  const { handleRequest } = copilotRuntimeNextJSAppRouterEndpoint({
    runtime: copilotKit,
    serviceAdapter,
    endpoint: "/api/copilotkit",
  });

  return handleRequest(req);
};

Defines a POST handler for a Next.js App Router API endpoint.
Key Components:
1. copilotRuntimeNextJSAppRouterEndpoint:
  - Sets up the handler for the /api/copilotkit endpoint.
  - Takes runtime (CopilotKit) and serviceAdapter (GroqAdapter) as inputs to configure the endpoint's behaviour.
2. handleRequest:
  - A function that processes incoming HTTP requests (in this case, POST requests).
  - This allows the CopilotKit runtime and service adapter to handle requests dynamically.
return handleRequest(req);: Invokes the handler and processes the incoming request (req), returning the appropriate response.

How it all works:

The Groq SDK is initialized with an API key for authentication.
A CopilotKit runtime is set up.
A GroqAdapter connects the runtime to the Groq service with a specified AI model.
The /api/copilotkit endpoint is configured to handle POST requests, pass the requests to CopilotKit's runtime, and return the processed response.

With this setup, you have successfully integrated CopilotKit into your Next.js application. The backend is now fully functional, enabling seamless communication with the database via REST APIs and the CopilotKit interface.

How to Build the Front End

For the front end, we’ll keep it as simple as we can. We just need a few things to get this project done: we need a Header component and a Table component.

Header component: To display the title or description of the application.
Table component: To visualize the data fetched from the database.

To achieve this, we’ll use ShadCN, a popular frontend component library known for its clean design and ease of use.

ShadCN provides pre-built components that help speed up development without compromising on quality. By leveraging this library, we can focus on functionality while ensuring the UI looks polished and professional.

How to Install ShadCN in a Next Project

Run the following command to install ShadCN components:

npx shadcn@latest init

This command:

Initialize ShadCN in your project.
Creates a components folder for storing ShadCN components.
Updates the tailwind.config.js file with required configurations.

You will be asked a few questions to configure components.json:

Which style would you like to use? › New YorkWhich 
color would you like to use as base color? › Zinc
Do you want to use CSS variables for colors? › no / yesadd components

To add specific components, use the following command:

npx shadcn@latest add

For example, to add a table component:

npx shadcn@latest add table

The components folder now contains a ready-to-use button component.

In the frontend, we have a components folder that contains the Table component. This component is responsible for displaying the database data in a structured tabular format.

Apart from the Table component, there are two additional files in the front end. These files serve different purposes and will be integrated later in the project for specific functionalities.

This modular structure ensures the front end remains clean and organized, making it easier to manage and expand as needed.

Let’s explore each file:

Table.jsx: This file is auto-generated by ShadCN when we installed the Table component. It contains the default configuration for the table component provided by the ShadCN library. Do not modify this file, as it is essential for the component’s proper functionality.
Tabledata.jsx: This file is where we populate the table with data fetched from the database through API calls. The Tabledata.jsx file bridges the gap between the backend API and the frontend table display.

Let’s take a closer look at the code:

import {
  Table,
  TableBody,
  TableCaption,
  TableCell,
  TableFooter,
  TableHead,
  TableHeader,
  TableRow,
} from "@/components/ui/table";

export function Tabledata({ data }) {
  return (
    <Table className="text-center">
      <TableCaption className="text-sm text-green-600 font-bold ml-8">
        Live data from database.
      TableCaption>
      <TableHeader>
        <TableRow className="text-center ">
          <TableHead>IdTableHead>
          <TableHead>nameTableHead>
          <TableHead>emailTableHead>
          <TableHead>phone_numberTableHead>
          <TableHead>addressTableHead>
          <TableHead>cityTableHead>
          <TableHead>stateTableHead>
          <TableHead>zip_codeTableHead>
          <TableHead>countryTableHead>
          <TableHead className="text-right">created at TableHead>
        TableRow>
      TableHeader>
      <TableBody>
        {data.map((db) => (
          <TableRow key={db._id}>
            <TableCell className="font-medium text-wrap w-12">
              {db._id}
            TableCell>
            <TableCell className="font-medium">{db.name}TableCell>
            <TableCell>{db.email}TableCell>
            <TableCell>{db.phone_number}TableCell>
            <TableCell className="text-right">{db.address}TableCell>
            <TableCell className="text-right">{db.city}TableCell>{" "}
            <TableCell className="text-right">{db.state}TableCell>
            <TableCell className="text-right">{db.zip_code}TableCell>{" "}
            <TableCell className="text-right">{db.country}TableCell>
            <TableCell className="text-right">{db.created_at}TableCell>
          TableRow>
        ))}
      TableBody>
    Table>
  );
}

This code renders a styled, dynamic table with data passed from a database or API.

Imports: Uses custom table components (Table, TableRow, TableCell, and so on) from @/components/ui/table.
Props: Accepts a data prop, an array of objects representing table rows.
Table Caption: Displays a caption, "Live data from database," styled with Tailwind CSS.
Table Header: Defines column headers such as Id, name, email, and more.
Dynamic Rows: Maps over the data array to generate TableRow elements dynamically, using _id as the unique key.
Data Cells: Displays object fields (_id, name, email, and so on) in TableCell components with custom styles.
Tailwind CSS: Styles applied for alignment, font weight, and spacing.

NLQueryForm.jsx

In this file, we handle the API calls, define CopilotKit actions, and pass the fetched data to the Table component. This file acts as the central logic hub for connecting the backend API, AI actions, and the frontend display.

Key functionalities of NLQueryForm.jsx:

API integration: Fetches data from the database and handles errors or loading states.
CopilotKit actions: Defines AI actions that allow querying and interacting with the database using natural language.
Data passing: Sends the processed data to the Table component for display.

Below is the code:

"use client";
import React, { useState, useEffect } from "react";
import { useCopilotReadable, useCopilotAction } from "@copilotkit/react-core";
import axios from "axios";
import { Tabledata } from "./Tabledata";

function NLQueryForm() {
  const [nlQuery, setNlQuery] = useState("");
  const [data, setData] = useState([]);
  console.log("🚀 ~ NLQueryForm ~ data:", data);
  const [error, setError] = useState("");
  const [loading, setLoading] = useState(true);

  const API_KEY = process.env.NEXT_PUBLIC_RESTDB_API_KEY;
  const BASE_URL = process.env.NEXT_PUBLIC_RESTDB_BASE_URL;
  console.table({ API_KEY, BASE_URL });
  useEffect(() => {
    async function fetchData() {
      if (!API_KEY || !BASE_URL) {
        setError("API configuration is missing");
        setLoading(false);
        return;
      }
      try {
        const response = await axios.get(BASE_URL, {
          headers: {
            "x-apikey": API_KEY,
            "Content-Type": "application/json",
          },
        });
        setData(response.data);
        setLoading(false);
      } catch (error) {
        console.error("Error fetching data:", error);
        setError(
          error instanceof Error ? error.message : "An unknown error occurred"
        );
        setLoading(false);
      }
    }
    fetchData();
  }, [API_KEY, BASE_URL]);

  useCopilotReadable({
    description: "Query database with detailed information",
    value: JSON.stringify(data.slice(0, 25)),
  });
  useCopilotAction({
    name: "fetchData",
    description: "Search and filter data based on natural language query",
    parameters: [
      {
        name: "nlQuery",
        type: "string",
        description: "Natural language search term for database",
        required: true,
      },
    ],

    handler: async ({ data }) => {
      setNlQuery(data);
      return JSON.stringify(data);
    },
  });

  if (loading) return <div>Loading...div>;

  return (
    <div>
      {error && <p style={{ color: "red" }}>{error}p>}
      <div>
        <p className="text-sm text-green-600 font-bold text-center">
          Live data from database.
        p>
        <p className="text-sm text-green-600 font-bold text-center">
          Total Records: {data.length}
        p>
        <Tabledata data={data} />
      div>
    div>
  );
}
export default NLQueryForm;

Here’s a detailed explanation of the NLQueryForm component:

Imports and Dependencies:

Utilizes React for state management (useState) and side effects (useEffect).
Imports axios for HTTP requests.
Imports useCopilotReadable and useCopilotAction from @copilotkit/react-core to integrate CopilotKit functionality.
Imports a custom Tabledata component for rendering data.

Component Setup:

Defines a functional React component NLQueryForm.
Initializes state variables:
- nlQuery: Holds the natural language query input.
- data: Stores fetched data from the API.
- error: Stores any errors that occur during data fetching.
- loading: Tracks the loading state of the component.

API Configuration:

Fetches API keys and base URL from environment variables (NEXT_PUBLIC_RESTDB_API_KEY and NEXT_PUBLIC_RESTDB_BASE_URL).
Logs these values for debugging purposes using console.table.

Data Fetching:

Uses useEffect to fetch data from the API on the initial render.
Makes a GET request to the API using axios with required headers.
Updates data with the response and stops the loading state.
Handles errors by logging them and updating the error state.

CopilotKit Integration:

useCopilotReadable: Exposes a readable description and a slice of the first 25 records of data.
useCopilotAction: Defines a CopilotKit action named fetchData which:
- Accepts a natural language query (nlQuery) as input.
- Updates the nlQuery state and returns it as a string.

Conditional Rendering:

Displays a loading message (Loading...) if loading is true.
Displays an error message in red text if an error occurs.

Rendering:

Shows a message indicating live data and the total record count.
Passes the data state to the Tabledata component for rendering.

Export:

Exports the NLQueryForm component as the default export.

Page.js

Now go to the page.js file inside the app folder and add this code:

  "use client";

  import NLQueryForm from "@/components/ui/nl-query-form";
  import { CopilotPopup } from "@copilotkit/react-ui";

  export default function Home() {
    return (
      <div className="min-h-screen bg-background">
        <header className="bg-primary text-primary-foreground py-6">
          <div className="container">
            <h1 className="text-3xl font-bold">
              Natural Language SQL Query Builder
            h1>
          div>
        header>
        <main className="container py-8">
          <NLQueryForm />
        main>

        <CopilotPopup
          instructions={
            "You are assisting the user as best as you can. Answer in the best way possible given the data you have."
          }
          labels={{
            title: "Popup Assistant",
            initial: "Need any help?",
          }}
        />
      div>
    );
  }

Here’s a simple explanation of the code above:

Client-Side Rendering:
- "use client"; indicates the file is using React's client-side rendering.
Importing Components:
- NLQueryForm is imported from a local component directory to be used in the app.
- CopilotPopup is imported from the @copilotkit/react-ui package for displaying an interactive popup.
Main Function:
- Home is a React functional component that defines the UI for the home page.
Page Layout:
- A full-page container (min-h-screen) with a background color (bg-background) wraps all content.
Header:
- Contains a title with the text "Natural Language SQL Query Builder".
- Styled with a primary background and text colors (bg-primary, text-primary-foreground).
Main Content:
- Renders the NLQueryForm component inside a container with padding (py-8).
Popup Component:
- Adds a CopilotPopup at the bottom with:
  - Instructions: Describes the assistant's role.
  - Labels: Includes a title and initial message for the popup.
Purpose:
- The page is designed to let users interact with a natural language SQL query builder and receive assistance via a popup.

Configuring CopilotKit for the Whole App

This is going to be the last step of building the application. Navigate to the layout.js file and add this code:


import "./globals.css";
import { CopilotKit } from "@copilotkit/react-core";
import "@copilotkit/react-ui/styles.css";
export const metadata = {
  title: "Create Next App",
  description: "Generated by create next app",
};

export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <body>
        <CopilotKit runtimeUrl="/api/copilotkit">{children}CopilotKit>
      body>
    html>
  );

Here’s what’s going on in this code:

Imports:
- ./globals.css: Imports global CSS styles for the application.
- @copilotkit/react-core: Imports the core functionality of CopilotKit.
- @copilotkit/react-ui/styles.css: Includes predefined styles for the CopilotKit UI components.
Metadata:
- The metadata object defines the app's title and description, which are useful for setting meta tags in the generated HTML for SEO and user information.
RootLayout function:
- This function serves as the root layout wrapper for the application. It ensures consistent structure across all pages and integrates the CopilotKit runtime.
Structure:
- The layout returns an element with a lang attribute set to en for English.
- Inside the tag, the CopilotKit component is wrapped around the children prop.
  This setup:
  - Connects the app to the CopilotKit runtime using the API endpoint /api/copilotkit.
  - Provides access to CopilotKit's functionality, such as handling natural language queries, throughout the application.

Some Important Notes

Designing and deploying a database can take various forms, depending on the tools and requirements. For this project, I have chosen the simplest and most accessible approach.

Why CopilotKit?

CopilotKit is a powerful tool that converts NLP queries into actionable backend code. If you have an alternative that works similarly, feel free to use it. It bridges the gap between natural language input and technical execution, making it ideal for projects like this.

Why GroqCloud?

I selected GroqCloud because it’s free and provides access to multiple LLMs with a single API key. While you can opt for alternatives like ChatGPT, note that they may require paid plans. GroqCloud’s versatility and affordability make it perfect for this tutorial.

Database Considerations

The size of your database can vary from very small to enormous. However, interacting with the database depends on the token limits of the LLM you’re using.

Since I’m working with free-tier tools, my focus is on a small database to ensure seamless interactions.

Security Best Practices

Never expose your credentials publicly. Always store sensitive information like API keys in an .env file to keep your project secure.

Future Enhancements

While this tutorial focuses on setting up and querying a database, the potential of CopilotKit extends to CRUD operations (Create, Read, Update, Delete). In my next tutorial, I will demonstrate how to implement full CRUD operations using CopilotKit for a more dynamic and functional application.

Playing with the Database

You can explore the live project via the following link and ask any questions related to the database data: live link .

For a deeper understanding of the code, here’s the GitHub repository link: github .

Also, here’s a screenshot demonstrating its practical use. In this example, instead of writing a plain SQL query like SELECT * FROM demo_data WHERE email = 'riverashannon@lee.com'; to extract the name of the person, we used an NLP query to achieve the exact same result.

Conclusion

I hope you’ve enjoyed building this simple AI chatbot to interact with the database. In this project, we’ve used a simple SQL database, but you can apply this approach to any database as long as you can retrieve the data.

In the future, I plan to implement many new projects involving AI and other tools. AI tools are truly game-changing in the IT field, and I look forward to providing you with more detailed insights and practical implementations of the latest tools emerging in the space.

So this is the end from my side. If you found this article useful, then do share it and connect with me – I am open to opportunities:

Follow Me on X: Prankur's Twitter
Follow me on LinkedIn: Prankur's Linkedin
Look at my Portfolio here: Prankur's Portfolio

How to Create a Meme Generator Using HTML Canvas

Timothy Olanrewaju — Tue, 19 Nov 2024 13:29:03 +0000

We all come across memes almost every day on the internet. Whether you're scrolling through social media or chatting with friends, there's a good chance you'll stumble on a meme, or even share one yourself. A meme can be an image, a video, or gif that is meant to be funny or convey a message in a lighthearted way.

Memes are fun and we all love them. What if I told you that you can create yours from scratch? Well, that is what I’ll be showing you in this article using HTML Canvas. No need for fancy software - just a little code and some creativity to make your own custom memes.

If you are excited about this, let’s jump straight into it!

What You’ll Need

To follow along with this tutorial, you will need:

Basic knowledge of HTML, CSS and JavaScript.
A text Editor (like Visual Studio Code or Sublime Text).
A modern web browser.

Step One: Set Up your Project

Create a folder and create these three files in the folder:

Index.html
Style.css
Script.js

Step Two: HTML Structure

First, let’s create the basic structure of the HTML file. Our structure would include a file upload button for images, a text input for adding captions (both at the top and bottom), buttons to generate and download the meme and a canvas for displaying the image and caption(s).

html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Meme Generatortitle>
  <link rel="stylesheet" href="style.css">
head>
<body>
  <h1>Meme Generatorh1>
  <input type="file" id="imageInput" accept="image/*">
  <div class="controls">
    <input type="text" id="topText" placeholder="Enter Top Text">
    <input type="text" id="bottomText" placeholder="Enter Bottom Text">
    <button id="generate" onclick="generateMeme()">Generate Memebutton>
    <button id="download" onclick="downloadMeme()">Download Memebutton>
  div>
  <canvas id="memeCanvas" width="580" height="450">canvas>

  <script src="script.js">script>
body>
html>

Step Three: Styling with CSS

Next, we apply styling to the HTML elements we just created to make it more appealing and user-friendly. Here, we just apply basic CSS to center the content and add colors to both the background and buttons.

body {
    display: flex;
    flex-direction: column;
    align-items: center;
    font-family: Arial, sans-serif;
    background-color: rgb(121, 121, 170);
    color: white;
}
canvas {
    border: 2px solid #333;
    margin-top: 10px;
}
.controls {
    margin-top: 10px;
}
.controls input, .controls button {
    margin: 5px;
}
#generate{
    background-color: green;
    color: white;
    font-weight: bold;
    padding: 6px;
    border-radius: 3px;
    border: none;
    cursor: pointer;
}
#download{
    background-color: blue;
    color: white;
    font-weight: bold;
    padding: 6px;
    border-radius: 3px;
    border: none;
    cursor: pointer;
}

Here's how our webpage looks in the browser after applying the styling:

Step Four: Add JavaScript to Handle Logic

Now, let’s code the functionalities of our app using JavaScript.

Initialization

First, we need to initialize some important elements that would enable us render our image on the canvas.

const canvas = document.getElementById('memeCanvas');
const ctx = canvas.getContext('2d');
const imageInput = document.getElementById('imageInput');
let uploadedImage = null;

In this code:

canvas: Refers to the HTML element with the ID of memeCanvas. This is where the meme image and text will be drawn.
ctx: While using canvas, there are methods that can be applied that enables for drawing shapes, images and texts on the canvas. We specified a Context-Type of 2d, making the canvas render in 2D context.
imageInput: Refers to an element of type file (with the ID of imageInput) that allows you upload an image.
uploadedImage: A variable to store the uploaded images so it can be drawn on the canvas.

How to Upload Images

Next, we want to be able to choose a particular file, read it and draw the selected image file on the canvas.

Our meme generator will accept only files with a type of image.

imageInput.addEventListener('change', (event) => {
  const file = event.target.files[0];
  const reader = new FileReader();

  reader.onload = (e) => {
    const img = new Image();
    img.src = e.target.result;
    img.onload = () => {
      uploadedImage = img;
      drawImage();
    };
  };

  reader.readAsDataURL(file);
});

In this code:

imageInput.addEventListener('change'): Adds and listens for a change event to the file input field that triggers when the user selects a file.
event.target.files[0]: Accesses the first file the user selects.
FileReader: Reads file data and allows it to be accessed as a URL.
reader.onload: This function is triggered after the file is read. It does the following:
- Creates a new Image object.
- Sets the image’s src property to the file's data URL.
- Waits for the image to load and then:
  - Stores the image in the uploadedImage variable.
  - Calls drawImage() to draw the image on the canvas.

How to Draw the Image and Text Caption

Here, we’ll be drawing the image, fixing the captions inputted by the user on top of the image (overlay), and styling and positioning the text captions.

function drawImage() {
  if (uploadedImage) {
    // Clear canvas and set canvas dimensions to fit the image
    ctx.clearRect(0, 0, canvas.width, canvas.height);
    ctx.drawImage(uploadedImage, 0, 0, canvas.width, canvas.height);

    // Get text values
    const topText = document.getElementById('topText').value;
    const bottomText = document.getElementById('bottomText').value;

    // Set text styles
    ctx.font = '30px Impact';
    ctx.fillStyle = 'white';
    ctx.strokeStyle = 'black';
    ctx.lineWidth = 2;
    ctx.textAlign = 'center';

    // Draw top text
    ctx.fillText(topText, canvas.width / 2, 50);
    ctx.strokeText(topText, canvas.width / 2, 50);

    // Draw bottom text
    ctx.fillText(bottomText, canvas.width / 2, canvas.height - 20);
    ctx.strokeText(bottomText, canvas.width / 2, canvas.height - 20);
  }
}

In this code:

ctx.clearRect(0, 0, canvas.width, canvas.height): Clears the canvas so it can be redrawn.
ctx.drawImage(): Draws the uploaded image on the canvas and stretches it to fit the set dimensions.
topText and bottomText: Captures the user’s input from two text fields – and .

Text styling:

ctx.font: Sets the font style.
ctx.fillStyle: Sets the fill color for the text.
ctx.strokeStyle: Sets the outline color for the text.
ctx.lineWidth: Sets the thickness of the outline.
ctx.textAlign: Ensures text is centered relative to the X-coordinate.
ctx.fillText() and ctx.strokeText():
- Draws the text at specified positions.
- canvas.width / 2 ensures text is horizontally centered.
- 50 and canvas.height - 20 define vertical positions for the top and bottom text.

You can customize the text styling to your liking.

How to Generate the Meme

Next, we’ll trigger the function that generates the meme by drawing user-provided text on the image.

function generateMeme() {
  drawImage();
}

The code above calls the drawImage function to ensure that the canvas is updated with the image and user-entered text.

How to Download the Meme

Finally, we want to be able to download our meme as an image into our device. Here is how we can achieve that:

function downloadMeme() {
  const link = document.createElement('a');
  link.download = 'meme.png';
  link.href = canvas.toDataURL();
  link.click();
}

In this code:

document.createElement('a'): Creates a temporary element.

link.download = 'meme.png': Sets the file name for the downloaded meme (every meme you download will carry the name of meme.png – you can change it if you wish to).
link.href = canvas.toDataURL(): Converts the canvas content into a Data URL.
link.click(): Simulates a click on the link, triggering the download.

With this, we now have a fully functional meme generator.

Full JavaScript Code

const canvas = document.getElementById('memeCanvas');
const ctx = canvas.getContext('2d');
const imageInput = document.getElementById('imageInput');
let uploadedImage = null;

// Load the image onto the canvas
imageInput.addEventListener('change', (event) => {
  const file = event.target.files[0];
  const reader = new FileReader();

  reader.onload = (e) => {
    const img = new Image();
    img.src = e.target.result;
    img.onload = () => {
      uploadedImage = img;
      drawImage();
    };
  };

  reader.readAsDataURL(file);
});

// Draw image and text on canvas
function drawImage() {
  if (uploadedImage) {
    // Clear canvas and set canvas dimensions to fit the image
    ctx.clearRect(0, 0, canvas.width, canvas.height);
    ctx.drawImage(uploadedImage, 0, 0, canvas.width, canvas.height);

    // Get text values
    const topText = document.getElementById('topText').value;
    const bottomText = document.getElementById('bottomText').value;

    // Set text styles
    ctx.font = '30px Impact';
    ctx.fillStyle = 'white';
    ctx.strokeStyle = 'black';
    ctx.lineWidth = 2;
    ctx.textAlign = 'center';

    // Draw top text
    ctx.fillText(topText, canvas.width / 2, 50);
    ctx.strokeText(topText, canvas.width / 2, 50);

    // Draw bottom text
    ctx.fillText(bottomText, canvas.width / 2, canvas.height - 20);
    ctx.strokeText(bottomText, canvas.width / 2, canvas.height - 20);
  }
}

// Generate meme by drawing text on the uploaded image
function generateMeme() {
  drawImage();
}

// Download the meme as an image
function downloadMeme() {
  const link = document.createElement('a');
  link.download = 'meme.png';
  link.href = canvas.toDataURL();
  link.click();
}

Steps on Creating your Meme on Meme Generator

Click on the Browse button and select a particular image.
Enter text into either of the two input types – labelled Top and Bottom Text.
Click on Generate Meme button to create your meme.
Click on Download Meme to download your generated meme.

This is the meme generator in full action with the steps demonstrated:

Final Results

Here are two memes created by our meme generator.

Pretty cool right?

Now, you can try it out and create your own viral meme!

For more programming articles and posts, you can follow me on X or connect with me on LinkedIn.

See you in the next one!

How to Build a Counter Button with React, TailwindCSS, and TypeScript

Devin Lane — Wed, 10 Jul 2024 14:41:14 +0000

How can you keep track of the number of times a user clicks a button? How are the hearts on Instagram or the likes on Facebook counted?

In this tutorial, we will build a button that tracks the number of times a button has been clicked. Along the way, you will learn some fundamental concepts in React such as components, JSX, passing props between components, and managing state with hooks. You will also get small introductions to Tailwind and TypeScript.

This tutorial builds upon examples and concepts outlined in the "Learn" section of the React documentation, which you can find here.

Prerequisites

Basic familiarity with JavaScript, such as working with variables, functions, arrays, and objects.
Basic familiarity with CSS and HTML.
Basic familiarity with the command line.
Node installed.
A code editor of your choice (I'll be using Visual Studio Code here)

How to Build the Counter Button
How to Refactor the Project
Two Components with Independent and Shared State
How to Add Both Pairs of Buttons to our Website
How to Deploy the Site to Netlify

Chapter 1: How to Build the Counter Button

What is React?

Before we dive in, let's define React. React is a JavaScript library for creating user interfaces out of pieces called components. Components are JavaScript functions that can receive and display data interactively to your users.

Project setup

We're going to use Next.js for our local React setup.

Within the directory you'd like to store this project, open your terminal and execute the following command:

npx create-next-app@latest

Name your project however you like, and answer the commands as follows:

What is your project named? react-counter-button
Would you like to use TypeScript? Yes
Would you like to use ESLint? Yes
Would you like to use Tailwind CSS? Yes
Would you like to use `src/` directory? No
Would you like to use App Router? (recommended) Yes
Would you like to customize the default import alias (@/*)? No

Now let's cd into our project directory

cd react-counter-button

And run the project in Visual Studio Code:

code .

Note: if you don't have the code command in your PATH, you can press ⇧⌘P (Ctrl+Shift+P on Windows/Linux) and type in 'Shell Command: Install 'code' command in PATH'. Alternatively, you can drag the folder onto the Visual Studio Code icon in MacOS. Or, within Visual Studio Code, you can select File -> Open, and find "react-counter-button", or the name of your project.

In your terminal run:

npm run dev

Open your browser to localhost:3000 and you should see the following page:

Next.js boilerplate

We now have the project up and running. Back over in our code editor, we can begin the work.

Remove boilerplate

In app/page.tsx, let's delete most of the boilerplate code except the two main tags. Then let's add a title for our project in an h1 tag in between the main tags. Our code should look like this:

export default function Home() {
    return (
        <main className="flex min-h-screen flex-col items-center justify-between p-24">
            <h1>React Counter Buttonh1>
        main>
    );
}

Here's what we should now see:

Initial state of our project

Writing our first component

Let's create our first component. A React component is a function that returns markup. Below and outside of the scope of our Home function, let's write the following:

function Button() {
    return <button>I have been clicked X timesbutton>;
}

Here we have a function Button that returns some markup in JSX. JSX looks a lot like HTML, but it can display dynamic content, and has stricter rules than HTML. You can learn more about JSX in the React docs here.

The Button function must be uppercase to be recognized as a valid React component. This contrasts it with an HTML tag, which is lower case.

You'll notice that we still see no change on our webpage – we need to render this component in order to see it on the screen.

We can use our Button component as if it were an HTML tag we created. If we nest the Button component within the Home component, we should see it on the screen:

export default function Home() {
    return (
        <main className="flex min-h-screen flex-col items-center justify-between p-24">
            <h1>React Counter Buttonh1>
            <Button />
        main>
    );
}

function Button() {
    return <button>I have been clicked X timesbutton>;
}

Rendering the Button component (with less than ideal CSS)

Styling our first component with Tailwind

You'll notice the button is on the bottom of the screen. This is because the styles on main include justify-between in the flex-col direction. If we remove justify-between we should see this:

Improving the CSS of the initial state of our application

You can read more about aligning items in a flexbox from MDN here.

You'll also notice that the button is un-styled. This is because Tailwind removes default styling on buttons as a part of their "preflight" styles. If you're curious to see where these styles come from, you can open node_modules/tailwindcss/src/css/preflight.css and check out ~line 193 (permalink on GitHub here):

/*
1. Correct the inability to style clickable types in iOS and Safari.
2. Remove default button styles.
*/

button,
[type='button'],
[type='reset'],
[type='submit'] {
  -webkit-appearance: button; /* 1 */
  background-color: transparent; /* 2 */
  background-image: none; /* 2 */
}

We're not going to change the styles within node_modules – instead we'll add our own styling to the Button component. One of the benefits of Tailwind is that our CSS is co-located with our JavaScript, making quick changes to styles easier than opening a separate stylesheet file.

Let's make the following changes:

export default function Home() {
    return (
        <main className="flex min-h-screen flex-col items-center p-24 gap-4">
            <h1>React Counter Buttonh1>
            <Button />
        main>
    );
}

function Button() {
    return (
        <button className="bg-blue-500 hover:bg-blue-700 rounded text-white font-bold px-4 py-2">
            I have been clicked X times
        button>
    );
}

We've added styles to our button, and we've also added a gap-4 to our main parent flex box to provide a space between the h1 and the button. (You can read more about the CSS property "gap" in the MDN here.) We should now see this:

Viewing our styled Button component

Wait, but what is Tailwind?

Now that we've styled our button component and spaced the items out, let's reflect on what Tailwind is, and what it provided for us. Tailwind is a CSS framework that provides a set of "utility" classes that we can use to style each element.

But what is a utility class? You'll see that to style our button, we added classes such as bg-blue-500 – which corresponds to setting the CSS background-color property to blue, and rounded – which corresponds to border-radius: 0.25rem.

Each class is defined according to its utility: changing the background color, the border radius, and so on. Through adding these utility classes to our elements, we arrive at our desired styles.

Tailwind sits in contrast to other frameworks, such as Bootstrap, that provide predefined classes for elements such as buttons. In Bootstrap, we would add a class of btn to achieve a styled button. And of course, with standard CSS we would likely add a custom class (perhaps called button) to our element and create CSS rulesets in a separate stylesheet.

Returning to our project, so far we've set up a React project using Next.js, created our first React component, and styled our button using Tailwind. How do we introduce the counter functionality?

How to add state

In order to display the number of times a button has been clicked, we need to use an event handler, and we need a way to manage state.

State is component-specific memory. In our example, this is how the button will remember how many times it has been clicked. Using a special React function "hook", we trigger a re-render and retain the data across renders – the [useState](https://react.dev/reference/react/useState) hook is provided by React for this purpose.

At the top of our page.tsx, let's import useState:

import { useState } from "react"

and within our Button component, let's add the following:

function Button() {
  const [count, setCount] = useState(0)
    return (
        <button className="bg-blue-500 hover:bg-blue-700 rounded py-2 px-4 text-white font-bold">
            I have been clicked X times
        button>
    );
}

Let's unpack what we have here:

We're using the destructuring assignment to get the values of count and the function setCount from useState. The convention is to name these two values something and setSomething, though we could name them anything.
The argument to useState is the initial value of our state variable. Here we've set it to 0.
count is our current state.
setCount is the function that updates our state and triggers a re-render.

However, if you click save you'll see the following error in your terminal and in your browser:

You're importing a component that needs useState. It only works in a Client Component but none of its parents are marked with "use client", so they're Server Components by default.
Learn more: https://nextjs.org/docs/getting-started/react-essentials

   ╭─[/[...your project path]/src/app/page.tsx:1:1]
 1 │ import { useState } from "react";
   ·          ────────
 2 │ 
 3 │ export default function Home() {
 4 │     return (
   ╰────

Maybe one of these should be marked as a client entry with "use client":
  ./src/app/page.tsx

This is due to Next.js's use of React Server Components, which you can learn more about here. React Server Components is a large topic, but the bottom line is that, by default, components are Server Components in Next.js and useState only works in a Client Component. If we write the "use client" directive at the top of our page.tsx, we resolve the error.

How to Evaluate JavaScript within JSX

If we click the button, we still don't see the numbers update. This is because we need a way to interpolate (or evaluate) JavaScript within our JSX markup. Enter the curly braces: {}.

We can use curly braces to "escape" into JavaScript from within JSX markup. This way we can evaluate JavaScript expressions (such as adding to a counter) and dynamically display data in our components. Here's what we'll do:

function MyButton() {
    const [count, setCount] = useState(0);
    return (
        <button className="bg-blue-500 hover:bg-blue-700 rounded py-2 px-4 text-white font-bold">
            I have been clicked {count} times
        button>
    );
}

We have added {count} to evaluate the value of count from useState within our button. We should see the following:

Displaying data in JSX with curly braces {}

We see a 0 – this comes from the count variable that we destructured from our useState hook, which we initially set to 0. We've successfully interpolated the JavaScript within our JSX markup!

Event handling

You'll notice that if we click the button, still nothing happens. How do we get the number to increment when we click it?

For this, we'll make use of an event handler function as well as the setter function (which we named setCount) that we get from useState:

function MyButton() {
    const [count, setCount] = useState(0);

    function handleClick() {
        setCount(count + 1);
    }
    return (
        <button className="bg-blue-500 hover:bg-blue-700 rounded py-2 px-4 text-white font-bold">
            I have been clicked {count} times
        button>
    );
}

What we've done here is add a function handleClick to update the state of the count variable. The convention is to name event handler functions handle followed by the name of your event (for example, handleClick).

[setCount](https://react.dev/reference/react/useState#setstate) is a special set function returned by useState that will update the state of the count variable to whatever we pass in as an argument. For example, we could call setCount(2), and it would update count to 2. setCount(7) would set it to 7, and so on.

We are calling setCount(count + 1), which evaluates to setCount(0 + 1), because the initial value of count is 0. Upon the next click, count will be 1, so we'd be calling setCount(1 + 1), and the next click would call setCount(2 + 1) and so on.

This allows us to update the counter with every click. But, if you click, you'll notice that still nothing happens – why? Perhaps take a moment to try to figure this out for yourself before reading on to help the concept stick even better.

How to Pass an Event Handler as a Prop to Your JSX

Looking at our code, there is no relationship between the user clicking the button, and the handleClick function. We need to pass the handleClick event handler to the onClick property on the button! Let's add that here:

function MyButton() {
    const [count, setCount] = useState(0);

    function handleClick() {
        setCount(count + 1);
    }
    return (
        <button
            onClick={handleClick}
            className="bg-blue-500 hover:bg-blue-700 rounded py-2 px-4 text-white font-bold"
        >
            I have been clicked {count} times
        button>
    );
}

Notice how we haven't said onClick={handleClick()}. We aren't calling the function ourselves here – we are instead passing it down. This is an important distinction, as React calls the function for us when the user clicks the button, instead of it firing immediately.

You can learn more about passing props to components in the React docs here.

Our working project

Try it out now, the button works!

You now have a button that updates its count when you click it. This shows usage of interpolating JavaScript within JSX using curly braces, creating your own component and nesting it within other components, using state and hooks within React, as well as working with Next.js and Tailwind. Congratulations!

Our working project

Here would be a good point to commit our changes using Git. You can close the current terminal process by pressing ctrl + c, and then type in git add ., followed by git commit -m "counter button" or some other message that is meaningful.

Chapter 2: How to Refactor the Project

Moving our component to another file

As our project sits, all the code is within app/page.tsx. What if we wanted to add another component, or several? Over time, our page.tsx would get large and difficult to read.

Instead, we can break our components up into their own files to help with readability as well as modularity (reusing the component in multiple different places).

Let's start by creating a folder components at the root of our project to store our components. Inside components, create a file called button.tsx. Then, within app/page.tsx cut (copy and then delete) the entire Button function component and paste it within components/button.tsx.

components/button.tsx should look like this:

function Button() {
    const [count, setCount] = useState(0);

    function handleClick() {
        setCount(count + 1);
    }
    return (
        <button
            onClick={handleClick}
            className="bg-blue-500 hover:bg-blue-700 rounded text-white font-bold px-4 py-2"
        >
            I have been clicked {count} times
        button>
    );
}

Fix the `useState` import error

You'll likely notice in your code editor that useState(0) has red squiggly lines underneath it. In Visual Studio Code, if you hover over it, you will see an error that says:

Error: cannot find name 'useState'

Why is this? We are using useState but we have not imported the module from React. Adding import { useState } from "react"; to the top of our button.tsx file will fix this error.

If you look at the beginning of the function, you'll see that Button() is underlined with white lines in Visual Studio Code. Hovering over it will show this error. Reflect on why this might be the case – we'll address this later.

Error: 'Button' is declared but its value is never read

Importing and Exporting Components

Let's return to app/page.tsx . You'll see two errors here: one on import { useState } from "react"; and another on

Why wouldn't Button be defined? The issue is that within our app/page.tsx we have no way to access the Button component over in components/button.tsx. We solve this by exporting and importing the appropriate module.

Within components/button.tsx, at the beginning of our function declaration, let's add the keywords export default. The file will look like this now:

You'll notice that our earlier error of 'Button' is declared but its value is never read has gone away, because now the value is being read as a default export.

But what have we done here? What is an export, or a default export? Exporting and importing allows us to modularize JavaScript components into their own sections and use them in others.

There are two types: default exports, and named exports. Each file can have multiple named exports but only one default export. You can read more about importing and exporting components the React documentation here.

Now that we have exported the component from components/button.tsx, we have to import it within app/page.tsx. Visual Studio Code can help with "intellisense" suggestions: at the top of your file if you start typing "Button", it will suggest the correct import with the correct filepath:

Within Next.js we can use this @/ syntax to reference the root of the project. This is a convenience added in case our import is several file layers deep. You can read the examples of the @/ syntax in the Next.js documentation here.

You'll see that our errors have disappeared and the project still works! We haven't added any new features but we have successfully refactored our code to make it more modular, readable, and maintainable.

Here let's follow the same steps to commit our changes, adding a message such as refactor: move button to its own file.

Chapter 3: Two Components with Independent and Shared State

Two Components with Independent State

What if we wanted to have two buttons that can count independently of each other? This will showcase the beauty of React and component-based development implementation will be simpler than building the button from scratch entirely again.

The final change is an opinionated one as I’d rather show something else if there aren’t any users currently assigned to the task.

The Compound Component Pattern Method

Now, for the main event. Start by creating a context which wraps the entire component.

Then we gather all the necessary data and functions that our dropdown and its components will need. This includes things like the list of assigned users, a function to update that list, and whether the dropdown is currently open or not.

With our context set up, it's time to craft the individual components that will make up our dropdown. Each component will interact with the context to access and manipulate the necessary data and functions.

The Header Component

The Close Component

The Assigned List Component

This component displays the list of assigned users, as well as removing users from the list.

The Item Component

This component represents each user and the functionality of adding and removing users from the assigned list.

The Button Component

To combine this component into a singular compound component (compound component), you assign each component to the parent, like so;

Next, import your compound component in your App component as a wrapper component and pass in the appropriate states.

Finally, use the custom hook we created earlier to close the dropdown when you click outside the component.

With this pattern, changing the look of the component is as easy as changing the order in which you render them in their parent. For instance, if you wanted the button first, you simply change the order in the parent wrapper.

This component is also flexible enough to change the layout of elements via props.

Comparison between the Regular and the Compound Component method

Alright, let's take a step back and compare the two approaches we've just explored.

Simplicity and Organization

Flexibility and Customization

Reuse and Maintenance

Additional Information

Conclusion

In the end, both methods have their place in the kitchen – er, I mean, in your code. The regular method is like your trusty old mixing bowl – reliable and familiar, but maybe not the most efficient for every recipe.

The compound component Pattern is like a well-organized kitchen, with everything in its place and ready to go. It might take a bit more setup, but it can make your life a whole lot easier in the long run. So, depending on what you're cooking up, choose the method that suits your taste– and happy coding! 🍰🎨

projects - freeCodeCamp.org

How to Become an Analytical Programmer – Solve the "Rock, Paper, Scissors" Game 5 Ways Using JavaScript & Mermaid.js

How to Read this Article

Here’s what we’ll cover:

Visual Tools for Code Comparison

Why Use System Block Diagrams?

The Use Case-Driven System Block Diagram

What We Are Going to Do

The Code Examples

How to Choose Your Projects

The Scope

The Methodology

How We’ll Build the Diagrams

Our Tool: Mermaid.js

Five Code Examples of Rock, Paper, Scissors

1. “CPC Rock Paper Scissors” by Amit: A project with fireworks animations

Analysis of the Project

Quickly discovering of the start and end of the workflow

The playGame Event Handler

Refinement

Imperative Programming

Finalizing the diagram

2. “Rock paper scissors game using native drag & drop” by Hmz C: A project using the HTML Drag element

Analysis of the Project

Quickly discovering of the start and end of the workflow

IIFE

Refinement

Finalizing the diagram and comparison to previous project

3. “Rock Paper Scissors” by Brad Traversy: A project with a modal and a reset

Analysis of the Project

Quickly discovering of the start and end of the workflow

Refinement

The play event handler as a Controller

Modularity and Separatation of Concerns (SoC)

Procedural Programming

Finalizing the diagram and comparison to previous projects

4. “Rock Paper Scissors OOP” by Damian: A project written in OOP

Analysis of the Project

Quickly discovering the start and end of the workflow

Refinement

OOP Encapsulation

Finalizing the diagram and comparison to previous projects

5. “Recurrent Neural Network – Rock, Paper, Scissors” by Andrew Worcerster: A Project Implementing AI

Analysis of the Project

Quickly discovering of the start and end of the workflow

Refinement

Further Refinement

Finalizing the diagram and comparison to previous projects

Final Thoughts

How to Talk to Any Database Using AI – Build Your Own SQL Query Data Extractor

What we’ll cover:

Prerequisites & Tools

Database

AI Agent

AI (LLM) Model

Next.js

Deployment

What We’ll Do Here:

How Does the App Work?

How to Set Up Your Tools

1. Install Next.js and dependencies:

2. Install CopilotKit and dependencies

3. Set Up the Database

4. Set Up the LLM for Action:

How to Set Up Groq Cloud

Structure and Features of the App

Webpage Structure

Key Features

How to Build the Back End

How to Configure the CopilotKit Back End

How to Build the Front End

How to Install ShadCN in a Next Project

NLQueryForm.jsx

Page.js

Configuring CopilotKit for the Whole App

Some Important Notes

Why CopilotKit?

Why GroqCloud?

Database Considerations

Security Best Practices

The `playGame` Event Handler

The `play` event handler as a Controller

Fix the `useState` import error