DEV Community: nuel ikwuoma

Unlocking Ethereum Scalability with Scroll and Wormhole Integration

nuel ikwuoma — Thu, 06 Jun 2024 13:43:34 +0000

Unlocking Ethereum Scalability with Scroll and Wormhole Integration

The Ethereum blockchain, popular for its decentralized applications (dApps) and Smart Contracts, experiences serious scalability challenges. To address these, various Layer 2 (L2) solutions have surfaced, rendering enhanced throughput and minimizing costs while maintaining Ethereum’s security and decentralization. Among these solutions, Scroll remains one of the most innovative zkEVM (zero-knowledge Ethereum Virtual Machine) validity rollups.

This article explains how Scroll enhances Ethereum’s scalability and the impact of its integration with Wormhole, facilitating the deployment of Ambient Finance, c3, and Synonym on the Scroll network.

Understanding Scroll’s zkEVM Rollup

Scroll is an enhanced Layer 2 scaling solution that leverages EVM, a zero-knowledge rollup designed to scale Ethereum applications without needing specialized circuit designs.

Zero-knowledge proofs (ZKPs) are known for verifying how credible a statement is without the statement itself. When used on blockchains, ZKPs can verify a large number of transactions off-chain and then batch them into a single proof submitted on-chain. This process significantly helps to minimize computational load and gas fees.

Scroll’s zkEVM is particularly intriguing because it maintains Ethereum Virtual Machine (EVM) congruence, meaning developers can dispatch existing Ethereum smart contracts on Scroll with minimal changes. This congruence ensures that developers can maximize the existing tools, languages, and frameworks built for Ethereum, facilitating a seamless transition and broader adoption.

How Scroll Works

1. Transaction Batching

Transactions are initially processed off-chain in a Layer 2 environment.

2. Proof Generation

These transactions are then bundled together, and a succinct proof (zk-SNARK) is generated to attest to their validity.

3. On-Chain Verification

The proof is passed on to the Ethereum mainnet, where Smart Contracts verifies it. Through this process, computational resources and amount of data required are drastically reduced, ultimately, leading to lower gas fees and faster transactions.

By using this method, Scroll achieves high throughput and cost efficiency without compromising on security. The validity rollup ensures that all off-chain transactions are cryptographically secure and verifiable on-chain.

Bridging Ecosystem with the aid of Wormhole Ecosystems

Wormhole is a cross-chain transmission protocol that eases interchangeability between different blockchain networks. Through the integration of Wormhole with Scroll, several prominent dApps—Ambient Finance, c3, and Synonym—are now set to be deployed on Scroll, bringing with them new functionalities and user experiences.

Ambient Finance

Ambient Finance leverages on the services rendered by decentralized finance to provide users with various financial products, including lending, borrowing, and asset management. Deploying on Scroll via Wormhole allows Ambient Finance to offer these services with lower transaction costs and higher efficiency, attracting a broader user base and enabling more complex financial products.

c3

c3 focuses on decentralized data storage and management. By integrating with Scroll, c3 benefits from reduced data storage costs and enhanced speed, crucial for applications handling large volumes of data. This integration also enhances c3’s ability to offer scalable solutions to enterprises requiring decentralized storage.

Synonym

Synonym aims to streamline cross-chain asset transfers and decentralized exchanges. With Wormhole and Scroll, Synonym can facilitate faster and cheaper transactions, improving the overall user experience in the decentralized finance (DeFi) ecosystem. This deployment ensures that users can move assets across different blockchains seamlessly, leveraging Scroll’s efficiency and Wormhole’s interoperability.

The Future of Ethereum Scaling

The integration of Scroll and Wormhole is one of the prominent moves towards addressing challenges associated with Ethereum’s scalability. This is because the integration fosters the maximization of the strengths of zKEVM roll ups when combined with cross-chain interoperability, rendering a robust framework for developing scalable, secure, and cost-effective networks.

Scroll and Wormholes integration represents a significant step forward in addressing Ethereum’s scalability issues. By combining the strengths of zkEVM rollups and cross-chain interoperability, they offer a robust framework for developing scalable, secure, and cost-effective decentralized applications.

Key Benefits

Enhanced Scalability

Scroll’s zkEVM rollup drastically increases transaction throughput and reduces costs.

Seamless Interoperability

Wormhole enables cross-chain communication, allowing dApps to operate across multiple blockchains.

Broader Adoption

With EVM compatibility, existing Ethereum dApps can easily migrate to Scroll, benefiting from its scalability improvements.

Challenges Ahead

This integration is promising, however, it also comes with challenges like ensuring robust security during cross-chain interactions and preserving all the ethos of decentralization in the Ethereum Ecosystem. In order to address these challenges, there is a need to embark on continuous development and rigorous testing.

Conclusion

When it comes to Ethereum Scaling, merging Scroll’s zkEVM rollup with Wormhole is vital as it not only improves the performance and cost-efficiency of dApps but also facilitates a more interdependent blockchain ecosystem. With Ambient Finance, c3, and Synonym all deployed on Scroll, both users and developers can anticipate an Ethereum network with higher scalability and versatility, which could usher the web3 industry into the next generation of decentralized applications.

Introducing Wormhole Gateway

nuel ikwuoma — Wed, 09 Aug 2023 10:33:34 +0000

Wormhole Gateway was recently announced as an app-chain built on the industry tested Cosmos-SDK to enable bridging non-native assets into the Cosmos ecosystem. This is a huge milestone for cross-chain or chain-agnostic application, but before we explain what Gateways aims to achieve, lets briefly re-introduce Wormhole, for what it is, and what it tries to achieve in the web3 ecosystem.

So as we know, ever since the existence of blockchains capable of executing arbitrary programs on-chain a.k.a Smart Contracts, different networks have sprung up, each with it own unique promise and competitive advantage, and although this has led to innovation in the web3 space but albeit not without its own challenges as well. Having blockchain networks which are isolated is synonymous living in world without any means of communication or even transportation from a source to a destination.
Now we can begin to imagine the kinds of challenges we're poised to face in a world such as this, including missed out opportunities for economic co-operation, trade and skills or knowledge transfer. These problems are also synonymous in isolated blockchain networks of today, hence the need for a mechanism or a system by which say chainA can communicate and send message back and forth with say chainB.

What is Wormhole?

At its core, Wormhole strives to be a generic message passing protocol, allowing for transfers of arbitrary data between different blockchains. This system is currently operated by a network of guardians, which are responsible for creating what is known as VAAs(verifiable Action Approvals) from messages observed in blockchain networks on which wormhole core-contract is deployed. These VAAs server are a security primitive or these cross-chain interactions, however a planned future upgrade to the Wormhole protocol would replace these with state proofs, effectively leading to a much more decentralized message passing system.
Now that we've established the fundamentals of what Wormhole is about, let's meet Gateway😃.

Enter the Gateway

Gateway is an app-chain built with the Cosmos-SDK, to facilitate message transfer in the cosmos ecosystem and serve as a unified liquidity source in the Cosmos ecosystem.
A big selling point for Gateway is that it leverages IBC(Inter-blockchain Communication) which is an industry standard protocol for authentication and transport of data between blockchains.
It might be worth pointing out that Cosmos itself is a Multichain ecosystem, allowing for seamless interoperability between sovereign blockchains, all enabled by IBC(Inter-Blockchain Communication) module. Therefore cosmos chains that do implement this module can interact seamlessly with each other.

(An overview of the cosmos ecosystem).

How Gateway work?

For transfers of x-Assets between cosmos chains, these assets are sent from the source chain to the Gateway via IBC messages, and then forwarded to the destination chain on cosmos. By leveraging IBC and packet forwarding middleware, it becomes possible to bridge tokens in the Cosmos ecosystem without liquidity fragmentation, hence making Gateway the canonical chain in cosmos for bridging x-Assets through IBC transfer, and with no additional fees.

Fun Fact: Originally Gateway was called Wormchain😉

Why you should use Gateway

Scalability:
Gateway is highly scalable as only one full node is required to be operated by the Guardians to connect the entirety of the Cosmos ecosystem.
Security:
Gateway leverages light clients to facilitate assets transfers to and between cosmos chains, making it highly secure.
Fungibility:
Gateway acts as the router for x-Assets transfer, hence making these assets 100% fungible.

Additional Information and resources

As part of a series of events lined up for the month of August, Gateway would be launched officially on 15th of August, with connection to Osmosis as the first supported chain, then other cosmos chains would follow suite. Some Interesting times ahead!🚀🚀

To stay up-to-date with happenings in the wormhole ecosystem, be sure to check wormhole socials:
Wormhole twitter

Official Site

Thanks for reading, and see you all in web3, WAGMI!!!

A guide to extending ERC2535 Diamonds.

nuel ikwuoma — Wed, 22 Mar 2023 19:09:23 +0000

In this article, I introduce the Diamond standard for writing upgrade-able smart contracts, and give a walk through of how it can be extended,to add support for roll-back upgrades.

Pre-requisites:

understanding ethereum and smart contracts.
experience with solidity.
basic terminal skills, hardhat and foundry installation.

For foundry installation, follow this link.

Brief introduction to Diamonds.

EIP2535 introduces the diamond standard as:

A modular smart contract systems that can be upgraded/extended after deployment, and have virtually no size limit. More technically, a diamond is a contract with external functions that are supplied by contracts called facets. Facets are separate, independent contracts that can share internal functions, libraries, and state variables.

In my opinion, what makes diamond standard shines is the clear separation of concern(a.k.a logic) baked into it from the ground up. This is made possible through what is called facets, which are smart contracts that groups logic that are related in one place. The default Diamond implementation used in this article includes three such facets described below:

DiamondCutFacet - This facet is mainly concerned with performing upgrade related logic on the Diamond.
DiamondLoupeFacet - This facet is mainly concerned with introspection into the diamond.
OwnershipFacet - Like the name implies, this facet is mainly concerned with matters related to ownership/admin/access-control on the diamond.

Now, onto the most important component, The Diamond itself, which is the proxy smart contract that enshrines the state of the whole system, and exposes the methods of the facets using delegatecall.
There are other components built into this default implementation, which includes libraries, interfaces and so on, but we'd discuss those later on as they're encountered.

To follow along in your preferred IDE, you can clone the repository and follow the ReadME to install the necessary dependencies.

The adventure begins... 🚗

Tracking the state of the diamond.

The Diamond for this demonstration, utilizes the diamond storage pattern, which declares the state of the Diamond as a storage struct, this is made possible via a feature of libraries in solidity, which allows for a library function to return a struct in storage, see here.

function diamondStorage() internal pure returns (DiamondStorage storage ds) {
        bytes32 position = DIAMOND_STORAGE_POSITION;
        assembly {
            ds.slot := position
        }
    }

This struct is then set in storage using the hash of a unique string, effectively preventing storage slot collision.
The library defines important data structure and logic that are shared amongst facets, thereby upholding the justifications of this standard (i.e Facets can share internal functions, libraries).

How upgrades are accomplished?

In diamond lingo, upgrade is synonymous to cut, the DiamondCutFacet implements the diamondCut to achieve that. However the struct FacetCut models the data unique to performing the said upgrade, i.e cutting the Diamond.

 struct FacetCut {
        address facetAddress;
        FacetCutAction action;
        bytes4[] functionSelectors;
    }

How can we roll-back an upgrade? 😐

First we define a custom RollBack struct, to model the data for performing a rollback

  struct RollBackCuts {
        address[] facetAddress;
        IDiamondCut.FacetCutAction action;
        bytes4[] functionSelectors;
    }

Next we append an array of this struct to the storage struct of the diamond, and subsequently populate this array with every upgrade to the diamond, see here, here and here, these functions adds, replaces and removes functions from the Diamond as part of an upgrade.

struct DiamondStorage {
        // maps function selector to the facet address and
        // the position of the selector in the facetFunctionSelectors.selectors array
        mapping(bytes4 => FacetAddressAndPosition) selectorToFacetAndPosition;
        // maps facet addresses to function selectors
        mapping(address => FacetFunctionSelectors) facetFunctionSelectors;
        // facet addresses
        address[] facetAddresses;
        // Used to query if a contract implements an interface.
        // Used to implement ERC-165.
        mapping(bytes4 => bool) supportedInterfaces;
        // owner of the contract
        address contractOwner;
        // history for rollback
        RollBackCuts[] rollbackCuts;
    }

A constant address, labeled as ROLLBACK_ADDRESS is defined in the library this:

address constant ROLLBACK_ADDRESS = 0x000000000000000000000000000000000000bEEF;

This constant address distinguishes a roll-back from an upgrade, hence preventing the duplication bug from multiple roll-backs.
Further more, the ROLLBACK_ADDRESS also serves to deter an initialization call on roll-back.

Then we proceed to define the logic for the rollback as part of the DiamondCutFacet:

function rollback() external override {
        // enforce is contract owner
        LibDiamond.enforceIsContractOwner();
        // LibDiamond.DiamondStorage storage ds = LibDiamond.diamondStorage();
        LibDiamond.RollBackCuts[] storage rollbackCuts = LibDiamond.diamondStorage().rollbackCuts;
        uint256 rollbackCutsLength = rollbackCuts.length;
        if(rollbackCutsLength == 0) {
            revert NoRollBackAction();
        }
        LibDiamond.RollBackCuts memory rollbackCut = rollbackCuts[rollbackCutsLength - 1];
        // remove last rollback action
        rollbackCuts.pop();
        uint256 cutLength = rollbackCut.facetAddress.length;
        IDiamondCut.FacetCut[] memory facetCut = new IDiamondCut.FacetCut[](
            cutLength
        );
        for (uint i = 0; i < cutLength; ++i) {
            bytes4[] memory rollbackSelector = new bytes4[](1);
            rollbackSelector[0] = rollbackCut.functionSelectors[i];

            facetCut[i] = IDiamondCut.FacetCut(
                rollbackCut.facetAddress[i],
                rollbackCut.action,
                rollbackSelector
            );
        }
        LibDiamond.diamondCut(
            facetCut,
            LibDiamond.ROLLBACK_ADDRESS,
            ""
        );
    }

The logic for the rollback effectively reads the storage struct, checks if a rollback is valid, constructs the data for rollback and proceeds to cut the diamond with the said data, using our beloved ROLLBACK_ADDRESS once again.

The Diamond once again. 💎

This time we dive into the logic of the Diamond constructor, and the main change here is registering the selector of our rollback implementation as seen here.

constructor(address _contractOwner, address _diamondCutFacet) payable {
        LibDiamond.setContractOwner(_contractOwner);

        // Add the diamondCut external function from the diamondCutFacet
        IDiamondCut.FacetCut[] memory cut = new IDiamondCut.FacetCut[](1);
        bytes4[] memory functionSelectors = new bytes4[](2);
        functionSelectors[0] = IDiamondCut.diamondCut.selector;
        // Add the rollback extxernal function from the diamondCutFacet
        functionSelectors[1] = IDiamondCut.rollback.selector;

        cut[0] = IDiamondCut.FacetCut({
            facetAddress: _diamondCutFacet,
            action: IDiamondCut.FacetCutAction.Add,
            functionSelectors: functionSelectors
        });

        LibDiamond.diamondCut(cut, address(0), "");
    }

With all major changes out of the way, we proceed to write test to validate our code:
The tests can be found here.
Now in your terminal excute the commands to compile and run the tests:

npx hardhat compile

forge test

The test essentially deploys, upgrade, and execute a roll-back on the diamond.
Verify that it passes, and viola!!! 🎉 We have basically extended an ERC2535 Diamond to add support for roll-back, which brings us to the end of this article.

If you enjoy reading code, i encourage an in-depth look at the Repo.

Once again, congrats on making it to the end, and I hope you found this article useful and can proceed to implementing Diamonds in the wild. Reach me on twitter @nuel

Arbitrary Message Signing in Dapps

nuel ikwuoma — Tue, 17 Aug 2021 03:32:32 +0000

Hi, I am nuel, a web and smart contract developer, i tweet frequently about web development and blockchains, find me here

For the absolute beginners, i would like to briefly define what Dapps are...

A Dapp is a decentralized application, that functions and executes based on the primitives of the blockchain, making it permissionless, trustless and censorship resistant

In a quest to understand message signing and digital signatures, which is quite a relatively new concept for me, I had gone through the rabbit hole of reading tons of articles and even landed in several official Ethereum Improvement Proposals (EIP-155, EIP-191, EIP-712), these proposals although well detailed out isnt neccasarily the best landing point for a beginner new to this concept as it can seem really abstract, as it was for my case initially as it took me a whole lot of time to figure out the basics of arbitratry message signing and what digital signatures really are and why we might need one. So I would approach this article starting by answering the question of:

What digital signatures are?
Why we need digital signatures?
Use cases in Dapps.

What are digital signatures?

Basically, digital signature is a way to prove identity, even in the absence of the entity who owns the signature.(still dosent make sense, relax).

It works similar like this: Imagine you were issued a cheque by a account holder, the cheque is signed and all you have to do is go to the bank, once the bank verifies the signature on the cheque (and maybe other verifications), you become elligible to claim the said ammount. In the context of Dapps, an externally owned account signs a message or transaction off-chain, and anyone can submit the transaction on-chain to verify the signature or perform its intended action in the case of a transaction.

Why we need digital signatures?

Aside the obvious benefits of authentication checks, digital signatures can improve the user experience in Dapps, and also reduce the number of transactions sent to the blockchain, see this awesome article for a quick and well explained demonstration.

Use cases?

Some trending uses cases for digital signatures are listed but not limited to...

Authentication
Message signing and verification
UX improvements
Gasless transactions

Where to go from here?

If you are building smart contract on ethereum using solidity or you flesh out the frontends of Dapps, you might want to take look at this, this and this proposals, to get a much deeper understanding on the topic.

NOTE: Message signing, although done with a private key, is not the same as encryption.

I am still actively learning and researching about blockchain and web3/p2p technologies, and I would love to hear your suggestions, as well as recommendations.

Thanks for reading, have any questions and/or interests related to Ethereum smart contract development or solidity? Reach out on Twitter>>> nuel

Higher Order Functions - A pragmatic approach

nuel ikwuoma — Sat, 18 Jul 2020 12:17:23 +0000

Intoducting HoF

Its a common saying that functions are the bread and butter of programming, and the basic unit for building reusable logic in many programming languages, but What makes a function become higher-order?
In simple terms, a HoF is just a kind of function that can accept other function(s) as argument or/and return a function.
Still Not clear? ,Its fine,

a line of code says more than a thousand words. Lets proceed.

There are many different scenarios for approaching HoF but i would list some of the mot common as we continue

Filtering Collections

To demonstrate a simple example, we consider a basic attempt to get only even numbers from a collection, we do the following:

const nums = [1, 2, 3, 6, 8, 11];
const result = [];

for(let i=0; i < nums.length; i++) {
     if(nums[i] % 2 == 0) {
         result.push(i)
     }
     return result;
 }

result     // [2, 6, 8]

This approach seems to work, but if the criteria for selecting the result become a little complicated, things can easily start to look messy, also leaving no room for reusability. A better approach would be to write a custom filtering logic as we do below.

function filter(nums, test) {
      let result = [];
      for(let i=0; i<nums.length; i++) {
          if(test(nums[i])) {
              result.push(nums[i])
          }
      }
      return result;
  }

The function we have just written would expect a collection as its first argument and another function as its second argument, which would be used to perform the selection criteria, now we can easily demonstrate the previous example again.

 let result = filter(nums, num => num % 2 == 0);
 result;      // [2, 6, 8]

It should noted that the custom filter function defined above is only a naive attempt to implement the more robust and efficient inbuilt Array.prototype.filter built-in method, for filtering Array collections.

Grouping

An even more useful application for HoF would be to group collection by say some arbitrary tag, and presenting them in a nicer arrangement.
This is one in many scenarios where higher order function begins to shine. Lets implement the logic to group items

function group(items, groupBy) {
        let grouped = Object.create(null);

        for(let i=0; i < items.length; i++) {
            let tag = groupBy(items[i])
            if(tag in grouped) {
                grouped[tag].push(items[i])
                continue;
            }
            grouped[tag] = [items[i]];

        }

        return grouped;
    }

For this example we would utilize the group function we just defined to re-arrange a collection, using a arbitrary tag.

const items = [
     {tag: "car", name: "tesla", model: "Y"},
     {tag: "smartphone", name: "Samsung", yr: "2019"},
     {tag: "car", name: "mercedes", model: "classic"},
     {tag: "gaming", name: "PS5"},
     {tag: "smartphone", name: "Iphone", yr: "2019"}
]
const tagged = group(items, item => item["tag"]);

tagged   
/*
  {
     car: [
        { tag: 'car', name: 'tesla',model: "Y"},
        { tag: 'car', name: 'mercedes', model: "classic" }
     ],
     smartphone: [
        { tag:'smartphone', name: 'Samsung s9', yr: "2018" },
        { tag:'smartphone', name: 'Iphone 11', yr: "2019" }
     ],
     gaming: [ { tag: 'gaming', name: 'PS5' } ]
    }
*/

Cool right? 😊 With HoF we can easily express this logic and still maintaining readability of our code.

Flattening Arrays

Ill leave you with this attempt to flatten a nested array, of an arbitrary depth. The first attempt would make use of the built-in Array.prototype.reduce. Lets do that.

function flatten(nested) {
    return nested.reduce((flat, next) => {
        return Array.isArray(next) ? [...flat, ...next]
                                   : [...flat, next]
    }, [])
}

const nest = [1, 2, [3, 5], 0]
const deeper = [1, 2, [3, 5, [0, 9, 1]], 0]

flatten(deep)   // [1, 2, 3, 5, 0]
flatten(deeper)   // [1, 2, 3, 5, [0, 9, 1], 0]

Notice that trying to flatten a deeply nested array, seemed not to yield the expected output 😦. However, we can do better, and we try a second approach but this time using the good old recursion technique in combination with Array.prototype.reduce

function flatten(nested) {
    return nested.reduce((flat, next) => {

        if(Array.isArray(next)) {
            return [...flat, ...flatten(next)]
        }

        return [...flat, next]

    }, [])
};

flatten(deeper)  // [1, 2, 3, 5, 0, 9, 1, 0]

Viola, we get the result we expected. It works!!! 😆

Conclusion

In essence higher order functions are not really difficult to understand, although they could look somewhat intimidating at first. Many popular javascript libraries including Redux, use them behind the scenes to expose simple interface for implementing even very complex logic.

I hope you do enjoy this article, as much as i did putting it up. Please leave your review below.

Say hi on twitter 💙
Lovely weekend to you!

JavaScript concepts to write better React code

nuel ikwuoma — Sat, 11 Jul 2020 09:53:51 +0000

Beginning development in React can be fun and trivial, however your codebase could quuickly get messy, verbose and unreadable unless some careful toughts are put into the development process. Writing clean (quality) code, many would agree comes with experience and i also belong to that school of thought, however there are simple and often overlooked javascript concepts that i believe if harnessed properly can greatly improve our React code quality. I would list these concepts in no particular order, Lets begin...

Object destructing

To be honest, ive never seen a professional React codebase without this sugar. Its a simple concept that can greatly improve code conciseness. The idea is simple - write variables whose names matches those of the object to be destructured and hold the same value as the name it mirrors.

let {foo, baz} = {foo: 1, bar: "Leave me out", baz: 2}
console.log(foo, baz) // -> 1, 2

This property is used in React mostly to assign variables from a component prop or state, hence avoiding repeated calls to props[dot]this, state[dot]that. I hope you get this idea. 😆
The same also applies for destructuring array, however the index of array elements determines how the operation executes.

Conditional Execution

More often we have logic we want to excute based on some given criteria, using simple if-else statement would suffice, however React developers favor the && operator instead. The code below logs 'congrats' to console if an expression returns 'true'

const isAdult = (age) => age >= 18

isAdult(18) && console.log('Congrats!!!')    // 'congrats'

Spread Operators

Often in React codebases you see the spread operator been used to pass props to components, as this is often convinient.
A simple use case for spread operators are passing arbitrary arguments to a function. A simple is how we would calculate the 'mean' from a series of numbers, we could leverage spread operator to make this easy.

const calc_mean = (...series) => series.reduce((sum, n) => sum + n, 0) / series.length;
const mean = calc_mean(2,4,6,8)
console.log(mean) // 5

Using spread operator we can evaluate mean from an arbitrary length of arguments.

Flattening with Array.prototype.reduce()

I chose the word 'flattening' out of recklessness, as i could not come up with something better, do forgive me 😱
However the intent is here is trying to reduce a collection to a single output. Say for instance you have been tasked at your new job to find the percent reviews of a newly shipped product from a given 'customers' sample.

let customers = [
    {category: 'happy', count: 1200},
    {category: 'sad', count: 204},
    {category: 'indifferent', count: 25}, 
];

// compute total from customers list
let total = customers.reduce((sum, {count}) => sum + count, 0)

// optional: proceed to compute percent for all categories
let customer_reviews = customers.map(customer => {
    let percent = customer.count / total * 100
    return {...customer, percent: percent.toFixed(2) + '%'}
})

console.log(customer_reviews)

Now we have a list of customers with their average percentage reviews.

Higher Order Functions

This category of higher-order functions discussed here involve those that return a function, as they can greatly result to code conciseness and make abstracting reusable logic a breeze. Say for instance, we want to filter a collection based on another collection

let invite_ids = [ 0, 1, 1, 2, 3, 5, 8, 13, 21, 34]
let friends = [{name: 'sam', id: 1}, {name: 'jon', id: 13}, {name: 'snow', id: 10}]

Fun Fact: The array, invite_ids is actually a fibonacci series 😉

Now we only want those friends whose id can be found in the invite_ids list to attend the party, how do we go about this?

const filter_invites = (ids) => ({id}) => ids.includes(id)

// now we can do this...
let my_invites = friends.filter(filter_invites(invite_ids))

console.log(my_invites) // [{name: 'sam', id: 1}, {name: 'jon', id: 13}]

Now notice how concise and brief we have implemented this logic while still maintaining readability. The function that performs the filtering can even be abstracted for purpose of reusing and/or testing.

Template Literals

Template literals are cool, in-essence they are just like strings, but with more capabilities. Very often, they are used in places where we intend to embed expressions and other code-related logic.

A simple greeting procedure

function greet(name) {
    return `Hello ${name}`
}
greet('mike')    // Hello mike

conditional logic in templates

let friends = ["ola", "tea", "mike"]
let className = `box ${friends.length ? 'show' : 'hidden'}`
console.log(className)    // 'box show'

By utilizing template literals we can write inline and more concise conditional expressions.
There are many other concepts to uncover as you write more React code, but i do not intend this post an ultimate authority. Thanks for reading, and i love your feedback.

You can follow me on twitter

Using Iterators and Generators in JavaScript

nuel ikwuoma — Thu, 02 Apr 2020 02:48:41 +0000

The word 'iterable' appears in many programming paradigm, it simply can be assumed as any data-structure that can be passed to a loop, to extract its contents. Many types in javascript are iterable, the likes of which includes string, array, set e.t.c
A quick example would be iterating over the Array type, so we can safely call the Array type an iterable

let weekends = ["fri", "sat", "sun"];   // Array type
for(let day of weekends) {
    console.log("its " + day)
}

Before we begin to implement our own custom iterable, lets quickly take a look at generators. A generator in javascript is an function expression with a yield statement, its quite different from a normal function and the yield statement should be inside the function block that defines the generator and not in an enclosing function. A quick demo of generator for yielding fibonacci sequence looks thus:

 function * fibonacci (rng) {
     let a = 0, b = 1, nxt;
     for(let i=2; i < rng; i++) {
        nxt = a + b;
        a = b;
        b = nxt
        yield nxt;    // 'yield' the next number in the fibonacci sequence
     }
 }

// using the fibinacci generator above to yield first 10 sequence
for(let val of fibonacci(10)) {
    if(val > 100) break;    // Note 'break' to prevent an infinite loop
    console.log(val)
}

I apologize if the generator expression above is a little complicated, but the most important to note is how we define the expression with an asterik and how we output value using the yield statement.
One more thing to briefly introduce is the Symbol constructor, in javascript, Symbol defines a unique symbol(constant) and ensures it does not coerce with other Symbols of similar construct. For instance,

let bar = Symbol("bar")
let bar2 = Symbol("bar")
bar == bar2    // returns "false"

Notice that the two Symbol definition above does not coerce.
Now, lets assume we creating a custom type we would call Matrix, to store a series of numbers, we would define a custom javascript class thus:

class Matrix {
    constructor(width, height, element = (x, y) => undefined) {
        this.width = width
        this.height = height
        this._content = []

        for(let y=0; y < height; y++) {
            for(let x=0; x < width; x++) {
                this._content[y*width + x] = element(x, y)
            }
        }
    }

    get(x, y) {
        return this._content[y*this.width + x]
    }
}

We can instantiate an 3 by 3 matrix object and pass some arbitrary values thus:

let matrix = new Matrix(3, 3, (x, y) => `x: ${x}, y: ${y}`)

To get through the values defined in the matrix type, a naive approach would look thus;

for(let val of matrix._content) {
    console.log(val)
}

This seems to work, but the underscore which precedes the content instance property should remind us not to access that property directly from outside the class in which it is defined, so how do we make the Matrix type iterable, there are quite a few ways to implement this, but i claim that the generator approach is quite easy to implement and reason about, it goes this:

Matrix.prototype[Symbol.iterator] = function* () {
    for(let y=0; y< this.height; y++) {
        for(let x=0; x < this.width; x++) {
            yield {x, y, value: this._content[y * this.width + x]}
        }
    }
}

// now we can create the object and iterate directly without directly accessing its internals

let matrix2 = new Matrix(3, 3, (x, y) => `x: ${x}, y: ${y}`)
for(let {x, y, value} of matrix2) {
    console.log(x, y, value)
}

What just happened?
First, we defined a property in Matrix prototype named Symbol.iterator, this is what is called when we try to get values from an iterable type inside a loop.

Second, since generator maintains its state everytime we yield from it, we use that to ensure we return appropriate values upon each iteration.

Now, it should be clear how we can use iterators and the less-favoured generator expression to write more robust custom types.

Thanks for reading, would appreciate your feedbacks