DEV Community: Alan Buenrostro

🛠️ Simple Shallow Type Checker in JavaScript

Alan Buenrostro — Thu, 10 Jul 2025 23:26:24 +0000

JavaScript's dynamic typing is both a blessing and a curse. Sometimes you just want a lightweight way to validate the shape and types of an object — without pulling in a full schema validator or TypeScript.

Here's a simple utility function for shallow type checking using plain JavaScript:

📦 The Code

/**
 * @typedef {Object} TypeDefinitionItem
 * @property {string} keyName - The name of the key to check on the object.
 * @property {string} type - The expected JavaScript type of the value (e.g. "string", "number", "boolean").
 */

/**
 * @typedef {TypeDefinitionItem[]} TypeDefinition
 */

/**
 * @description A shallow type checker. Verifies that an object's key-value pairs match the expected type definitions.
 * @param {TypeDefinition} typeDefinition - An array of type definition items specifying keys and expected types.
 * @param {Object} objectToCheck - The object to validate against the type definitions.
 * @returns {boolean} Returns true if all keys exist and have the correct type, otherwise false.
 */
export function shallowTypeCheck(typeDefinition, objectToCheck) {
    try {
        for (let property of typeDefinition) {
            // Check if key exists in the object
            const keyExists = objectToCheck.hasOwnProperty(property.keyName);
            if (keyExists) {
                const typeCorrect = typeof objectToCheck[property.keyName] === property.type;
                if (!typeCorrect) {
                    return false;
                }
            } else {
                return false;
            }
        }
        return true;
    } catch (e) {
        return false;
    }
}

🧪 Example Usage

const typeDef = [
  { keyName: 'name', type: 'string' },
  { keyName: 'age', type: 'number' },
  { keyName: 'isAdmin', type: 'boolean' }
];

const user = {
  name: 'Alice',
  age: 30,
  isAdmin: false
};

console.log(shallowTypeCheck(typeDef, user)); // true

🔴 What if the types don't match?

const invalidUser = {
  name: 'Bob',
  age: 'thirty', // ❌ should be a number
  isAdmin: false
};

console.log(shallowTypeCheck(typeDef, invalidUser)); // false

🚫 Limitations

It's shallow: it doesn't check nested objects.
It doesn't support complex types like arrays, classes, or custom validators.
For more robust validation, consider libraries like zod, yup, or io-ts.

✅ When to Use This

This is useful when:

You want lightweight validation with no dependencies.
You’re working in a Node.js project without TypeScript.
You need quick runtime guards for input objects.

Deny AI, Embrace You. - An AI Deconstuction

Alan Buenrostro — Thu, 19 Jun 2025 03:16:28 +0000

Deconstructing AI -

a gift for all the junior devs with imposter syndrome

Today we are going to deconstruct the notion that you or any other individual needs AI to succeed, here are some common thought patterns that a diverse amount of individuals may have:

If I don’t use ai I’ll somehow fall behind! (or would i?)
I wouldn't be the same programmer without ai (or would i?)
AI makes me write code more efficiently. (or does it?)

News flash you've been lied to.

Have you ever wondered how the first ChatGPT model was produced? Did they somehow use a time machine to create a rip though the fabric of reality and prompt an o3 model in the future, no, it was produced with a little bit of human ingenuity and the good old-fashioned human brain, truth be told you have the most powerful computer that open AI is so desperately trying to replicate and its right in your head, It belongs to you, not in some buzzing computer cluster, that used to be a storage warehouse for pets.com. let’s begin by reviewing these notion's and why its so easy to fall into from a marketing level.

Companies have to lie (sort of)

One vital thing to understand is the incentive behind lying and or exaggerating a product such as an LLM. These companies have to lie as a means of survival, especially since LLM's as a technology are still very much in its infancy, AI companies such as OpenAI , google and sonnet, all have an incentive to exaggerate the effectiveness of their products, not only to you but also to their shareholders, all for the benefit and growth of a company.

Now understanding this, we can begin to see why these companies make so many remarkable claims about their product with little to no evidence. They’re simply in a position that requires them to do so for their self interest.

Its simply marketing, marketing is an effective strategy used for decades to control the perception around your company and its products.

Systems Level Thinking

Refuse Perfection
“There is no minimum requirement for me to strive for perfection — therefore, perfection lies far outside my scope.”

I believe, one of the primary beliefs that keep people constrained to this attachment to ai, is the false notion that ai somehow leads to a more perfect, or effective product. Lets first shatter the illusion of achievable perfection.

Let’s think about this first from a systems level perspective .
A decision tree graph is a node based tree graph that is used to represent a chain of outcomes and decisions leading to a final outcome. For every decision, there is a new set of sequential decisions, the amount of decisions per node grows exponentially. You cannot make a perfect decision on top of every other previous decision in the tree even if you tried to, simply doing so is statically impossible.

This means, that in order to produce a perfect solution (like your sorting algorithm), you would have to first traverse the entire decision tree, doing so will take more than several lifetimes. The brutal reality is that all of human technology falls victim to this constraint. This is why we have minimum requirement's, a minimum requirement is the same reason why I own and use my car despite it being no where near perfection, Its minimum requirement is that it gets me from a to z in a safe and timely manner. We as human beings have the tendency to over optimize or analyze for many edge cases. Additionally, this i why "vibe coding" can be so difficult, for every piece of code you ordinary LLM outputs, it will also find and suggest many more improvements that which in themselves have other improvements that can be made upon and thus you are left with an exponentially large chain of possible decisions and improvements. Perhaps this is what the first popular tweet regarding vibe coding was referring to as "the exponentials".

Systems level thinking is the same reason why, Im being cautious to over analyze my writing, It's because the minimum requirement is the transfer of concepts via literature. It keeps me in scope, something ai cannot do.

I could go on and on about ai inability to think critically but let me know if you care for it in the meantime it lies outside my scope of minimum requirements.

Deny AI, Embrace You. - An AI Deconstuctions

Alan Buenrostro — Thu, 19 Jun 2025 03:16:28 +0000

Deconstructing AI -

a gift for all the junior devs with imposter syndrome

Today we are going to deconstruct the notion that you or any other individual needs AI to succeed, here are some common thought patterns that a diverse amount of individuals may have:

If I don’t use ai I’ll somehow fall behind! (or would i?)
I wouldn't be the same programmer without ai (or would i?)
AI makes me write code more efficiently. (or does it?)

News flash you've been lied to.

Companies have to lie (sort of)

Its simply marketing, marketing is an effective strategy used for decades to control the perception around your company and its products.

Systems Level Thinking

Refuse Perfection
“There is no minimum requirement for me to strive for perfection — therefore, perfection lies far outside my scope.”

I could go on and on about ai inability to think critically but let me know if you care for it in the meantime it lies outside my scope of minimum requirements.

Building a Smart Vue 3 Cart Manager Composable 🛒

Alan Buenrostro — Tue, 27 May 2025 17:08:08 +0000

Building a Smart Vue 3 Cart Manager Composable 🛒

Ever found yourself writing the same cart logic over and over across different components? I recently built a Vue 3 composable that centralizes all cart item interactions around one simple concept: the "focused item."

The Problem We're Solving

Think about how users interact with shopping carts. They don't just dump items in randomly. There's always a flow where they focus on one specific item, maybe adjust its quantity, then perform an action like adding it to cart or removing it entirely.

Traditional approaches scatter this logic across multiple components, making it hard to maintain and prone to bugs. What if we could capture this natural user behavior in a single, reusable composable?

The "Focused Item" Approach

The core insight is that cart interactions always revolve around one item at a time. Whether a user is viewing a product modal, adjusting quantities, or managing their cart, there's always one item that has their attention. This becomes our "focused item."

Here's how the composable works:

import { ref } from "vue"

function useCartManager() {
    // The item currently receiving user attention
    const currentFocusedItem = ref({});

    // Focus an item from different data sources
    const focusItem = function (options) {
        if (!options.from) {
            return console.error(`Function missing the from: property`)
        }

        let optionHandler = {
            // When you have a single product object (like from product details)
            "object": function (options) {
                const itemToFocus = options.data.value;
                if (!itemToFocus.quantity) {
                    itemToFocus.quantity = 0; // Ensure quantity exists
                }
                currentFocusedItem.value = itemToFocus;
            },
            // When you need to find an item in an array (like from search results)
            "array": function (options) {
                const itemToFocus = options.data.find((item) => {
                    return item.id === options.id
                })
                if (!itemToFocus.quantity) {
                    itemToFocus.quantity = 0;
                }
                currentFocusedItem.value = itemToFocus;
            }
        }

        if (optionHandler.hasOwnProperty(options.from)) {
            optionHandler[options.from](options)
        } else {
            return console.error(`${options.from} is an incorrect field`)
        }
    }

    // Smart quantity adjustment with validation
    const changeFocusedItemQuantity = function (number) {
        const currentQuantity = currentFocusedItem.value.quantity;
        const newQuantity = currentQuantity + number;

        // Keep quantities reasonable (0-100)
        if (newQuantity >= 0 && newQuantity <= 100) {
            currentFocusedItem.value.quantity = newQuantity;
        }
    };

    // Intelligent cart addition that handles duplicates
    const addFocusedItemToCart = function (cart) {
        const itemInCart = cart.find(item => { 
            return item.id === currentFocusedItem.value.id 
        })

        if (itemInCart) {
            // Item exists, just increase quantity
            itemInCart.quantity += currentFocusedItem.value.quantity
        } else {
            // New item, add it to cart
            cart.push(currentFocusedItem.value);
        }
    }

    // Clean cart removal
    const deleteCurrentFocusedItemFromCart = function (cart) {
        const itemIndex = cart.findIndex((cartItem) => {
            return cartItem.id === currentFocusedItem.value.id
        })
        cart.splice(itemIndex, 1);
    }

    return { 
        currentFocusedItem, 
        focusItem, 
        changeFocusedItemQuantity, 
        addFocusedItemToCart, 
        deleteCurrentFocusedItemFromCart 
    }
}

Real-World Usage

The beauty of this pattern becomes clear when you see how it simplifies component logic. Here's a typical product modal workflow:

const cartManager = useCartManager()
const { cart } = useCartStore()

// User clicks "Add to Cart" from product listing
function handleProductClick(productId, productsArray) {
  // Focus the clicked product
  cartManager.focusItem({ 
    from: "array", 
    data: productsArray, 
    id: productId 
  })

  // Set initial quantity
  cartManager.changeFocusedItemQuantity(1)

  // Show modal for quantity adjustment
  showModal.value = true
}

// User confirms purchase
function confirmAddToCart() {
  cartManager.addFocusedItemToCart(cart.value)
  showModal.value = false
}

For cart editing, the pattern is equally clean:

// Focus on cart item for editing
function editCartItem(itemId) {
  cartManager.focusItem({ 
    from: "array", 
    data: cart.value, 
    id: itemId 
  })
}

// Simple quantity controls
const increaseQty = () => cartManager.changeFocusedItemQuantity(1)
const decreaseQty = () => cartManager.changeFocusedItemQuantity(-1)
const removeItem = () => cartManager.deleteCurrentFocusedItemFromCart(cart.value)

Why This Approach Works

This composable succeeds because it mirrors natural user behavior. Users don't think about complex cart algorithms. They focus on one item, decide what to do with it, then move on. The composable captures this mental model perfectly.

The flexible focusItem method handles the reality that product data comes from various sources. Sometimes you have a single product object from an API, other times you're picking from a filtered array. The composable adapts to your data structure rather than forcing you to adapt to it.

Built-in validation prevents common edge cases like negative quantities or accidentally adding undefined items to carts. The error messages help during development, while the quantity limits prevent user confusion in production.

Key Benefits

The focused item pattern eliminates prop drilling by centralizing cart state management. Instead of passing cart functions down through multiple component layers, any component can access the cart manager and work with the currently focused item.

Testing becomes straightforward because each function has a single responsibility. You can test item focusing separately from quantity changes, and cart operations independently from item selection.

The composable scales naturally as your app grows. Need to add wishlist functionality? The same focusing pattern applies. Want to implement item comparisons? Focus multiple items and compare them. The pattern extends without breaking existing code.

Wrapping Up

This cart manager composable demonstrates how good Vue 3 composition functions should work. They capture natural user workflows, provide flexible APIs, and make complex interactions feel simple. The focused item concept proves that sometimes the best technical solutions are the ones that mirror how users already think about the problem.

The next time you're building cart functionality, consider whether your users are really managing multiple items simultaneously, or if they're focusing on one item at a time. The answer might lead you to simpler, more maintainable code that better serves your users' mental models.

🧠 XRPL — Hashing & Encryption: Foundations of the Ledger

Alan Buenrostro — Fri, 02 May 2025 18:37:30 +0000

🧠 XRPL EP.1 — Hashing & Encryption: Foundations of the Ledger

The fintech revolution is coming, and at its core lies one of the most underrated innovations of our time — the blockchain ledger. This isn’t just about cryptocurrencies or buzzwords. It’s about the raw cryptographic power that makes trustless, decentralized finance possible.

Welcome to Episode 1 of our new video series breaking down the XRP Ledger (XRPL) — one concept at a time.

🎥 Watch on YouTube

🔐 What’s Inside:

In this episode, we dive into the two cryptographic pillars behind the XRPL and modern blockchain systems:

Hashing: Immutable fingerprints for any data
Encryption: Protecting the integrity and privacy of transactions
Why Hashing ≠ Encryption (and why that matters)
How the XRPL uses these concepts under the hood

Whether you're new to Web3 or building on XRPL, these are tools you must understand.

📦 Why It Matters:

Most developers know what a hash function is. Fewer understand why it's critical in blockchain consensus, how it supports immutability, or how encryption standards impact financial systems at scale.

This series will bridge that gap — starting here.

⚙️ Tech Stack Mentioned:

SHA-256
Public/Private Key Encryption
XRP Ledger’s core protocol

🧪 Who This Is For:

Blockchain developers
Fintech engineers
XRPL builders
Anyone curious about real-world cryptography in action

📢 Follow the series — we’ll be breaking down the XRPL layer by layer, from consensus algorithms to smart contract integration (Hooks), and more.

➡️ Drop your thoughts or questions below — and let’s build the future of finance, together.

#xrpl #blockchain #crypto #encryption #hashing #web3 #fintech #devjournal #cryptography

🚀 Diving into the XRP Ledger with JavaScript

Alan Buenrostro — Tue, 22 Apr 2025 02:34:45 +0000

Installing The XRPL Library

This tutorial uses the xrpl library installed via npm

npm install xrpl

Baby Steps.

In order to make meaningful interactions with the xrp ledger , such as currency transactions, wallet creation, etc. We must first connect to the server.

We do so, by:

importing the Client Object from the xrpl library
Instantiating the Client object with the xrpl websocket server address.
making a connection using connect()
Disconnecting when the interaction is done.

//ES6 Imports
import {Client} from 'xrpl'

async function connectToLedger(){
    //Instantiate the object with xrpl address as an argument and store its reference.
    const client = new Client('wss://s.altnet.rippletest.net:51233/')
    //Connect Via the connect function
    await client.connect()
    console.log(await client.connection)
        //insert other code down here
        //Bla Bla Bla 
        client.disconnect();
    }

connectToLedger()

A brief breakdown xrp test network : `wss://s.altnet.rippletest.net:51233/1`

Faucets

In the realm of xrp, there exist a set of developer tools called Faucets aka test nets.
Faucets, Replicate the functionality of the mainet allowing you to test ledger interactions on a testing environment, and it also provides a websocket for fulfilling these interactions. These interactions include but are not limited to wallet creation, and token transactions.

Learn more: https://xrpl.org/resources/dev-tools/xrp-faucets

Why Dov We Need Faucets?

Some mainet interactions requires a small amount of xrp for ex; transactions, fund transfers, and tokenization, The benefit of a faucet really starts to shine when it comes to testing transactions and other important blockchain functionality without risking real xrp.

Wallet Creation

Now lets create a wallet and provide some funds.

import {Client} from 'xrpl'

async function connectToLedger(){
    //Instantiate the object with xrpl address as an argument and store its reference.
    const client = new Client('wss://s.altnet.rippletest.net:51233/')
    //Connect Via the connect function
    await client.connect()

        //Instantiating A wallet with fundWallet and storing its reference.
        let testFund = await client.fundWallet();
        //Waiting for promise and storing referennce of the wallet property
        let wallet = (await testFund).wallet
        //Waiting for promise and storing the wallet balance property
        let balance = (await testFund).balance
        console.log(`Wallet Public Key : ${wallet.publicKey} \nWallet Balance : ${balance}` )
        client.disconnect();
    }

connectToLedger()

Code Breakdown

`fundWallet()`

on line 10 we call the asynchronous fundWallet method from our previous client object.
this function returns an object containing a Wallet object, and within the Wallet object there are details such as its publicKey andprivateKey and seed phrase.
Alongside the Wallet object we have its balance.
In essence the function:

generates a new wallet.
Initiates a faucet transaction that sends 100 test XRP to the wallet’s public address via a WebSocket connection. This triggers a sequence of interactions between operation and issuer accounts on the test network.

Why FundWallet?

As we mentioned earlier, this is a testing environment, so we are able to utilize functions such as fundWallet to easily retrieve a dispensable wallet with dispensable funds, however you are not allowed to use fundWallet() on the mainet, you need to generate a wallet and send it funds via an external wallet with xrp or a Digital Exchange. See [[#Generating A wallet on the main-net.]] for more details.

{
  wallet: Wallet {
    publicKey: 'kgphikthpotpruktf325235rpkopkwpokgwopenr12359322f',
    privateKey: 'idjfi0wufj14faafaaffff110124812401gsafawfwafa4',
    classicAddress: 'idjfi0wufj14afafawawfafaafawfawfaw95329595f',
    seed: 'afiafjawifjawoifaw'
  },
  balance: 100
}

Querying data from a ledger.

`client.request()`

This method, is used for querying various types of ledger data, Afterall a ledger is a data structure and thus can be used as database. This method accepts a object map for query configuration. The current configuration we are using is:

        let onChainData= await client.request({
            command:"account_info", //The type of data we want to querry
            account:wallet.address, // The specific account or adress we want to querry
            ledger_index:"validated", // Most recently validated ledger index
        });
        console.log(`Balance In Drops : ${onChainData.result.account_data.Balance}`)

Config Key	Description
`command`	The query type
`account`	The account we desire to query in this context were using the address of the recently generated wallet
`ledger_index`	A specific ledger selector - in this context were selecting the most recently validated ledger index containing information surrounding this address.

Once the request is fulfilled it should return an object similar to this one:

{
  api_version: 2,
  id: 6,
  result: {
    account_data: {
      Account: 'fafawfawwfajifjawifawjfawf',
      Balance: '100000000',
      //.... Ledger Data
    },
    account_flags: {
      //.... Ledger Data      
      //.... Ledger Data
    },
    ledger_hash: 'faiwhfa9w0fhaw0f9ahf90awhf90awfhaw90fhawf0aw9ha9fhaw',
    ledger_index: 67999825,
    validated: true
  },
  type: 'response'
}

Final Source Code

import {Client} from 'xrpl'

async function connectToLedger(){
    //Instantiate the object with xrpl address as an argument and store its reference.
    const client = new Client('wss://s.altnet.rippletest.net:51233/')
    //Connect Via the connect function
    await client.connect()
        //Instantiating A wallet with fundWallet and storing its reference.
        let testFund = await client.fundWallet();
        //Waiting for promise and storing the wallet property
        let wallet = (await testFund).wallet
        //Waiting for promise and storing the wallet balance property
        let balance = (await testFund).balance
        console.log(`Wallet Public Key : ${wallet.publicKey} \nWallet Balance : ${balance}` )
        //Configuring querry via object
        let onChainData= await client.request({
            command:"account_info", //The type of data we want to querry
            account:wallet.address, // The specific account or adress we want to querry
            ledger_index:"validated", // Most recently validated ledger index
        });
        console.log(`Balance In Drops : ${onChainData.result.account_data.Balance}`)

        client.disconnect(); // A gracefull disconnect
    }

connectToLedger()

Generating a wallet and account on the main-net.

You can generate and receive its private and public key but it or any related data wont be on the ledger until a transaction its made to the wallet address.

Generating A Wallet

import {Wallet} from xrpl
let wallet = Wallet.generate();

Generate a wallet from seed

If you want to generate a wallet address based on a seed phrase:

import {Wallet} from xrpl
let wallet = Wallet.fromSeed("AFNAK9310913JFSAANFJFn")

Creating a FSM (finite state machine) in js_

Alan Buenrostro — Tue, 08 Apr 2025 20:02:54 +0000

Why This Post? Building a JavaScript FSM for Real-World Parsing

When I set out to create Terraformatic—a JavaScript library for parsing and validating Terraform HCL configurations—I hit a roadblock: finite state machines (FSMs). While FSMs power everything from regex engines to network protocols, I struggled to find a simple, configurable JavaScript implementation that could serve as the backbone for my lexical analyzer. Most solutions were either over-engineered for my needs or lacked the flexibility to model complex syntax rules.

Frustrated by this gap, I built my own minimal FSM abstraction. In this post, I’ll share this implementation, explain why FSMs matter for parsing tasks like Terraform HCL, and demonstrate how you can use (or extend) it for your own projects. Whether you’re building a linter, a configuration validator, or just curious about computational models, this post is for you.

What’s a Finite State Machine?

A finite state machine (FSM) is a computational model that abstracts logic into states, transitions, and actions. Think of it like a flowchart:

Here’s why FSMs shine for parsing tasks like Terraform HCL:

Predictability: Each state defines exactly what inputs are valid.
Error Handling: Invalid transitions can be caught immediately.
Simplicity: Complex syntax rules (e.g., nested blocks, quoted strings) become manageable when broken into discrete states.

What This Post Covers

A minimal FSM implementation in JavaScript.
How to configure states and transitions for real-world use cases.
Lessons learned from applying FSMs to Terraform HCL parsing.

By the end, you’ll have a reusable FSM abstraction and a template for solving similar problems. Let’s dive in!

Implementation Details: Your Toolkit for Building State Machines

The FSM class is designed to be simple but powerful—like a Swiss Army knife for modeling stateful logic. Whether you’re parsing syntax, designing game AI, or handling UI flows, here’s how it works under the hood:

1. The Constructor: Your FSM’s Blueprint

To create a state machine, define its states and transitions upfront. Think of this as drawing a map for your FSM to follow:

// Example: A traffic light FSM
const trafficLight = new FSM({
  entrySTATE: "RED", // Starts at RED
  states: {
    RED: { 
      next: "GREEN", // Transitions to GREEN on input "next"
      accepts: true  // Optional: Mark RED as an accepting state
    },
    GREEN: { next: "YELLOW" },
    YELLOW: { next: "RED" }
  }
});

Key Configuration Options

states: A dictionary where each key is a state name, and its value defines:
- Transitions: { input: "next_state", ... } (e.g., next: "GREEN").
- Accepting States: Add accepts: true to mark states where the FSM can "halt" successfully.
entrySTATE: The starting point (defaults to "STATE_A" if omitted).

Default Behavior

If you don’t provide options, you’ll get a toggle switch FSM:

{
  states: {
    STATE_A: { 0: "STATE_B", 1: "STATE_A" }, // Toggles on 0, stays on 1
    STATE_B: { 0: "STATE_A", 1: "STATE_B", accepts: true }, // STATE_B is accepting
  },
  entrySTATE: "STATE_A"
}

2. Core Methods: Navigating the State Maze

`transition(input)` – Move Between States

Feed inputs to your FSM, and watch it traverse its state map:

trafficLight.transition("next"); // RED → GREEN
trafficLight.transition("next"); // GREEN → YELLOW

Why It Matters:
- Throws an error if the input isn’t valid for the current state (e.g., trying to pause a traffic light).
- Updates currentINPUT to log the last processed input (useful for debugging).

`isAccepting()` – Check for Success

Call this to see if the FSM is in a valid "end" state:

console.log(trafficLight.isAccepting()); // true if in RED (our accepting state)

`reset()` – Rewind to the Start

Reset the FSM to its entrySTATE—like a time machine for your state machine:

trafficLight.reset();
console.log(trafficLight.currentSTATE); // "RED"

3. Properties: The FSM’s Memory

currentSTATE: The FSM’s "where am I?" tracker.
entrySTATE: The "home base" it returns to on reset().
currentINPUT: A breadcrumb trail of the last input processed.
STATES: The full state/transition configuration (for introspection).

Real-World Example: A Light Switch

Let’s model a light with ON/OFF states:

const light = new FSM({
  entrySTATE: "OFF",
  states: {
    OFF: { toggle: "ON" },
    ON: { toggle: "OFF", accepts: true } // Optional: Treat "ON" as a valid end state
  }
});

light.transition("toggle"); // OFF → ON
light.transition("toggle"); // ON → OFF

Error Handling: Your Safety Net

The FSM throws descriptive errors if you try to break its rules:

try {
  light.transition("break"); // "break" isn’t a valid input for OFF/ON
} catch (e) {
  console.error(e.message); // "Invalid input break: or state does not exist: OFF"
}

Pro Tips

Coercion: Inputs are coerced to strings (e.g., 0 becomes "0"). Use consistent input types!
Accepting States: Not just for "success"—use them to flag specific states (e.g., ERROR).
Extend It: Add hooks for onEnter/onExit callbacks to supercharge your FSM.

Go Build Something!

With this abstraction, you can model:

Lexers: Tokenize Terraform HCL (like I did!).
UI Flows: Handle multi-step forms or wizards.
Game Logic: Control enemy AI or dialogue trees.

Got questions? Found a cool use case? Drop a GitHub issue—I’d love to hear how you’re using this!

This implementation balances simplicity with just enough power to handle real-world problems. Now go turn those state diagrams into code! 🚀

function FSM(options = {}) {
  //State Storage
  //Inherits options configuration
  this.STATES = options.states || {
    STATE_A: {
      0: "STATE_B",
      1: "STATE_A",
    },

    STATE_B: {
      0: "STATE_A",
      1: "STATE_B",
      accepts: true,
    },
  }

  this.entrySTATE = options.entrySTATE ? options.entrySTATE : "STATE_A";
  this.currentSTATE = this.entrySTATE;
  this.currentINPUT = "";

  this.transition = function (input) {
    try {
      this.currentINPUT = `${input}`;
      this.currentSTATE = this.STATES[this.currentSTATE][input]
    }
    catch (e) {
      throw new Error(`Invalid input ${this.currentINPUT}: or state does not exist: ${this.currentSTATE}`);
    }
  }
  this.isAccepting = function () {
    let accepting = !!this.STATES[this.currentSTATE]?.accepts;
    return accepting
  }
  this.reset = function (){
    this.currentSTATE = this.entrySTATE;
  }
}

"I just wanted to point out the impressive UI in this website. I love it and i think it is absolutely beautiful." - Alan

Alan Buenrostro — Sun, 11 Aug 2024 02:51:17 +0000

DEV Community: Alan Buenrostro

🛠️ Simple Shallow Type Checker in JavaScript

📦 The Code

🧪 Example Usage

🔴 What if the types don't match?

🚫 Limitations

✅ When to Use This

Deny AI, Embrace You. - An AI Deconstuction

Deconstructing AI -

a gift for all the junior devs with imposter syndrome

News flash you've been lied to.

Companies have to lie (sort of)

Systems Level Thinking

I could go on and on about ai inability to think critically but let me know if you care for it in the meantime it lies outside my scope of minimum requirements.

Deny AI, Embrace You. - An AI Deconstuctions

Deconstructing AI -

a gift for all the junior devs with imposter syndrome

News flash you've been lied to.

Companies have to lie (sort of)

Systems Level Thinking

I could go on and on about ai inability to think critically but let me know if you care for it in the meantime it lies outside my scope of minimum requirements.

Building a Smart Vue 3 Cart Manager Composable 🛒

Building a Smart Vue 3 Cart Manager Composable 🛒

The Problem We're Solving

The "Focused Item" Approach

Real-World Usage

Why This Approach Works

Key Benefits

Wrapping Up

🧠 XRPL — Hashing & Encryption: Foundations of the Ledger

🧠 XRPL EP.1 — Hashing & Encryption: Foundations of the Ledger

🔐 What’s Inside:

📦 Why It Matters:

⚙️ Tech Stack Mentioned:

🧪 Who This Is For:

🚀 Diving into the XRP Ledger with JavaScript

Installing The XRPL Library

Baby Steps.

A brief breakdown xrp test network : wss://s.altnet.rippletest.net:51233/1

Faucets

Why Dov We Need Faucets?

Wallet Creation

Code Breakdown

fundWallet()

Why FundWallet?

Querying data from a ledger.

client.request()

Final Source Code

Generating a wallet and account on the main-net.

Generating A Wallet

Generate a wallet from seed

Creating a FSM (finite state machine) in js_

Why This Post? Building a JavaScript FSM for Real-World Parsing

What’s a Finite State Machine?

What This Post Covers

Implementation Details: Your Toolkit for Building State Machines

1. The Constructor: Your FSM’s Blueprint

Key Configuration Options

Default Behavior

2. Core Methods: Navigating the State Maze

transition(input) – Move Between States

isAccepting() – Check for Success

reset() – Rewind to the Start

3. Properties: The FSM’s Memory

Real-World Example: A Light Switch

Error Handling: Your Safety Net

Pro Tips

Go Build Something!

"I just wanted to point out the impressive UI in this website. I love it and i think it is absolutely beautiful." - Alan

A brief breakdown xrp test network : `wss://s.altnet.rippletest.net:51233/1`

`fundWallet()`

Why `FundWallet`?

`client.request()`

`transition(input)` – Move Between States

`isAccepting()` – Check for Success

`reset()` – Rewind to the Start