Forem: Martin Wachira

How VS Code Understands Your Code: Inside the Language Server Protocol

Martin Wachira — Sun, 28 Dec 2025 19:10:13 +0000

Have you ever wondered how VS Code knows:

Which variables or functions are available as you type?
When a syntax error appears, even before you save the file?
Where a function or type is defined so you can “go to definition”?
What suggestions to offer for autocomplete or inline documentation?

It’s tempting to think the editor itself “understands” the language. It DOESN'T.

VS Code or any other code editor is just the UI. The real magic happens in the background, in a separate process called a language server, which communicates with the editor to provide language intelligence.

In this article, I’ll take you step by step through how VS Code, a language server like gopls for go, and the Language Server Protocol (LSP) work together, from project startup to shutdown, including how diagnostics, autocompletion, and go-to-definition actually flow through JSON-RPC messages.

Key Terms

Editor (VS Code): The UI client you interact with. Knows about files, buffers, cursors, and how to render things. Knows nothing about the language itself.

Language Server (gopls for Go): A separate process that understands the language, parses code, builds ASTs, resolves symbols, checks types, and generates diagnostics.

Language Server Protocol (LSP): A protocol (a contract) defining how the editor and language server communicate. Specifies messages, request/response rules, notifications, and data structures.

JSON-RPC: The transport format used to send LSP messages. Defines a structured, language-agnostic way to send notifications and requests between editor and server.

High-Level Send/Receive Workflow

Here’s how information flows in clear send/receive terms:

At this point, you have a mental model: your keystrokes travel through the editor, are translated into structured messages, processed by the language server, and the results are sent back to render the UI.

Section 1: Process Startup and the Initialize Handshake

Before the workflow above can happen, there’s an important setup phase. When you open a project, VS Code must start the language server and agree on what each side can do.

1.1 Process Startup

VS Code spawns gopls either via --stdio (most common) or over TCP sockets.

gopls runs as a long-lived background process, continuously reading messages from stdin and writing to stdout.

The editor never blocks while the server is processing — all communication is asynchronous.

1.2 Transport: JSON-RPC Language-agnostic protocol for message passing

LSP uses JSON-RPC 2.0

Messages are framed with headers (Content-Length) and a JSON body

Example notification (didOpen) from VS Code to server:

Content-Length: 143
{
  "jsonrpc": "2.0",
  "method": "textDocument/didOpen",
  "params": {
    "textDocument": {
      "uri": "file:///home/user/main.go",
      "languageId": "go",
      "version": 1,
      "text": "package main\nfunc main() {}"
    }
  }
}

method: Name of the LSP request or notification

params: Data required for the request

id: Only used for requests, not notifications

1.3 The Initialize Request

Before the server can handle edits or queries, VS Code must initialize it by sending an initialize request over JSON-RPC.

It Provides:

Client capabilities (what editor supports: completion, hover, etc.)
Workspace info (root path, folders)
Initialization options (language-specific configs)

JSON-RPC Example:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "processId": 12345,
    "rootUri": "file:///home/user/project",
    "capabilities": {
      "textDocument": {
        "completion": {
          "completionItem": {
            "snippetSupport": true
          }
        },
        "hover": {},
        "definition": {}
      },
      "workspace": {
        "configuration": true
      }
    },
    "clientInfo": {
      "name": "Visual Studio Code"
    }
  }
}

Server Response

The server responds with its capabilities — telling the editor what it can handle:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "capabilities": {
      "textDocumentSync": 2,
      "hoverProvider": true,
      "completionProvider": {
        "resolveProvider": true,
        "triggerCharacters": ["."]
      },
      "definitionProvider": true
    }
  }
}

textDocumentSync: 2 → incremental synchronization supported

Editor now knows which features it can safely request from the server.

1.5 Key Concepts

Requests vs Notifications

LSP defines two classes of messages:

Requests expects a response and represent explicit queries (e.g. initialize, textDocument/hover, textDocument/definition)
Notifications do not expect a response and are used to update server state (e.g. textDocument/didOpen, textDocument/didChange)

This distinction allows the editor to push state changes without blocking while still issuing targeted queries when results are required.

Capability Negotiation

During initialization, the editor and server exchange supported capabilities.

The editor only sends requests for features the server has explicitly declared, preventing invalid calls and unnecessary work. This negotiation defines the contract for the entire session.

JSON-RPC Transport

All communication is framed using JSON-RPC.

This provides:

A consistent request/response model
Explicit message IDs and ordering
A language-agnostic transport independent of editor or server implementation

JSON-RPC is a transport choice, not a language feature; all semantics live at the LSP layer above it.

1.6 Send/Receive Flow For The Initialize Request

At this stage, the server is ready to accept text document events (didOpen, didChange) and handle requests like hover, completions, and definitions.

Section 2: Document Lifecycle: How Editors Keep Language Servers in Sync

The Language Server Protocol is push-based. The server never “checks” files or polls the filesystem. Instead, the editor continuously pushes document state so the server can maintain an accurate in-memory model of the code — even when that code does not yet exist on disk.

These notifications define that lifecycle.

1. textDocument/didOpen

Sent when a document is opened in the editor.
Contains the entire file content.

This event establishes the editor’s buffer as the authoritative source of truth. From this point on, the language server reasons about the in-memory text, not the filesystem.

For servers like gopls, this is where:

The file is parsed into an initial AST
The file is associated with a package and module
Baseline diagnostics (syntax, imports) are produced
Disk state is explicitly secondary.

2. textDocument/didChange

Sent on every edit.
Can contain full text or incremental changes.

This is the most performance-critical notification in LSP.

Modern editors send incremental edits, allowing the server to:

Update only affected text ranges
Reuse unchanged AST subtrees
Invalidate and recompute analysis selectively

Without this mechanism, features like real-time diagnostics, autocomplete, and go-to-definition would be prohibitively expensive.

3. textDocument/didClose

Sent when the user closes a document.

Signals the end of active editing.

Closing a document does not mean the file disappears from analysis. It means the server can:

Release editor-specific buffers
Drop incremental parsing state
Deprioritize diagnostics for that file

The file may still be loaded via disk if referenced elsewhere in the workspace.

4. textDocument/didSave (optional)

Sent when in-memory content is written to disk.
Often used to trigger disk-oriented work.

This notification exists because some tools care about persisted state, not transient buffers. On save, servers may run:

Formatting
Full package type-checking
Vet-style or static analysis passes

Because save semantics vary across editors, this notification is optional in the protocol.

The invariant

At all times:

The language server’s understanding of the program is driven by editor events, not by reading files opportunistically.

This design is what allows LSPs to reason about code that is incomplete, syntactically broken, or not yet saved — while still providing rich, real-time tooling.

2.1 Example: Opening a Go File

When a user opens a Go file, VS Code sends a textDocument/didOpen notification:

{
  "jsonrpc": "2.0",
  "method": "textDocument/didOpen",
  "params": {
    "textDocument": {
      "uri": "file:///home/user/main.go",
      "languageId": "go",
      "version": 1,
      "text": "package main\n\nfunc main() {}"
    }
  }
}

The version field establishes the starting point for all subsequent edits and increments with every change.

On receipt, the language server creates an internal document model for this file. From this point forward, all analysis is performed against this in-memory model, which is updated as edits arrive.

2.2 Incremental Updates (didChange)

Sending the entire file on every keystroke would be wasteful, so LSP supports incremental updates.

Each didChange notification includes:

A range indicating the affected portion of the document
The replacement text
An updated document version

Example:

{
  "jsonrpc": "2.0",
  "method": "textDocument/didChange",
  "params": {
    "textDocument": {
      "uri": "file:///home/user/main.go",
      "version": 2
    },
    "contentChanges": [
      {
        "range": {
          "start": { "line": 2, "character": 0 },
          "end":   { "line": 2, "character": 0 }
        },
        "text": "    fmt.Println(\"Hello\")\n"
      }
    ]
  }
}

The editor sends only what changed, not the entire file.

2.3 Why the Server Maintains a Full In-Memory Copy

Although updates are incremental, the server always maintains a complete copy of the document.

When a change arrives, the server:

Applies the edit to its in-memory buffer
Updates the document version
Re-runs parsing and analysis as needed

Crucially, analysis is performed against the entire file, not just the modified region. Incremental updates are an optimization for how changes are applied, not a restriction on what the server understands.

This design enables:

Incremental parsing (only affected syntax nodes are reprocessed)
Whole-file diagnostics
Accurate hover, completion, and navigation anywhere in the file

2.4 Diagnostics as a Server Push

After applying a change, the server may publish diagnostics back to the editor:

{
  "jsonrpc": "2.0",
  "method": "textDocument/publishDiagnostics",
  "params": {
    "uri": "file:///home/user/main.go",
    "diagnostics": [
      {
        "range": {
          "start": { "line": 2, "character": 4 },
          "end":   { "line": 2, "character": 15 }
        },
        "severity": 1,
        "message": "undefined: fmt",
        "source": "gopls"
      }
    ]
  }
}

The editor does not interpret these diagnostics. It simply maps ranges to UI elements such as red squiggles or hover messages.

All of this happens asynchronously; the editor remains responsive while analysis runs in the background.

2.5 Key Observations

Incremental updates reduce overhead but do not limit analysis scope
Versioning prevents out-of-order or stale edits
The server always reasons about a complete document
The editor never analyzes code; it forwards changes and renders results
Communication is asynchronous and JSON-RPC based

With an up-to-date internal model of the document, the server can now answer targeted requests such as hover, completion, and go-to-definition.

Next, we will examine how those requests flow through LSP and how the server responds to them.

Section 3: Hover, Completion, and Go-to-Definition

Once the language server maintains an up-to-date internal model of the workspace, the editor can issue targeted requests for language information such as hover details, code completion, and symbol navigation.

Unlike document lifecycle events, these interactions are requests, not notifications: the editor expects a response.

3.1 Hover (textDocument/hover)

A hover request is sent when the user points at a symbol in the editor.

The request identifies:
The document
The cursor position

The server resolves the symbol at that position using its internal model and returns relevant information such as type details or documentation.

Request:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "textDocument/hover",
  "params": {
    "textDocument": {
      "uri": "file:///home/user/main.go"
    },
    "position": {
      "line": 3,
      "character": 8
    }
  }
}

Response

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "contents": "func main()",
    "range": {
      "start": { "line": 2, "character": 0 },
      "end":   { "line": 2, "character": 10 }
    }
  }
}

The editor renders this response directly; it does not interpret or analyze the content.

3.2 Completion (textDocument/completion)

Completion requests are triggered by typing or explicit user actions (CTRL + SPACEBAR).

The editor provides the current cursor position. The server inspects scope, imports, and type information to determine valid completions.

Request:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "textDocument/completion",
  "params": {
    "textDocument": {
      "uri": "file:///home/user/main.go"
    },
    "position": {
      "line": 3,
      "character": 4
    }
  }
}

Response:

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "isIncomplete": false,
    "items": [
      {
        "label": "Println",
        "kind": 3,
        "detail": "func fmt.Println(a ...any) (n int, err error)",
        "documentation": "Println formats using the default formats for its operands"
      }
    ]
  }
}

The editor is responsible only for ranking and rendering suggestions.

3.3 Go-to-Definition (textDocument/definition)

A definition request resolves a symbol reference to its declaration.

The server uses its workspace index and type information to locate the symbol, which may reside in:

The current file
Another workspace file
The standard library

Request:

{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "textDocument/definition",
  "params": {
    "textDocument": {
      "uri": "file:///home/user/main.go"
    },
    "position": {
      "line": 3,
      "character": 8
    }
  }
}

Response:

{
  "jsonrpc": "2.0",
  "id": 4,
  "result": [
    {
      "uri": "file:///usr/local/go/src/fmt/print.go",
      "range": {
        "start": { "line": 120, "character": 6 },
        "end":   { "line": 120, "character": 12 }
      }
    }
  ]
}

The editor navigates to the returned location(s).

Key Observations

Language intelligence is always derived from the server’s internal state
Partial edits are sufficient because the server maintains a full document snapshot
Editors do not analyze code; they delegate and render
JSON-RPC provides a strict request/response boundary

With hover, completion, and navigation in place, the editor can now delegate nearly all semantic reasoning to the language server.

Next, we will cover shutdown, exit, and cleanup, and how editors terminate LSP sessions without losing state or leaking resources.

Section 4: Shutdown and Exit

When the editor closes a workspace or terminates, it must shut down the language server in a controlled way. LSP defines a two-step termination sequence to ensure cleanup happens deterministically.

4.1 shutdown (request)

Before terminating the server process, the editor sends a shutdown request.

This request signals that:

No new requests will be sent
The server should finish or cancel ongoing work
Internal state should be released

Request:

{
  "jsonrpc": "2.0",
  "id": 5,
  "method": "shutdown",
  "params": null
}

Response:

{
  "jsonrpc": "2.0",
  "id": 5,
  "result": null
}

After responding, the server must not process any further LSP requests other than exit.

4.2 exit (notification)

Once the shutdown request has completed, the editor sends an exit notification.

This message has no response. On receipt, the server terminates its process immediately.

Notification:

{
  "jsonrpc": "2.0",
  "method": "exit",
  "params": null
}

If the server receives exit without a prior shutdown, it should exit with a non-zero status, signaling an abnormal termination.

4.3 Termination Semantics

shutdown is a request: orderly cleanup and acknowledgement
exit is a notification: process termination

This separation ensures:

Pending work can be completed or canceled
Resources such as file buffers, caches, and indexes are released
The editor does not need to forcibly kill the process

4.4 Shutdown Flow

At this point, the LSP session is fully closed. A new session begins with a fresh server process and a new initialization handshake.

Final Notes

The LSP lifecycle is deliberately explicit:

Editors manage user interaction and rendering
Language servers own parsing, analysis, and symbol resolution
JSON-RPC provides a strict, asynchronous boundary
Document state is driven by editor events
Startup and shutdown are symmetrical and deterministic

This separation allows editors to remain simple while language tooling evolves independently.

By understanding this workflow, you see how VS Code delegates language intelligence to servers and why this separation matters. This knowledge also equips you to:

Build custom language tooling
Debug LSP interactions effectively
Contribute to language server development

It highlights how a structured, asynchronous protocol can provide real-time language features while keeping editors lightweight and responsive.

Draft - saved

Demystifying CORS: Understanding How Cross-Origin Resource Sharing Works

Martin Wachira — Fri, 18 Aug 2023 18:03:55 +0000

In modern web development, ensuring secure and controlled communication between different origins (domains) is important. This is where Cross-Origin Resource Sharing (CORS) comes into play.

CORS is a fundamental security mechanism implemented by web browsers that governs how web pages from one origin can interact with resources from another.

In this article, we'll delve into the intricacies of CORS, demystify its inner workings, and explore how it safeguards the integrity and privacy of data exchanged across different web origins.

Understanding Cross-Origin Requests

Before delving into the specifics of CORS, let's establish a foundation of understanding about cross-origin requests.

Imagine a scenario where a web page hosted on http://localhost:4000/ wants to retrieve data from an API located at http://localhost:3000/data. In a simpler time, this interaction might have raised concerns about data security and unauthorized access. CORS addresses these concerns by adding a layer of control and validation.

The image shows a cross-origin request by a web page froma different origin

The Role of CORS

CORS acts as a Gatekeeper: Think of CORS as a virtual gatekeeper stationed between web origins. When a cross-origin request is initiated, the gatekeeper evaluates whether the request is permissible or not.

Origin and Security: An origin is a combination of the protocol (HTTP or HTTPS), domain, and port. CORS ensures that only web pages from approved origins can access specific resources hosted on other domains.

Request with Origin Header: When a web page makes a request to an external resource, it includes an "Origin" header in the request. This header indicates the origin of the requesting web page.

Server Response with CORS Headers: The server that hosts the requested resource evaluates the incoming "Origin" header. If the server is configured to allow the requesting origin, it responds with CORS headers that provide permission details.

How CORS Works

1.Request with Origin Header: The requesting web page sends a request to a different domain, including an "Origin" header.


async function fetchData() {
  try {
   const response = await fetch('http://localhost:3000/data', {
   method: 'GET',
   headers: {
     'Origin': ' http://localhost:4000'
     }
   });
   const data = await response.json(); 
   console.log(data);
   } catch (error) {
   console.error(error);
  } 
}

2.Server Response with CORS Headers: The server checks the "Origin" header against its allowed origins. If the request is authorized, the server responds with specific CORS headers that grant access.


app.get('/data', (req, res) => {
  const allowedOrigins = ['http://localhost:4000', 'https://otherdomain.com'];
  const requestOrigin = req.headers.origin;

  if (allowedOrigins.includes(requestOrigin)) {
    res.header('Access-Control-Allow-Origin', requestOrigin);
    res.header('Access-Control-Allow-Methods', 'GET');
    res.status(200).json({ data: 'Response data' });
  } else {
    res.status(403).json({ error: 'Unauthorized origin' });
  }
});

3.Browser Check and Access Decision: The browser receives the response along with CORS headers. It verifies that the requesting origin matches the allowed origins specified in the "Access-Control-Allow-Origin" header. If they match, the browser allows access.


async function fetchData() {
  try {
   const response = await fetch('http://localhost:3000/data');
   const data = response.json();
  } catch (error) {
   console.error(error);
   }
 }

4.Blocking Unauthorized Access: If the requested origin is not in the approved list or if CORS headers are missing, the browser blocks the response from being accessed. This shields the data from unauthorized access.

Pre-Fight Requests

Preflight requests are an essential part of the Cross-Origin Resource Sharing (CORS) mechanism and are used by browsers to check with the server whether a specific cross-origin request is allowed.

Preflight requests are automatically triggered by the browser under certain conditions before the actual request is made. They ensure that the server is properly configured to handle the cross-origin request.

Here's how preflight requests work in CORS:

1.Complex Requests: Preflight requests are primarily used for so-called "complex" requests. A request is considered complex if it meets any of the following criteria:

It uses an HTTP method other than GET, HEAD, or POST.
It sets custom headers using the setRequestHeader() method.
It sends data other than simple textual data (e.g., JSON, XML) as the request body.

2.Preflight Request: When the browser detects that a cross-origin request is complex, it automatically sends a preflight OPTIONS request to the server before sending the actual request. This preflight request includes the following headers:

Origin: The origin of the requesting site.
Access-Control-Request-Method: The HTTP method of the actual request.
Access-Control-Request-Headers: A list of any custom headers used in the request.

3.Server Response: The server should be configured to respond to preflight requests with appropriate CORS headers. These headers inform the browser whether the actual request is allowed. The relevant headers are:

Access-Control-Allow-Origin: Specifies which origins are allowed to access the resource. This header must match the origin of the requesting site or be set to * to allow any origin.
Access-Control-Allow-Methods: Specifies the HTTP methods that are allowed for the actual request.
Access-Control-Allow-Headers: Specifies the custom headers that are allowed for the actual request.

4. Browser Decision: Based on the response from the server's preflight request, the browser decides whether to proceed with the actual request. If the server responds with appropriate headers indicating that the actual request is allowed, the browser sends the actual request. If the server does not provide the necessary headers or explicitly denies the request, the browser generates a CORS error and does not send the actual request.

5.Actual Request: If the preflight request is successful, the browser sends the actual request to the server with the appropriate headers. The server processes the request and responds to it.

It's important to note that the preflight process adds an extra layer of security by ensuring that servers explicitly allow cross-origin requests and specify the allowed methods and headers. This helps protect against unauthorized access and potential security vulnerabilities.

When setting up CORS on your server, ensure that your server correctly handles preflight OPTIONS requests and responds with the appropriate CORS headers to indicate which origins, methods, and headers are allowed for the actual requests.

Conclusion

In conclusion, CORS acts as a gatekeeper that enforces rules for cross-origin requests, ensuring that only authorized origins can access resources hosted on different domains.

By understanding how CORS functions and its critical role in maintaining a secure web environment, developers can navigate the complexities of cross-origin communication with confidence.

As web applications continue to evolve and interconnect, CORS remains a steadfast guardian that enables secure data exchange while upholding the principles of privacy and integrity.

React Router: A comprehensive guide for beginners

Martin Wachira — Fri, 28 Apr 2023 09:55:09 +0000

React router, is a routing library that helps you create dynamic and responsive single-page applications with different views and pages that update without reloading the entire application.

In this article, we will discuss how to use react router and show an example of how to use it in a React application.

Table of contents
Installing react router
Configuring the router
Defining routes
Handling navigation with Link and NavLink
Link
NavLnk
Dynamic routing

Installing React Router
To install the library, we can use the npm package manager by running the following command:

 npm i react-router-dom

Configuring the Router
To configure our router, we will wrap our root component in BrowserRouter.

import React from "react";
import ReactDOM from "react-dom/client";
import { BrowserRouter } from "react-router-dom";
import "./index.css";
import App from "./App";
import reportWebVitals from "./reportWebVitals";

const root = ReactDOM.createRoot(document.getElementById("root"));
root.render(
  <React.StrictMode>
    <BrowserRouter>
      <App />
    </BrowserRouter>
  </React.StrictMode>
);

Browser router, is a component provided by the React Router that enables client-side routing in a single-page application.

It works by synchronizing the URL in the browser's address bar with the components displayed on the screen.

Defining routes
Defining routes is mostly done at the top most level of your application, such as the app.js.

import "./App.css";
import { Routes, Route } from "react-router-dom";
import HomePage from './pages/HomePage'
import Images from './pages/Images'
import PageNotFound from './pages/PageNotFound'

function App() {
  return (
    <div className="App">

      <Routes>
        <Route path="/" element={<HomePage />} />        {/* It maps the path "/" to the <HomePage /> component, which will be rendered when the user navigates to the root path. */}

        <Route path="/images" element={<Images />} />
        {/*  This line defines a route for the "/images" path of the application. */}
        <Route path="*" element={<PageNotFound />} />
        {/* It maps any other path to the <PageNotFound/> component, which will be rendered when the user navigates to any undefined path. */}
      </Routes>

    </div>
  );
}

export default App;

Code explanation

<Routes>:
This is a parent component that defines the routes for the web application.

<Route path="/" element={ <HomePage/> } />: 
It maps the path "/" to the <HomePage/> component, which will be rendered when the user navigates to the root path.

<Route path="/images" element={ <Images/> } />: 
This line defines a route for the "/images" path of the application.

<Route path="*" element={ <PageNotFound/> } />: 
This line defines a fallback route for any other paths that are not defined in the previous routes.

It maps any other path to the <PageNotFound/> component, which will be rendered when the user navigates to any undefined path.`

Handling navigation
Using the Link component
React router uses a Link component which is used to create a hyperlink that allows users to navigate to a different route or page within a React application without having to reload the entire page.

import React from 'react'
import { Link } from 'react-router-dom'

function NavBar() {
   return (
     <nav className='navBar'>
        <ul>
           <li><Link to='/'>Home</Link></li>
           <li><Link to='/images'>Images</Link></li>
           <li><Link to='/pagenotfound'>Page not found!!</Link></li>
        </ul>
     </nav>
    )
}


export default NavBar

When a user clicks on a Link component, React Router will update the URL in the browser's address bar to match the path specified in the to prop of the Link.
This will trigger React Router to render the component associated with that path.

Using NavLink
In React Router, you can also use the NavLink component to create links that have additional styling when they match the current URL.

The NavLink component is similar to the Link component, but it provides additional props that allow you to customize the styling of the link based on whether or not it matches the current URL.

import React from 'react'
import { NavLink } from 'react-router-dom'
import { Link } from 'react-router-dom'
function NavBar() {
   return (
     <nav className='navBar'>
        <ul>
         <li><NavLink to='/' className={'activeLink'}>Home</NavLink></li>
         <li><NavLink to='/images' className={'activeLink'}>Images</NavLink></li>
          <li><NavLink to='/pagenotfound' className={'activeLink'}>Page not found!!</NavLink></li>
        </ul>
     </nav>
   )
}

export default NavBar

The activeLink prop allows you to specify a CSS class name to be applied to the link when it matches the current URL.
This allows you to customize the styling of the link to provide visual feedback to the user.

Dynamic Routing
Dynamic routing is the process of defining routes for different pages of a web application based on the current state of the application or the user's actions.

Dynamic routing can be achieved using parameters in the route path.

Parameters are specified in the route path using a colon followed by a parameter name, such as "/images/:imageId"

import "./App.css";
import { Routes, Route } from "react-router-dom";
import HomePage from './pages/HomePage'
import Images from './pages/Images'
import PageNotFound from './pages/PageNotFound'
import NavBar from "./Components/NavBar";
import ImageDetails from "./pages/ImageDetails";

function App() {
  return (
    <div className="App">
       <NavBar />
      <Routes>
        <Route path="/" element={<HomePage />} /> 
        <Route path="/images" element={<Images />} />     
       ** <Route path="/images/:id" element={<ImageDetails />} />**     
        <Route path="*" element={<PageNotFound />} />

      </Routes>
    </div>
  );
}
export default App;

When you have a dynamic route, you want to access the dynamic value in your custom component which is where the useParams hook comes in.

import React from 'react'
import { useParams } from 'react-router-dom'

const ImageDetails = () => {
  const { id } = useParams();
    return (
      <div>
         <p>Image { id }</p>
         {/* Render dynamic content based on the value of `id` */}
      </div>
  )
}
export default ImageDetails

The useParams() hook is provided by the React Router library to extract the value of the id parameter from the current URL.

When a URL matches the path specified in the Route component (e.g., /images/123), the useParams() hook will return an object containing the key-value pair of id: "123", where "123" is the value of the id parameter in the URL.

The code then uses object destructuring to extract the id value from the object returned by useParams(). This creates a new variable named id that holds the value of the id parameter.

So, in the ImageDetails component, the id variable can be used to access the value of the id parameter from the URL and use it to render dynamic content.

Conclusion
Overall, React Router is a powerful tool for managing client-side routing in React applications. It can help make an application more modular, flexible, and easier to navigate, improving the user experience and simplifying development.

How to use React loader spinner library

Martin Wachira — Mon, 24 Apr 2023 19:05:08 +0000

React Loader Spinner is a popular library that provides a wide range of customizable spinners for React applications.
It is a great way to indicate to users that your application is loading data or performing an operation that may take some time.

In this article, we will discuss how to use the React Loader Spinner library and show an example of how to use the TailSpin spinner in a React application.

Installing React Loader Spinner
Before we start using React Loader Spinner, we need to install the library in our React application.

To install the library, we can use the npm package manager by running the following command:

npm install react-loader-spinner

Once the library is installed, we can import the react-loader-spinner component and start using it in our React application.

Using the TailSpin Spinner in a React Application
First, we import the TailSpin component from the react-loader-spinner library:

import { TailSpin } from "react-loader-spinner";

Next, we define a state variable called loading and set its initial value to false.
This state variable will be used to determine whether the spinner should be displayed or not:

const [loading, setLoading] = useState(false);

In the useEffect hook, we define an asynchronous function called fetchData that retrieves data from a remote API.
Before the data is fetched, we set the loading state variable to true to indicate that the data is being loaded:

const fetchData = async () => {
  try {
    setLoading(true);
    const response = await fetch("https://jsonplaceholder.typicode.com/posts");
    const data = await response.json();
    setPosts(data);
  } catch (error) {
    setError(error.message);
  } finally {
    setLoading(false);
  }
};

useEffect(()=>{
  fetchData();
},[]);

Finally, in the JSX code, we conditionally render the TailSpin spinner based on the value of the loading state variable. If loading is true, the spinner is displayed; otherwise, the posts are displayed:

{loading ? (
  <TailSpin color="red" radius={"8px"} />
) : (
  posts.map((post) => (
    <div key={post.id}>
      <h5>{post?.title}</h5>
      <p>{post?.body}</p>
    </div>
  ))
)}

In this example, we set the color and radius props of the TailSpin component to customize the appearance of the spinner.

Here are some other properties that can be set for the spinner component:

color: Sets the color of the spinner.
height: Sets the height of the spinner.
width: Sets the width of the spinner.
timeout: Sets the duration of the animation before the spinner stops spinning.
visible: Determines whether the spinner should be visible or not.
secondaryColor: Sets the secondary color of the spinner for multi-color spinners.
radius: Sets the border radius of the spinner.
strokeWidth: Sets the stroke width of the spinner.
style: An object that contains additional styles to apply to the spinner.
className: A string that contains additional CSS classes to apply to the spinner.

Conclusion
React Loader Spinner is a powerful library that provides a wide range of customizable spinners for React applications.
By using the TailSpin spinner, we can indicate to users that our application is loading data or performing an operation that may take some time.
By installing the library, importing the component, and using it in our JSX code, we can easily integrate React Loader Spinner into our React application.

Data Types In JavaScript

Martin Wachira — Fri, 27 Jan 2023 12:20:38 +0000

A data type, is a classification that specifies which type of value a variable has and what type of mathematical, relational or logical operations can be applied to it without causing an error.
Basic data types in JavaScript include:

Number
String
Boolean
Symbol
Null
Undefined
Object

The above data types are categorized into two categories:
1.Primitive data types, these are data types that store a single value. They include number, String, Boolean, Symbol, Null and Undefined.
2.Non primitive (Reference) data types, these data types are derived from primitive data types and have properties and methods to manipulate their values. An example is the object data type.

Difference between Primitive and non-primitive Data types

1.Primitive data types are compared by value, that is, two values are strictly equal if they have the same value.
Sample

let age = 18;                          
let num = 18;                          

let isEqual = age === num;            
console.log(isEqual); //Output -> true

Non-primitive data types are compared by reference, that is, two objects are strictly equal if they refer to the same values.


let sports1 = ['Football', 'Rugby', 'Basketball'];                          
let sports2 = sports1;                                                                                     
let isEqual = sports1 === sports2;                
console.log(isEqual); //Output -> true

Primitive Data types

Primitive data types are those that hold a single value.


let x = 5
let y = 12.5

They include:

1. Number

It can be an integer, a float , an exponential, a NaN and an infinity.


let x = 100; //An integer     
let y = 12.43; //A float      
let z = 10e4; //An exponential

NaN(Not a Number) is used to represent an invalid number, results when you try to perform an operation on a number with a non-numeric value.


let b = 12 * 'f';
console.log(b); //Output -> NaN

Infinity, it results when we divide a number by zero


let b = 12 / 0;                      
console.log(b); //Output -> Infinity

2.Boolean

Holds a true or false value.
It is mostly used to check if a logical condition is true or false.


let isGreater = 3 < 9;                                   
console.log(isGreater); //Output -> true

3.Null

Is a special value that represents an unknown value.


let b = null;                   
console.log(b); //Output -> null

4.Undefined

It represents a value that is not defined.


let b;                               
console.log(b); //Output -> undefined

5.String

A string is any group of characters surrounded by quotes, double quotes or backticks.
When using double quotes or single quotes, there is no practical difference between them.


let country = "Kenya";
let city = 'Nairobi';

A backtick is mostly used when appending a variable to a string


let backtick = 'backtick';                                          
console.log (`This is a ${backtick}`);
//Output -> This is a backtick

Non-Primitive Data Types

1.Objects

In JavaScript, an object is a collection of properties where each property is defined with a key-value pair.


let obj = {
country: 'Kenya',
capital: 'Nairobi',    
continent: 'Africa'
}    
The above object has three properties country, capital and continent with corresponding values of Kenya, Nairobi and Africa.

How to access data in objects

To access values in an object, we use the dot notation and bracket notation.

Dot notation


objectName.propertyName //Syntax to access values of an object    

let countryName = obj.country;              
console.log(countryName); //Output -> Kenya  
let capitalName = obj.capital;               
console.log(capitalName); //Output -> Nairobi

Bracket Notation


objectName['propertyName'] //Syntax to access values of an object    
let countryName = obj['country'];              
console.log(countryName); //Output -> Kenya  
let capitalName = obj['capital'];               
console.log(capitalName); //Output -> Nairobi

Adding a value in an object


obj.population = '51.09 million';
console.log(obj);
// Output
{
 country: 'Kenya',
 capital: 'Nairobi',
 continent: 'Africa',
 population: '51.09 million'
 }

Delete a value in the object


delete obj.population;
console.log(obj);

//Output
{
 country: 'Kenya',
 capital: 'Nairobi',
 continent: 'Africa',
}

Modifying value of a property in an object


let intialObj = 
{
country: 'Kenya',
capital: 'Nairobi',
continent: 'Africa',
population: '51.09 million'
}

intialObj.country = 'Tanzania';//Changes the value Kenya to Tanzania
console.log(intialObj);
//Output 
{
 country : 'Tanzania', 
 capital : 'Nairobi', 
 continent :'Africa',
 population : '51.09 million' 
  }