DEV Community: Vinyl-Davyl

Migrating 120k+ Lines of Legacy Banking JavaScript to TypeScript with Zero Downtime

Vinyl-Davyl — Tue, 23 Sep 2025 06:27:31 +0000

Migrating a large-scale production application is never a small decision especially when the application in question is powering wallet operations, bill payments and crypto-to-fiat conversions. For context, the system I worked on had grown beyond 120,000 lines of JavaScript, much of it mission-critical and actively serving users with real money flowing through it every single day.

The push to migrate wasn’t just my personal, although I’d long advocated for TypeScript internally. The tipping point came through a combination of colleague feedback, developer pain around ongoing maintenance, and the long-term risks of leaving such a large system in “pure JavaScript mode.”

I should also note that this work was heavily inspired by Ben Howdle. His excellent talk on Letting Go of Perfectionism in Distributed Systems and his write-up on migrating on Production Banking convinced me that it could be done, and done without downtime. What follows is my broken voice and process logged in Git history.

Why We Migrated

In a fintech company, downtime isn’t a minor inconvenience, it’s a direct hit to customer trust and financial operations. Even a brief outage could result in lost transactions or delayed payments, and the limitations of the existing setup were becoming increasingly evident:

Scale & Complexity: As features like virtual cards, crypto conversions, biller integrations, and multiple payment rails kept growing, the codebase became more complex and demanded a stronger foundation.
Developer experience Without types, changing one module often meant fear of breaking another. Code reviews got slower. Even small changes required significant mental load to avoid regressions.
Risk Management: In fintech, errors cost more than just “bugs.” They cost trust, sometimes money (refunds), or regulatory headaches. We wanted earlier detection of issues.
Code stability wasn’t keeping up with scaling. Banking logic has no tolerance for “undefined is not a function” at runtime.

TypeScript promised stronger contracts, compile-time bug detection, and better tooling across the team. The key question wasn’t should we migrate, but rather how can we migrate without disrupting production systems?

The Core Challenges

Migrating 120k+ lines of production code presented three main challenges:

1.** Zero Downtime Requirement**
We could not afford any outage. Users relied on the platform daily for wallet operations, bill payments, crypto-to-fiat conversions and more. Downtime would mean failed transactions, regulatory implications, and broken trust.

Large Codebase
The frontend was built with Next.js, using RTK Query for data fetching and Redux/Context for state management. Testing was done with Jest, RTL, and Cypress. The backend included a Node.js Express API, GraphQL services, and a real-time event processing system. Additional services ran on AWS Lambda and ECS workers, handling tasks like currency conversion and compliance checks.
Parallel Development
The business couldn’t pause feature delivery. New features, bug fixes, and compliance requirements had to continue while the migration was ongoing.

The Migration Strategy

1. Create a Dedicated Migration Branch

At the time, I was in the lead role, stepping back from day-to-day feature and bug work to orchestrate the migration. The first step was to create a separate branch. Every .js and .jsx file in the codebase was renamed to .ts and .tsx, giving us a dedicated environment to work in without disturbing production.

This isolated “migration branch” acted as the staging ground. We could gradually introduce TypeScript features and compiler settings without destabilizing ongoing development.

Pro Tip: Use incremental commits per module instead of one massive push. This keeps changes reviewable and easier to debug.

2. Periodic Rebasing Against Main

Because the main branch continued to move with feature delivery, the migration branch required regular rebasing. This ensured that when the eventual merge happened, conflicts were minimized.

In practice, this meant re-applying TypeScript conversions to any new .js files introduced since the last rebase. A typical cycle looked like this:

git checkout migration-branch
git fetch origin
git rebase origin/main
# resolve conflicts
# convert any new .js/.jsx files to .ts/.tsx

3. Incremental Typing & Module-by-Module Progress

Rather than converting everything at once. Instead, we prioritized incremental typing:

Critical workflows (wallet funding, transfer logic, virtual card issuance).

Core shared utilities (error handling, logging, validation).

Less critical or peripheral features last (UI-facing non-critical modules, internal dashboards).

Loosen tsconfig.json settings at the start (e.g., strict: false) and progressively tighten them.

At some point, we encountered thousands of unique errors (missing types, wrong function signatures, incorrect return types). That was expected. Each error was logged, triaged, and fixed in batches, module by module.

4. CI/CD Integration & Automated Checks

Every rebase triggered our CI/CD pipeline, which ran:

Jest tests. (unit + integration).
Frontend E2E tests (Cypress runs on wallet top-ups, card creation, bill payments).
Type checks via tsc --noEmit.

Nothing hit staging unless it passed the same scrutiny as production.

Testing in Staging: Our Safety Nets

Before we even dreamed of a production merge, staging was our battlefield. We simulated real-world user flows for days top-ups, conversions, card transactions, sometimes even looping “heartbeat transfers” between test accounts just to make sure nothing ever silently failed.

We deployed the TypeScript-converted version to staging (mirroring production services).
For 5-6 days, we ran real-world usage simulations: card creation, payments, wallet funding, conversion, bill payments.
Synthetic transactions were part of the monitoring so we could detect regressions in flows early.

If you’ve never watched a test wallet send $1 back and forth between itself for 48 hours straight, I can assure you it’s the fintech equivalent of a lava lamp: oddly hypnotic, slightly absurd, but incredibly useful.

Fallback / Safe Flags During Deployment

Because not every UI module was migrated at once, we used feature flags and conditional resolution in the frontend. The idea was if a TypeScript-compiled version of a component/page existed, the app would load it; otherwise, it would fall back to the legacy JavaScript version.

This gave us granular control during rollout, so unfinished modules didn’t block deploys and we could safely rebase our migration branch onto main without risking a broken build.

Here’s a representative snippet from one of our entry points:

// utils/loadModule.ts
export async function loadModule(moduleName: string) {
  try {
    return await import(`../dist/${moduleName}.js`);
  } catch {
    return await import(`../src/${moduleName}.js`);
  }
}

This progressive bootstrapping let us ship continuously without waiting for “100% TypeScript.”

Cutover: The Zero Downtime Merge

Once staging ran clean for days, we merged the branch and deployed.🪔 Thanks to f*eature flags, our CI/CD guardrails, and fallback loaders*, the cutover was smooth. Users never noticed the tectonic shift happening under their accounts.

Results: What We Gained (and What Hurt)

Gains

Developer confidence rose sharply. With TypeScript, many bugs got caught before QA or staging.
Maintenance cost dropped, especially for refactors, less “fear-driven development.” I call this one FDD.
Code readability and shared understanding improved: new engineers on the team could follow contracts via types.

Hard Parts

The initial error list was overwhelming. Prioritization was critical.

Rebasing often created merge conflicts (especially around shared utilities). Sometimes took many hours.

Some third-party libraries had poor typings or none, which meant writing our own .d.ts or wrapping them.

Tools & Key Configurations

Several tools proved invaluable during the migration:

Typescript Hero and TypeScript Import Sorter: import management.
Code transformation tools (ts-migrate) to automate tedious parts (renaming imports, updating require → import).
Feature flags / dynamic module loading as above snippet to allow mixing old and new code safely.
ESLint with TypeScript plugin. Enforced consistent style and caught many import/exports mistakes early.
Jest + type checking in CI. Ensured types and tests both passed.

Conclusion: Was it worth it?

100%. Migrating a large-scale production banking system from JavaScript to TypeScript is not trivial. It requires planning, discipline, and collaboration across the engineering team. But the payoff is clear: safer code, happier developers, and a platform that can scale confidently.

For us, the migration took roughly one month plus of focused effort. It was challenging but ultimately transformative.

I want to credit Ben Howdle for openly sharing his own journey, which directly influenced our approach. If you’re considering such a migration, I encourage you to study his experience as well.

_TypeScript isn’t just about types, it’s about trust. Trust that your system will behave consistently under load, trust that developers can make changes without fear, and trust that users’ money remains safe.
_
If your fintech or enterprise platform is still operating at scale in plain JavaScript, the time to consider migration is now.

Google Summer of Code: Getting Selected, My Time, My Experience, My Journey.

Vinyl-Davyl — Sat, 28 Dec 2024 09:49:17 +0000

Beginnings in Engineering and Passion for Creation

I am David Okononfua, and I majored in Electrical and Electronics Engineering in Nigeria. Growing up, I always had a penchant for building things, whether it was a small contraption or a digital product. My academic journey in engineering only fueled this passion, giving me the tools to understand complex systems and the drive to explore new horizons.

Beyond academics, I found joy in coding, which allowed me to develop tools, libraries, and products that brought ideas to life. It became a medium through which I could create and innovate. My enthusiasm wasn't limited to technology; I participated in hackathons and even dabbled in Capture the Flag (CTF) competitions, lol. The thrill of solving problems, collaborating with others, and creating something tangible kept me going.

Outside tech, I have a deep love for football—a sport that I enjoy playing physically and one I can discuss passionately for hours. I also play the saxophone, an instrument that allows me to express myself musically, and chess, a game that sharpens my strategic thinking. This combination of interests—both technical and recreational—shaped my identity as someone who seeks balance and fulfillment in multiple dimensions of life.

The First Encounter: OSCAFEST and the Open Source World

It was in 2022 when I attended a transformative event called OSCAFEST (Open Source Community Africa Festival) in Lagos. This was a major milestone in my journey toward open source. At OSCAFEST, I met like-minded individuals who shared the same passion for technology and collaboration. Among them was Favour, a fellow Electrical Engineering student who was in the same academic level as me. Favour and I clicked instantly; our shared background and interests created an immediate bond. We talked about tech, work, life outside school, and various opportunities and platforms. Learned about Community Pro and EddieHub—a community that helps beginners contribute to open source.

The event itself was a vibrant introduction to the power of open source—the idea that people from around the world could work together to solve problems and build better tools. It was a revelation that coding wasn't just about individual brilliance but also about collective effort. While I heard mentions of Google Summer of Code (GSoC) during OSCAFEST, I didn’t pay much attention at the time. However, the seeds of curiosity had been planted.

Understanding Open Source

Open source refers to software projects where the source code is publicly available. This allows anyone to view, use, modify, and distribute the code, provided they adhere to the licensing terms. Open source promotes collaboration and transparency, enabling developers worldwide to contribute, learn, and share knowledge.

Popular examples of open-source software: Linux, Firefox, VLC Media Player and more.

Some Benefits of Open Source:

Collaboration: Open-source projects enable global collaboration, breaking geographical barriers.

Learning: Contributors gain real-world experience in coding, debugging, and problem-solving.

Community: These projects foster strong, supportive communities.

Quality & Innovation: With constant contributions, open-source projects often achieve high quality and foster innovation.

Basics of Contributing to Open Source

Open-source collaboration thrives on platforms such as GitHub, GitLab, and Bitbucket, where developers come together to improve software projects. Understanding the key concepts is essential when contributing to these projects.

At the core of open-source contributions are issues, which serve as a way to highlight bugs, request new features, or propose enhancements. Contributors engage with these issues to help maintainers understand what needs attention.
Once contributors find areas to work on, they create a fork, a personal copy of the project’s repository. This lets them make changes without affecting the original project. Changes are made in branches, which are separate spaces for developing new features or fixes.
Each change is captured in a commit, documenting what was changed and why. These commits form a pull request (PR), the formal way to propose updates to the main project. Maintainers review PRs to ensure they meet the project's standards before merging them into the main codebase.
In open-source projects, documentation is vital. It helps users and contributors understand the project. For newcomers, improving documentation is a great start, as it requires understanding the software without needing to write code.

By engaging with these processes, contributors not only improve the software but also gain valuable experience in teamwork, problem-solving, and collaboration.

A Turning Point: Learning About GSoC

Fast forward to the following year, Favour told me during one of our conversations that she had successfully participated in GSoC. She explained how the program not only paid contributors for their work but also offered a platform to grow and make meaningful contributions to open source. This was a lightbulb moment for me. I had been contributing to open source for years without compensation, purely out of passion. The idea of getting paid to do what I love was both exciting and motivating. I decided then and there to put in the effort and apply for GSoC in the next cycle.

The process began with researching organizations that aligned with my technical stack. When the list of participating organizations was released, I carefully evaluated each one. Initially, I started with 15 organizations and narrowed them down to 7, then 5, and finally 2. My criteria for narrowing down included the activity level of their communities, the number of open pull requests, and whether I could make a significant impact. For example, one project had over 150 open pull requests, signaling a slim chance of getting noticed to me.

Eventually, I chose Accord Project, an organization under DocuSign that focuses on agreements, contracts, and document automation. Their mission and technical challenges aligned perfectly with my skills and interests.

Immersing Myself in Accord Project

Once I decided on Accord Project, I immediately began contributing to their codebase. Time was of the essence since the application deadline was approaching. I became active in their community, messaging mentors directly to introduce myself and establish a connection. My contributions included opening and merging multiple pull requests, fixing bugs, and adding features—actions that showcased my dedication and technical ability.

The Accord Project's work fascinated me. They were building tools that powered critical aspects of DocuSign’s operations, focusing on automating contracts and agreements. It felt rewarding to contribute to a project that had real-world applications and was making a difference.

As the application deadline loomed, I drafted my proposal meticulously. I outlined my goals, the value I intended to bring to the organization, and the skills I’d leverage to achieve them. After submitting the proposal, the waiting period was nerve-wracking. On the result day, I was ecstatic to learn that I had been accepted into GSoC. It was my first attempt, and the joy was indescribable. All the effort, sleepless nights, and determination had paid off.

How I Got in, How you can possibly get in.

1. Choosing the Right Organization

When the organizations participating in GSoC were announced, I carefully evaluated them to find the best fit for my skills and interests. Here’s how I narrowed down my options:

Started with 15 organizations: I looked for active organizations with year-round contributions, not just during GSoC.
Filtered to 7: I ensured the organizations matched at least 30% of my tech stack, making it easier to contribute.
Reduced to 5: I checked the activity level of their GitHub repositories, focusing on those with manageable pull requests (PRs).
Finalized 2: I assessed their community engagement and mentor responsiveness.
Chose Accord Project: Accord Project’s work on contract agreements and documents resonated with me, as it involved building tools used by DocuSign.

2. Contributing to the Codebase

I began contributing to Accord Project even before the GSoC application period opened. I explored their repositories, fixed issues, and interacted with mentors. By the time applications closed, I had multiple PRs merged and had built a solid reputation within the community.

3. Writing the Proposal

Creating a proposal was a meticulous process. I followed these steps:

Thoroughly studied the project I wanted to work on.
Collaborated with mentors to refine my ideas.
Drafted a clear, concise proposal outlining the problem, solution, timeline, and deliverables.

4. Submitting the Proposal and Waiting

After submitting my proposal, I anxiously awaited the results. On the day the results were announced, I couldn’t contain my joy—I had been selected on my first try!

Tips for Aspiring GSoC Contributors

Research Organizations: Use resources like GSoC Organizations to explore participating organizations.

Look for active organizations with a strong track record.

Align your interests and skills with their projects.

Be Active in the Community: Contribute to discussions, join forums, and connect with mentors. Visibility and engagement are crucial.
Start Early: Begin contributing to the organization’s codebase before the application period.
Create a Strong Proposal: Tailor your proposal to the organization’s needs. Clearly define your goals, timeline, and approach.
Stay Persistent: If your chosen organization or project isn’t selected, don’t be discouraged. Your contributions and experience will still hold value.

The GSoC Experience

Participating in Google Summer of Code was a transformative experience. It challenged me to grow as an engineer and collaborator. Working with Accord Project meant I was essentially collaborating daily with the directors of engineering at DocuSign and the DocuSign engineering team. I was tasked with building and improving tools that streamlined document workflows, specifically a template playground in my case. The work required not just technical expertise but also communication and teamwork skills. I interacted with mentors and community members, learning from their vast experience and gaining insights into open-source best practices.

One of the most rewarding aspects was seeing my contributions make an immediate impact. The pull requests I opened were reviewed, merged, and deployed, becoming part of a tool that people relied on. This sense of purpose fueled my passion for open source even further.

Reflections and Future Aspirations

Looking back, my journey into open source and GSoC was shaped by a combination of curiosity, determination, and community support. From attending OSCAFEST and meeting Favour to contributing to Accord Project and succeeding in GSoC, each step was a learning experience. It taught me the value of persistence, the importance of collaboration, and the joy of creating solutions that help others.

Today, I aim to continue building performant, accessible, and feature-rich applications as a professional Frontend Engineer. My experience spans developing applications across multiple APIs, third-party integrations, and databases, designing beautiful user interfaces, and scaling web products. I strive to leverage these skills to make meaningful contributions, whether in open source or professional settings.

As I look to the future, I am excited about the possibilities. Open source has shown me that technology can be a force for good, and I’m committed to being part of that change. Whether it’s contributing to impactful projects, mentoring newcomers, or exploring new technologies, I’m ready to embrace the challenges and opportunities ahead.

References

To further explore and gain insights into open-source contributions and programs like Google Summer of Code, here are some useful resources:

GSoC: Accord Project Template Playground Development
My blog post detailing my experience and work on the Accord Project Template Playground during GSoC 2024.
Podcast: Cracking GSoC – How David Succeeded on His First Try
A podcast episode where I was featured, sharing my journey, strategies, and tips for succeeding in GSoC on my first attempt.
Accord Project Website
Learn more about the Accord Project, its open-source initiatives, and how it fosters innovation in the legal tech space.
Open Source Internship Programs – YouTube Video
A helpful video discussing various open-source internship opportunities available for aspiring developers.
All About Google Summer of Code – YouTube Video
An informative video that provides an overview of GSoC, its processes, and tips for getting selected.

What Are Web Workers and How to Leverage Them for Optimized Frontend Performance

Vinyl-Davyl — Mon, 23 Dec 2024 09:27:16 +0000

Hello guys, Vinyl here again! 👋

Welcome back to my blog. I know it's been a while, but I’m excited to share some of my latest findings and learnings while working on one projects I’ve been on with this year — a template playground used to draft, test, and experiment with smart legal contracts and documents. Today, we’ll dive into Web Workers: what they are, how they work, and how you can use them to supercharge your frontend projects.

Okay so let’s imagine you’re at a bar to get some beer right, and the bartender (your main thread) has to take orders, prepare the order, and clean the counter all at once. If they’re busy brewing a complicated order (heavy computation), everyone else in line has to wait—frustrating, right? Now imagine the bartender has an assistant (a Web Worker) who takes care of cleaning and organizing the pint glasses in the background while the bartender focuses on taking and making orders. This teamwork ensures smoother operations.

That’s just a short overview. I know you might thinking an API from the description lol, No, they are not! Let’s dive right in.

What Are Web Workers?

Web Workers in web development are exactly like that assistant. They handle heavy-lifting tasks in the background, freeing the main thread to keep your app responsive and smooth. In this article, we’ll dive into Web Workers, explore their key functions, explain how to navigate them, and use three real-world scenarios to demonstrate their power in frontend development. I’ll also give tips for using Web Workers in other frameworks like Vue because the primary use case here would be React.

The Three Types of Web Workers

Before diving into how to use Web Workers, let’s understand the three main types:

Dedicated Workers: These are specific to a single script and are the most commonly used workers. They’re perfect for tasks like background computations or handling API calls for one app instance.

Example: Compressing data for a specific user session.

Shared Workers: These can be shared between multiple scripts or browser tabs, making them ideal for tasks that need cross-tab communication, such as syncing data across tabs.

Example: Keeping user session data consistent across multiple browser tabs.

Service Workers: Unlike Dedicated and Shared Workers, these intercept network requests and act as a proxy between your app and the network. They’re commonly used for caching and offline support.

Example: Serving cached templates when a user is offline.

You can read more about these types in MDN’s Web Workers Documentation.

To know which worker to use, consider the scope of your task:

Use Dedicated Workers for isolated, single-script tasks.
Use Shared Workers for multi-tab communication.
Use Service Workers for network-related tasks like caching or offline capabilities.

The key advantage of Web Workers is their ability to offload these tasks from the main thread, ensuring a smooth user experience. Communication between the main thread and the worker occurs via a messaging system using the postMessage and onmessage APIs.

Key Web Worker Functions

onmessage: Handles messages sent from the main thread to the worker.

self.onmessage = (event) => {
  console.log('Message received from main thread:', event.data);
};

postMessage: Sends messages from the worker back to the main thread.

self.postMessage('Task completed');

terminate: Stops the worker from running.

worker.terminate();

Error Handling: Catches errors in the worker.

self.onerror = (error) => {
  console.error('Worker error:', error.message);
};

Other useful functions include importScripts for loading external scripts, self.close for shutting down the worker, and setTimeout/setInterval for timed operations. Refer to the documentation for further details if needed.

Example Use Cases in a Web Playground Project

Here are three practical scenarios where Web Workers can significantly enhance the sample Template Playground project:

Case 1: API Calls for Templates Data

Fetching templates data from APIs can result in huge datasets that need to be parsed before use. This can block the UI thread if done directly.

1. Create the Worker File: Create dataParser.worker.js.

// dataParser.worker.js
self.onmessage = (event) => {
  const { rawData } = event.data;
  const parsedData = rawData.map((template) => ({
    name: template.name,
    tag: template.tag,
  }));

  self.postMessage(parsedData);
};

2. Use the Worker in React:

import React, { useState } from 'react';

export default function templateDataParser({ rawData }) {
  const [parsedData, setParsedData] = useState([]);

  const parseData = () => {
    const worker = new Worker(new URL('./dataParser.worker.js', import.meta.url));
    worker.postMessage({ rawData });

    worker.onmessage = (event) => {
      setParsedData(event.data);
      worker.terminate();
    };
  };

  return (
    <div>
      <button onClick={parseData}>Template Parsed Data</button>
      <pre>{JSON.stringify(parsedData, null, 2)}</pre>
    </div>
  );
}

Case 2: URL Compression and Decompression

To allow users to share their templates via compact URLs, Web Workers can handle the compression and decompression efficiently.

1. Create the Worker File: Create urlCompressor.worker.js.

// urlCompressor.worker.js
import LZString from 'lz-string';

self.onmessage = (event) => {
  const { action, data } = event.data;
  let result;

  if (action === 'compress') {
    result = LZString.compressToEncodedURIComponent(data);
  } else if (action === 'decompress') {
    result = LZString.decompressFromEncodedURIComponent(data);
  }

  self.postMessage(result);
};

2. Use the Worker in React:

import React, { useState } from 'react';

export default function URLCompressor({ template }) {
  const [compressedURL, setCompressedURL] = useState('');

  const compressTemplate = () => {
    const worker = new Worker(new URL('./urlCompressor.worker.js', import.meta.url));
    worker.postMessage({ action: 'compress', data: template });

    worker.onmessage = (event) => {
      setCompressedURL(event.data);
      worker.terminate();
    };
  };

  return (
    <div>
      <button onClick={compressTemplate}>Compress Template</button>
      <pre>{compressedURL}</pre>
    </div>
  );
}

Case 3: Handling Loading Animations for Templates

While loading multiple templates, Web Workers can process metadata or configurations asynchronously.

1. Create the Worker File: Create templateLoader.worker.js.

// templateLoader.worker.js
self.onmessage = (event) => {
  const { templates } = event.data;
  const loadedTemplates = templates.map((template) => {
    return { ...template, loadedAt: new Date() };
  });

  self.postMessage(loadedTemplates);
};

2. Use the Worker in React:

import React, { useState } from 'react';

export default function TemplateLoader({ templates }) {
  const [loadedTemplates, setLoadedTemplates] = useState([]);

  const loadTemplates = () => {
    const worker = new Worker(new URL('./templateLoader.worker.js', import.meta.url));
    worker.postMessage({ templates });

    worker.onmessage = (event) => {
      setLoadedTemplates(event.data);
      worker.terminate();
    };
  };

  return (
    <div>
      <button onClick={loadTemplates}>Load Templates</button>
      <pre>{JSON.stringify(loadedTemplates, null, 2)}</pre>
    </div>
  );
}

These are three scenarios where Web Workers can improve your work. Feel free to try them in your own project and experiment.

Tips for Using Web Workers in Other Frameworks

Vue: Use the worker-loader plugin and call the worker within Vue components.

Angular: Leverage Angular’s built-in Web Worker support with the ng generate web-worker command.

Svelte: Use the vite-plugin-svelte loader to import and use workers seamlessly.

Conclusion

Viola, You’ve definitely come to the end now! 🎉 Web Workers are like your app’s secret assistants right, quietly handling the heavy lifting while your main thread focuses on providing a great user experience. By using Web Workers in scenarios like URL compression, API calls, and data preprocessing and more, you can significantly improve your app’s responsiveness and make the experience smoother for your users.

So, don’t wait—start experimenting with Web Workers today and unlock the full potential of your web applications! See you next time! 👋

References

The Ultimate Guide to Styling with CSS-in-JS Using Styled Components

Vinyl-Davyl — Mon, 13 May 2024 12:33:58 +0000

Hello There! Welcome back to my page. Whether you're a seasoned follower or a first-time visitor, I'm thrilled to have you here.

Today's drill is guaranteed to pique your interest, trust me; The Ultimate Guide to Styling with CSS-in-JS Using Styled Components. We'll delve into the world of writing CSS directly within JavaScript, exploring the power, efficiency, and flexibility this approach offers in styling for your React applications.

Introduction:

Okay let's imagine styling our web applications is like preparing a dish. You have a pantry full of ingredients (styles) and a recipe (HTML structure) to follow. But instead of traditional pots and pans, you wield a magic wand 🪄 that lets you conjure up your culinary creations effortlessly. This is the magic of CSS-in-JS, particularly when wielded with the power of Styled Components.

In this comprehensive article, I'll guide you through setting up and utilizing Styled Components, exploring visual and practical examples, and unleashing the full potential of this powerful styling methodology.

Why CSS-in-JS? Defeating the Cascading Stylesheet Monster

CSS-in-JS provides a more “atomic” way to scope styles taking only to the components that use them. On the other hand, Traditional CSS can be a double-edged sword. While it offers fine-grained control over styling, it also introduces challenges like:

Specificity Wars: Naming conflicts and style overrides can lead to a tangled mess of CSS code, making maintenance a nightmare.
Global Scope Pollution: Global styles can unintentionally affect unrelated parts of your application.
Component Reusability Woes: Styling components becomes cumbersome as styles are scattered throughout your codebase.

CSS-in-JS tackles these issues by integrating styles directly within your JavaScript components. Offers several advantages like Dynamic Styling and Improved Maintainability and Reusability.

💡 Styled-Components cannot be directly used in HTML and CSS for a few reasons like it being a library designed for React/JavaScript libraries, specifically designed to integrate CSS styling within React components. It utilizes React's component structure and features like JSX syntax.

See here, benefits of CSS-in-JS

Getting Started with Styled Components

Installation and setup

Here's what you'll need to get started with Styled Components:

React Setup: Ensure you have a basic React project set up. You can use tools like Create React App to streamline this process (https://create-react-app.dev/).

Styled Components Installation: Install the Styled Components library using npm or yarn:

npm install styled-components

Once installed, you can import Styled Components into your project and start using them right away.

Deep Dive, Basic Syntax and Usage

Basic usage and syntax

Styled Components leverage tagged template literals to define styles. Here's a basic example of creating a styled button component:

import styled from 'styled-components';

const Button = styled.button`
  background-color: #007bff;
  color: #fff;
  padding: 0.5rem 1rem;
  border: none;
  border-radius: 4px;
  cursor: pointer;
`;

const MyComponent = () => {
  return <Button>Click me</Button>;
};

Creating styled components
Styled Components allow you to create custom styled versions of HTML elements or reusable component primitives, For example;

const StyledDiv = styled.div`
  background-color: #f0f0f0;
  padding: 1rem;
`;

const MyComponent = () => {
  return <StyledDiv>Hello, world!</StyledDiv>;
};

With Styled Components, the possibilities are endless. You can style any component or HTML element just like you would with traditional CSS, but with the added benefits of scoping and reusability.

Styled Components in Action: Building Common UI Elements (with Illustrations)

Now that we've grasped the core concepts, let's explore how Styled Components can be used to style various UI elements here:

Buttons: As seen in the previous example, Styled Components excel at creating reusable buttons with customizable styles.

Cards: Build visually appealing and informative cards using styled components.

Avatar Image: Create styled Avatar Image for the card.

import styled from "styled-components";

const Card = styled.div`
  background-color: #fff;
  border-radius: 4px;
  box-shadow: 0 2px 4px rgba(0.1, 0.1, 0.1, 0.2);
  padding: 20px;
  margin: 10px;
`;

const CardTitle = styled.h2`
  font-size: 1.2em;
  margin-bottom: 10px;
  align-item: center;
  text-align: center;
`;

const CardContent = styled.p`
  margin-bottom: 10px;
`;

const Button = styled.button`
  padding: 10px 20px;
  background-color: #007bff;
  color: #fff;
  border: none;
  border-radius: 4px;
  cursor: pointer;
`;

const AvatarImage = styled.img`
  margin: 0px 20px 0px 0px;
  height: 40px;
  border-radius: 50%;
  display: block;
  margin: auto;
`;

function ProductCard() {
  return (
     <Card>
    <CardTitle>James Washington</CardTitle>
    <AvatarImage
      src="https://miro.medium.com/v2/resize:fit:740/1*ooOH6jo8I0ns0J-BE0SAow.jpeg"
      alt={name}
    />
    <CardContent>
      Imagine styling your web applications like preparing a dish. You have a
      pantry full of ingredients (styles) and a recipe (HTML structure) to
      follow. But instead of traditional pots and pans, you wield a magic wand
      🪄 that lets you conjure up your culinary creations effortlessly. This
      is the magic of CSS-in-JS, particularly when wielded with the power of
      Styled Components.
    </CardContent>
    <Button>Try Now</Button>
  </Card>
  );
}

Live Preview🛠️:

Explore the live preview in this sandbox environment. Feel free to experiment and apply various styling techniques within the playground.

As an Engineer, while building and as my projects grew in complexity, I recognized the value of reusable components for streamlining development. This led me to create Vinyl Component Blocks, a component library built using Styled Components as the major styling methodology. Vinyl Component Blocks aims to reduce repetitive tasks associated with UI component creation, promoting efficiency and a more consistent development experience. Feel free to explore the library on GitHub to see its capabilities and how it leverages Styled Components for complex UI architectures.

Check this links for Further Exploration:

Styled Components Official Documentation: Dive deeper into the library's features and API reference: https://styled-components.com/docs
Advanced Techniques with Styled Components: Explore advanced techniques like theming, nesting, and global styles: https://styled-components.com/docs/api
Vinyl Component Blocks: Explore the component library and it's capabilities and how it leverages Styled Components for complex UI architectures. https://github.com/Vinyl-Davyl/vinyl-component-blocks

Styling Strategies with Styled Components

Unleashing the Power of Styled Components: Strategies for Dynamic and Reusable UIs. Styled Components offer a range of features to enhance your styling capabilities:

Global styles vs. component-specific styles

Styled Components offer flexibility in defining both global styles and component-specific styles. Global styles can be defined using the createGlobalStyle API.

import { createGlobalStyle } from 'styled-components';

const GlobalStyles = createGlobalStyle`
  body {
    font-family: 'Roboto', sans-serif;
    background-color: #f8f8f8;
  }
`;

const MyApp = () => {
  return (
    <>
      <GlobalStyles />
      <MyComponent />
    </>
  );
};

While the component-specific styles are encapsulated within individual components. Like the previous example.

This approach allows you to maintain a consistent design system across your application while still benefiting from the modularity of component-specific styles.

Theming and customizing with props

One of the key features of Styled Components is the ability to customize styles based on component props. This is particularly useful for creating reusable components with dynamic styles and theming.

const Button = styled.button`
  background-color: ${(props) => (props.primary ? '#007bff' : '#6c757d')};
  color: #fff;
  padding: 0.5rem 1rem;
  border: none;
  border-radius: 4px;
  cursor: pointer;
`;

const MyComponent = () => {
  return (
    <>
      <Button primary>Primary Button</Button>
      <Button>Secondary Button</Button>
    </>
  );
};

By leveraging props, you can create versatile components that adapt to different use cases without duplicating code.

Nesting: Nest styles within each other for more complex layouts and organization.
Styled System Integration: Leverage popular styling systems like Bootstrap or Material-UI with Styled Components for a unified styling approach.

Beyond Styled Components: Exploring Alternatives

While Styled Components is a popular choice for styling React applications, there are several alternatives worth exploring. Emotion, JSS, and CSS Modules are all viable options, each with its unique features and use cases.

Emotion

Emotion is another CSS-in-JS library that offers similar functionality to Styled Components but with additional features like built-in CSS prop support and automatic vendor prefixing.

JSS

JSS (JSS is great for... inline styles and theming) is a CSS-in-JS library that focuses on inline styles and theming. It provides a powerful API for dynamically generating styles based on component props, making it ideal for building highly customizable UI components.

CSS Modules

CSS Modules is a different approach to styling in React applications that leverages the built-in CSS module support in bundlers like webpack. With CSS Modules, you can write traditional CSS files and import them into your components, enjoying benefits like local scope and automatic class name generation.

Hey, I’m not an expert on every single JavaScript styling library, so take this as you will. The bulk of my experience is with Styled Components. It is an excellent tool popular with most of the works I've done.

Conclusion and Next Steps

Congratulations!🎊 You've now mastered the art of styling with CSS-in-JS using Styled Components. Armed with this knowledge, you can create beautiful and maintainable UI components that bring your web applications to life.

But remember, mastering styling is an ongoing journey. Continue to explore new techniques, experiment with different libraries, and stay up-to-date with the latest trends in frontend development. With dedication and practice. Stay with me also for more updates and contents like this!

Illustrations and References

Ready to conquer the world of styling with CSS-in-JS using Styled Components 💅🏻. Hope to see you next time, Merci!

Understanding the Role of Husky, ESLint and Prettier: Reasons for Adoption and Implementation Guidelines

Vinyl-Davyl — Mon, 14 Aug 2023 04:50:28 +0000

Frontend development has undergone rapid evolution throughout the years, introducing fresh frameworks, libraries, and tools that have streamlined the process of crafting visually appealing and user-friendly web applications. However, due to the escalating complexity of web projects, maintaining code quality, and consistency, and fostering developer collaboration have emerged as a notable challenge. This is where the robust combination of Husky, ESLint, and Prettier proves to be a lifesaver, offering an effective solution to amplify the frontend development workflow. In this comprehensive article, we will delve deep into the rationales behind utilizing this trio, the benefits it brings, and a step-by-step guide on configuring it to create a flawless development experience in general. Yeah! Let's dive right in.

1. Introduction to Husky, ESLint, and Prettier

1.1 Husky

Named after the loyal and sturdy husky dog, Husky is a Git hook manager for frontend developers mostly and developers in general. It helps enforce coding standards and prevent subpar code from being committed to a repository. By integrating Husky into your project, you can define scripts that run automatically before certain Git commands, such as committing or pushing code. This allows you to catch errors, run tests, and perform other pre-commit or pre-push tasks, ensuring that your codebase remains consistent and high-quality. Cool Right?

You should see it as a stern dog, that always barks at you when do something wrong or do not follow its rules.

1.2 ESLint

ESLint is a widely used and configurable linter tool for JavaScript. It analyzes your code statically to identify potential issues, enforce coding standards, and maintain code quality. ESLint comes with a plethora of rules that can be customized based on your project's requirements. This tool not only detects syntax errors but also enforces best practices, ensuring that your code is readable, maintainable, and follows consistent coding conventions.

1.3 Prettier

Code formatting is often a contentious topic within development teams. Prettier solves this challenge by automatically formatting your code according to a predefined style guide. It eliminates debates over coding style, ensuring that your codebase looks neat and uniform. Prettier supports various file formats and can be configured to format code as you write, creating a seamless experience for developers.

2. Why Use the Husky, ESLint, and Prettier Trio?

The combination of Husky, ESLint, and Prettier addresses several pain points in development and offers a multitude of benefits:

2.1 Code Consistency

In collaborative development environments, maintaining a consistent code style across the entire codebase can be challenging. Different developers might have varying coding styles, leading to code that is hard to read and maintain. By integrating ESLint and Prettier through Husky hooks, you can enforce a unified coding style, ensuring that all code adheres to the same set of guidelines. This consistency improves code readability and reduces confusion among developers.

2.2 Error Prevention

Detecting errors and bugs early in the development process is essential for minimizing debugging time and maintaining a high-quality codebase. The Husky, ESLint, and Prettier trio assist in error prevention by running pre-commit and pre-push scripts. ESLint's static analysis capabilities catch issues such as syntax errors, potential bugs, and adherence to coding standards. This proactive approach helps developers identify and rectify problems before they reach the repository.

2.3 Efficient Collaboration

In collaborative projects, differing coding styles can lead to unnecessary conflicts and discussions among developers. Prettier's automated code formatting and ESLint's rule enforcement eliminate the need for manual code formatting and style debates. Developers can focus on writing code and implementing features, knowing that the tools will handle formatting and standards compliance. This enhances teamwork, as the trio reduces friction and allows developers to concentrate on the creative aspects of their work.

2.4 Time Savings

Manually formatting code, identifying and fixing errors, and debating coding standards consume a considerable amount of development time. The trio of Husky, ESLint, and Prettier automates these tasks, freeing up developers to concentrate on innovation and problem-solving. With automated code formatting, time spent on adjusting code style is minimized, and the development process becomes more efficient overall.

As an illustration, consider a scenario where you wish to transition the import style from single quotes to double quotes throughout an entire legacy project to ensure uniformity. Prettier and ESLint can effectively accomplish this task on your behalf. Isn't that great?

3. Setting Up Husky, ESLint, and Prettier: A Step-by-Step Guide

In this section, we'll walk you through the process of setting up the Husky, ESLint, and Prettier trio in your frontend project. We'll cover installation, configuration, and integration with code samples to illustrate each step. Putting the Trio to Work.

3.1 Integrating ESLint

ESLint can be integrated into your project by installing it and configuring its rules. Start by installing ESLint:

# Using npm
npm install eslint --save-dev

# Using yarn
yarn add eslint --dev

Next, initialize ESLint configuration using the following command:

npx eslint --init

Subsequently, inaugurate ESLint configuration using the ensuing command:

npm init @eslint/config

This command will guide you through setting up ESLint and selecting a configuration style. You can choose between popular styles like Standard, XO and more.

After configuration, ESLint will generate a .eslintrc.cjs file with your chosen settings.

3.2 Configuring ESLint

Customizing ESLint rules is essential to align it with your project's coding standards. Open the .eslintrc.cjs file in your

project directory and modify the rules accordingly. For example:

module.exports = {
    "env": {
        "browser": true,
        "commonjs": true,
        "es2021": true,
        "jest": true,
    },
    "extends": "standard",
    "overrides": [
        {
            "env": {
                "node": true
            },
            "files": [
                ".eslintrc.{js,cjs}"
            ],
            "parserOptions": {
                "sourceType": "script"
            }
        }
    ],
    "parserOptions": {
        "ecmaVersion": "latest"
    },
    rules: {
    // Add your custom ESLint rules here
    'no-console': 'warn',
    'no-unused-vars': 'error',
    // ...
  },
}

By defining rules in your ESLint configuration, you can ensure that the codebase adheres to your desired coding conventions.

Then in your package.json file, add the following commands to your scripts:

{
   //...
    "scripts": {
        //...
        "lint": "eslint .",
        "lint: fix": "eslint --fix ."
    },
    //...
}

Subsequently, run the lint command with npm:

npm run lint

Based on the above image, it is evident that several errors are present, particularly within a specific file that doesn't meet ESLint's criteria. Subsequently, we proceed to address these issues individually or utilize the npm run lint:fix command to potentially rectify errors that can be automatically resolved.

For issues that can be rectified, employ:

npm run lint:fix

Notably, certain software, such as CRA (Create React App) and Vite, incorporate ESLint by default, negating the need for a separate setup of ESlint. Alright, give it a try and see if you understand the idea! I hope you did. Excellent, let's proceed. Prettier next!

3.3 Automating Code Formatting with Prettier

Prettier's automatic code formatting can be integrated into your project with a few simple steps:

Install Prettier using npm or yarn:

# Using npm
npm install prettier --save-dev

# Using yarn
yarn add prettier --dev

Create a .prettierrc.js file in your project directory to define your code formatting preferences. For instance:

module.exports = {
  singleQuote: true,
  trailingComma: 'es5',
  useTabs: false,
};

Post-installation of Prettier, add it to plugins and extends in ESLint, allowing it to complement Prettier's formatting.

Ensure the functionality of Prettier by installing the Prettier extension for VSCode.

In the settings, ensure that your default formatter is set to Prettier and enable the "format on save" feature.

And there you have it, whenever you save a file while working on a specific task, Prettier automatically performs its formatting function.

3.4 Installing Husky

Husky can be easily installed using a package manager like npm or yarn. Open your terminal and navigate to your project directory.

One thing to always note is that the concept of Husky revolves around setting up ESLint or performing linting just before or as we prepare to commit. This approach aims to prevent the contamination of the existing code style of another element by executing a pre-commit script, among other considerations. I feel that's great.

Setting up:

# Using npm
npm install husky --save-dev

# Using yarn
yarn add husky --dev

Subsequently, execute:

npx husky init

Once installed, Husky provides a simple yet powerful way to manage Git hooks.

3.5 Configuring Husky Hooks

Husky hooks are scripts that run automatically before specific Git actions. To set up a pre-commit hook that integrates ESLint and Prettier, follow these steps:

Open your project's package.json file.

Add a husky property to define your hooks. Here's an example configuration for running ESLint and Prettier before committing:

{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  }
}

here's an example of a husky pre-commit file, which would be in the generated .husky folder

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged

In this example, lint-staged is a tool that runs linters on staged files. We can then configure lint-staged to run ESLint and Prettier.

3.6 Editor Integration

Integrating Husky, ESLint, and Prettier with your code editor enhances your development experience by providing real-time feedback. Most modern code editors support extensions or plugins for these tools. So just like is specified for prettier, earlier on. Here's how you can integrate them with popular editors:

Visual Studio Code: Install the ESLint and Prettier extensions from the Visual Studio Code marketplace. Once installed, these extensions will automatically apply linting and formatting to your code as you write.

Sublime Text: Use the SublimeLinter-eslint and SublimeLinter-contrib-prettier packages to integrate ESLint and Prettier into Sublime Text.

Atom: Install the linter-eslint and atom-prettier packages to enable linting and formatting in the Atom editor.

By integrating these tools into your code editor, you receive immediate feedback on code quality and formatting, ensuring that your code adheres to standards as you write.

4. Real-world Examples: Putting the Trio to Work

In this section, we'll explore two real-world examples to demonstrate how the Husky, ESLint, and Prettier trio enhances frontend development workflows.

4.1 Example 1: Creating a React Component

Let's consider a scenario where you're creating a React component named Button. With the Husky, ESLint, and Prettier trio in place, your workflow would look like this:

*Writing Code: * As you write the code for the Button component, ESLint provides real-time feedback on potential issues such as syntax errors, unused variables, and adherence to coding standards.

Formatting: Prettier automatically formats your code according to the defined style guide. This ensures that your code remains consistent and follows best practices.

*Pre-commit Checks: * Before committing your changes, Husky's pre-commit hook kicks in. It runs lint-staged, which in turn runs ESLint and Prettier on the staged files. Any errors or formatting issues are caught and displayed.

Committing: With clean code and proper formatting, you can confidently commit your changes, knowing that you're contributing high-quality code to the repository.

4.2 Example 2: Collaborative Project Development

Consider a larger project with multiple developers collaborating on different features. The Husky, ESLint, and Prettier trio becomes invaluable in this scenario:

Pull Requests: When developers create pull requests, the pre-commit and pre-push hooks ensure that the code adheres to coding standards. This minimizes the chances of introducing bugs or inconsistencies.

Code Reviews: During code reviews, ESLint highlights issues that reviewers can address, enhancing the review process's efficiency. Prettier-formatted code is visually consistent, making it easier for reviewers to focus on the logic and functionality.

Continuous Integration: Automated testing and continuous integration pipelines benefit from the trio as well. Code that passes pre-commit and pre-push checks is more likely to pass automated tests, reducing the chances of build failures.

5. Best Practices and Customization

Although the initial configurations offered by ESLint and Prettier are valuable, customizing them to align with your project's unique requirements is crucial. With that said, let's delve into some recommended practices and tips for customization that should unquestionably be part of your toolkit.

5.1 Choosing ESLint Rules

ESLint's extensive collection of rules can be overwhelming. When choosing rules for your project, consider the following:

Project Type: Different project types might have different requirements. For instance, a Node.js backend project might have different ESLint rules compared to a frontend project.

Team Consensus: Collaborate with your development team to define a set of rules that everyone agrees on. This ensures consistency and prevents disagreements later on.

Common Mistakes: ESLint rules can catch common mistakes and potential bugs. Prioritize rules that address issues specific to your codebase.

5.2 Tailoring Prettier Formatting

Prettier offers a wide range of formatting options that you can configure to match your team's preferences. Some customization options include:

Indentation: Set the number of spaces or tabs used for indentation.

Semicolons: Choose whether to use semicolons at the end of statements.

Line Length: Define the maximum line length before Prettier wraps lines.

Quotation Marks: Specify whether to use single or double quotes for strings.

By adjusting these formatting options, you can ensure that Prettier aligns with your project's coding standards and visual preferences.

6. Future Trends and Conclusion

As frontend development continues to evolve, tools like Husky, ESLint, and Prettier are likely to become even more integral to the development workflow. With the increasing emphasis on code quality, collaboration, and efficiency, developers will continue to seek ways to streamline their processes and deliver high-quality web applications.

I'm certain that after reading this article, you should now possess a comprehension of these three components (Eslint, Prettier, and Husky), their functions within the development journey, and the steps involved in setting them up for practical use. This understanding is what truly brings satisfaction to me in crafting this article – the act of sharing this knowledge. Do you agree? Yes lol, Fantastic!

In summary, the Husky, ESLint, and Prettier trio empower frontend developers to produce precise, clean, and faultless code. This combination establishes a benchmark for superior frontend development by upholding coding standards, identifying errors promptly, and automating code formatting. By dedicating effort to tool setup and refinement, developers can unlock project potential and contribute to the development community's advancement.

Keep on building and learning, buddy! For more similar content, do stay connected on my blog. Looking forward to your return.

Till then, Merci!👋

Useful resources I used in this article: Prettier: https://prettier.io/ ESLint: https://eslint.org/ Husky: https://www.npmjs.com/package/husky

How to Deploy a FullStack NodeJs and Express App on Vercel

Vinyl-Davyl — Mon, 05 Jun 2023 18:04:39 +0000

Hello there, Welcome back to my page. Whether you're a returning visitor or visiting for the first time, Voila! I'm more than thrilled to have you here. Recently, I completed a full-stack project named "Talku-Talku".

Although after sharing it with my peers and the public in general, some developer friends of mine informed me that they struggled with deploying the project. As a result, I decided to write this insightful article on deploying a MERN stack project using Vercel. If you're interested in learning how to deploy a full MERN stack app on Vercel, you're right at the spot. Please join me and let's dive right in.

Introduction

Deploying a full-stack NodeJs and Express app on Vercel can seem daunting, especially if you're new to web development. But don't worry! With the right guidance and a fun analogy like I always use, you'll be able to deploy your app in no time.

Imagine that your app is like a pizza. You have all the ingredients (code) ready, and now it's time to bake it and serve it to your customers (users). Vercel Here! Let's take it as a pizza oven – it takes care of all the technical details so that you can focus on making a delicious pizza (bakes the pizza so it can be served to consumers or customers).

In this article, we'll walk through the steps of deploying your NodeJs and Express app on Vercel. And we'll cover everything from setting up your environment to configuring your deployment settings. Ace Up, Let's get started!

First Step: Setting up your environment

Before we dive into deploying our app, let's make sure we have the right tools installed. Here are some of the most important things you'll need:

Node.js and npm: You can download and install Node.js from the official website. Npm comes bundled with Node.js.
Git: This version control system will help you keep track of changes to your code. Download Git from the official website.
A code editor: Choose a code editor that suits your preferences. We recommend Visual Studio Code, which is free and easy to use.
Express.js: The popular web framework for Node.js, It provides several features such as routing, middleware support, and template engine integration, making it easier for developers to build server-side applications and APIs.

Once you have these tools installed, you are one step ahead and almost ready to go. Open the terminal and navigate to your project folder by typing

cd path/to/your/folder

Ensure that both the client and server of your application are ready for development, add another terminal for the server, navigate its server path and run both servers, Your server needs to be connected to your database and listening on the specified port(check out my article to get more insight on connecting your app to a database), while your client should be accessible through the browser on your localhost.

Now that we have our environment set up, let's move on to deploying your app on vercel.

Second Step: Kicking off deployment on Vercel

Now that we have our app up and running locally, it's time to deploy it to Vercel. Here's what you need to do:

Sign up for a Vercel account: If you don't already have a Vercel account, sign up at https://vercel.com/signup.
Install the Vercel CLI: The Vercel CLI is a command-line tool that makes it easy to deploy your app. Install it by running the following command in your terminal: npm install -g vercel
Log in to Vercel

Deploying the Backend or API of your MERN application:

Step 1: Log in to Vercel dashboard and click on the “Add New…” button and select the “Project” category. As you can see here, I'm already logged in and I have quite a number of projects with vercel already deployed.

Step 2: Import your Git repository after linking your Github/Gitlab/BitBucket account with Vercel, In this case, we would be working with "talku-talku-v3" for this article.

Step 3: Configure the backend/server for your MERN application on Vercel

Name your project, such as "my-project-backend"
Select "Other" in the framework option to tailor the setup and customization process to Node.js.
Indicate the backend directory of your project where Vercel will run the build command.

Add any necessary environmental variables, such as MONGO_ATLAS_URL: my-mongo-atlas-url. Note: There could be more than one!

Finally, click on the "Deploy" button.

Step 4: Very Important, Include the provided vercel.json file in your backend/server root directory and then push it to your remote repository. This will enable Vercel configuration.

{
    "version": 2,
    "builds": [
        {
            "src": "*.js",
            "use": "@vercel/node"
        }
    ],
    "routes": [
        {
            "src": "/(.*)",
            "dest": "/"
        }
    ]
}

Congratulations!🎊 Your backend will be up and running within a few minutes after deployment. You should see something like this.

Quick Note: As soon as possible, don’t forget to save the new deployment link of your server. "https://talku-talku-v3-server.vercel.app" in this case, and replace it in your code wherever the local server link was provided.

Deploying the Frontend of your MERN application:

Quite similar to the backend deployment of our app, we follow the same process.

Step 1: Once again, Go to Vercel dashboard and click on the “Add New…” button and select the “Project” category.

Step 2: Import your Git repository after linking your Github/Gitlab/BitBucket account with Vercel, In this case, we would are definitely working with "talku-talku-v3" for this article.

Step 3: Configure the frontend for your MERN application on Vercel

Name your project, such as "my-project-frontend"
Choose "Create-React-App" from the available frameworks to ensure that the configuration and modification procedures are tailored for React.js.
Indicate the frontend directory of your project where Vercel will run the build command.

Add any necessary environmental variables, such as REACT_APP_LOCALHOST_KEY: chat-app-current-user. Note: There could be more than one and you might want to consider adding GENERATE_SOURCEMAP: false for security and performance reasons.

Finally, click on the "Deploy" button once you're done.

Congratulations!🎊 Your frontend will be up and running within a few minutes after deployment. You should see something like this.

Finally, Checking and Allowing CORS policy after deployment

Note: To solve for CORS policy error if one eventually comes up after deployment of your full-stack app, you can install the cors package and use it to allow cross-origin requests from other domains. This can be done by adding the following code snippet to your backend server:

const cors = require('cors');

// Allow all origins
app.use(cors());

// Allow specific origin(s)
app.use(cors({
  origin: 'https://yourdeployedsite.com'
}));

Additionally, you should always check the console for errors, including any CORS errors. This will help you identify and fix any issues that may arise.

Conclusion

Deploying a full-stack Node.js and Express app on Vercel doesn't have to be difficult. By following the steps outlined in this article and using the pizza analogy at the introduction of this article to get a clearer view, you can easily get your app up and running in no time.

After all that's been said and done, don't forget to check out "Talku-Talku-V3" on GitHub. Sign up to chat and send media with friends and foes! Share your review and feedback, and leave a star⭐️ if you find something interesting.

Overall, you should by now have a good understanding of the deployment process for a full-stack MERN app using Vercel, including common challenges and best practices. I sure hope so. Please do follow me for more content and updates like this in the future. Until we meet again.

Merci!!

Getting Started with Solidity, All you need to know (A Step by Step Guide).

Vinyl-Davyl — Wed, 03 May 2023 16:39:05 +0000

Solidity is a high-level programming language used to write smart contracts on the Ethereum blockchain. Smart contracts are self-executing programs that automatically enforce the terms of an agreement between two or more parties.

In this article, we will provide a step-by-step guide on getting started with Solidity. We'll begin by giving a brief introduction to the language and its basic structure, followed by an overview of data types, functions, and events in Solidity. So, let's dive right in and learn how to write smart contracts using Solidity.

Getting Started

To start writing Solidity code, you need to have at least all of the following;

A development environment like Remix or Hardhat: Remix is an online IDE that allows you to write and test Solidity code in your browser, while Hardhat is a local development environment that gives you more control over your development process.
A text editor: This can be any text editor, such as Visual Studio Code, Atom, or Sublime Text.
An Ethereum wallet: You will need to have an Ethereum wallet to deploy your smart contracts to the blockchain. There are several wallets available, including MetaMask and MyEtherWallet.
Solidity compiler: You will need a Solidity compiler to compile your code into bytecode that can be executed on the Ethereum Virtual Machine (EVM). The most popular compiler is the solc compiler.

Basic Structure

A Solidity contract is a collection of functions and data that can be deployed to the Ethereum blockchain. Here's an example of a simple Solidity contract:

pragma solidity ^0.8.0;

contract MyContract {
    uint256 myVariable;

    function set(uint256 _myVariable) public {
        myVariable = _myVariable;
    }

    function get() public view returns (uint256) {
        return myVariable;
    }
}

Hey, Don't Chicken Out! We would explain and go through this together. Cool!👌

In this contract, there is a state variable myVariable, set, get.

This Solidity code creates a smart contract with a single unsigned integer variable called myVariable It has two functions, set and get. The set function takes an argument _myVariable and sets the value of myVariable to it. The get function returns the current value of myVariable. The pragma statement specifies the version of the Solidity compiler to be used.

Cool Right? It's Just the Intro, Let's dive right into data types In solidity.👨‍🍳

Data Types

Here's an explanation of some data types in Solidity with examples

bool : A boolean value that can be either true or false. For example:

bool myBool = true;

int

and uint: These are integer types where int can store negative values and uint can only store positive values. The number after the type determines the number of bits used to represent the value. For example:

int8 myInt8 = -123;
uint16 myUint16 = 12345;

address

: This is a 20-byte variable used to store Ethereum addresses. For example:

address myAddress = 0x1234567890123456789012345678901234567890;

string : This is used to store dynamic string values. For example:

string myString = "Hello, world!";

bytes

: This is used to store byte arrays. For example:

bytes myBytes = hex"0011223344556677";

struct

: A struct is a custom-defined composite type that groups other variables. For example:

struct Person {
    string name;
    uint age;
}

Person myPerson = Person("Alice", 25);

enum

: An enumeration is a custom-defined type that defines a set of named constants. For example:

enum Color { RED, GREEN, BLUE }
Color myColor = Color.RED;

mapping

: A mapping is a key-value store where the keys and values can be of any type. For example:

mapping(address => uint256) balances;
balances[0x1234567890123456789012345678901234567890] = 100;

array

: An array is used to store a collection of values of the same type. For example:

uint256[] myArray = [1, 2, 3];

These are just some of the basic data types available in Solidity. There are more specialized types such as fixed-point numbers, multi-dimensional arrays, and others that you can learn about as you dive deeper into Solidity programming.

Next Up, Functions!✨

Functions

Functions are an essential component of Solidity, allowing developers to define the behavior and functionality of smart contracts. We would go through some key examples of functions in Solidity:

Defining a public function:

pragma solidity ^0.8.0;

contract MyContract {
    uint256 myVariable;

    function set(uint256 _myVariable) public {
        myVariable = _myVariable;
    }

    function get() public view returns (uint256) {
        return myVariable;
    }
}

In this example, we define two functions set and get. The set function is a public function that sets the value of myVariable, while the get function is a public view function that returns the value of myVariable.

Defining a private function:

pragma solidity ^0.8.0;

contract MyContract {
    uint256 myVariable;

    function set(uint256 _myVariable) public {
        myVariable = _myVariable;
        doSomething();
    }

    function doSomething() private {
        // Do something here
    }
}

Here, we define a private function doSomething which can only be called from within the contract (set calls doSomething). Private functions are not visible to external contracts or accounts.

Defining an external function:

pragma solidity ^0.8.0;

contract MyContract {
    function doSomething() external {
        // Do something here
    }
}

Similarly! In this case, we define an external function doSomething. External functions can only be called from outside the contract and not from within the contract itself.

Defining an internal function:

pragma solidity ^0.8.0;

contract MyContract {
    uint256 myVariable;

    function set(uint256 _myVariable) public {
        myVariable = _myVariable;
        doSomething();
    }

    function doSomething() internal {
        // Do something here
    }
}

We define an internal function here, doSomething which can only be called from within the contract or any derived contracts. Internal functions are not visible to external contracts or accounts.

Next Up, Events!✨

Events

Events in Solidity are used to notify external applications or contracts about certain actions that have occurred within a smart contract. They are similar to log messages and can be accessed via the Ethereum blockchain.

Here is an example of how to create and emit an event in Solidity:

pragma solidity ^0.8.0;

contract MyContract {
    event MyEvent(uint256 indexed id, string message);

    function doSomething(uint256 id, string memory message) public {
        // perform some action here

        emit MyEvent(id, message);
    }
}

In this example, we define an event called MyEventwith two parameters: id (an unsigned integer with an index) and message (a string). Within the doSomething function, we perform some action and then emit the event with the appropriate values.

To listen for and respond to events in another contract or application, you can use the web3.js library or a similar tool. Here is an example of how to listen for events emitted by the above contract using web3.js:

const myContract = new web3.eth.Contract(contractABI, contractAddress);

myContract.events.MyEvent({ filter: { id: 123 } })
    .on('data', function(event) {
        console.log(event.returnValues.message);
    })
    .on('error', console.error);

This code creates a new instance of MyContractusing the contract's ABI and address. It then listens for the MyEvent event with an ID of 123 and logs the corresponding message to the console when the event is triggered. If an error occurs, it will also be logged into the console.

Overall, events are a powerful way to communicate information between different parts of a decentralized application or even between different applications on the Ethereum network.

Conclusion

Congratulations, you've successfully taken your first steps into the exciting world of Solidity! Armed with the knowledge of basic structure, data types, functions, and events, you're ready to start building on the Ethereum blockchain like a pro. Get ready to amaze your friends and family with your newfound skills in writing smart contracts - who knows, you might even become the next Vitalik Buterin!🧖‍♂️(Imagination)

This is just an Introductory guide to Solidity, but don't be afraid to dive deep and expand your knowledge! Get friendly with the language, read through the documentation, try building a mini Dapp and maybe you'll even create the next big thing on the blockchain.

Reference

In a blog post for Web3Afrika, I discussed the benefits of using blockchain technology and an Introductory guide on all you need to know to get started with solidity. For more content analysis like this, check out my Personal Page here and follow me here on DevTo.

Until next time, Happy Exploring!

Cheers,

Vinyl-Davyl.