Updates

Author: fezcode

data/shownPosts.json

@@ -7,6 +7,14 @@
     "description": "a journey to create my first golang package",
     "tags": ["go", "lib", "pkg.go.dev"]
   },
+  {
+    "slug": "hashrouter-vs-browserrouter",
+    "title": "HashRouter vs. BrowserRouter",
+    "date": "2025-10-15",
+    "updated": "2025-10-16",
+    "description": "Why am I using HashRouter for github pages",
+    "tags": ["react", "webdev", "gh-pages", "router"]
+  },
   {
     "slug": "warning-post",
     "title": "My Second Post",

posts/hashrouter-vs-browserrouter.txt

@@ -0,0 +1,48 @@
+# HashRouter vs. BrowserRouter
+
+When building Single-Page Applications (SPAs) with React, `react-router-dom` is a go-to library for handling client-side routing. It offers two primary router components: `HashRouter` and `BrowserRouter`.
+While both achieve the goal of navigating between different views in your application without full page reloads,
+they do so in fundamentally different ways, and these differences become crucial when deploying to static hosting environments like GitHub Pages.
+
+## The Core Difference: How They Handle URLs
+
+The key to understanding `HashRouter` and `BrowserRouter` lies in how they interact with the browser's URL structure, specifically the `path` and `fragment` (or hash) parts of a URL.
+
+A typical URL looks something like this: `protocol://hostname:port/path?query#fragment`
+
+*   **`/path`**: This part of the URL is sent to the server. The server uses it to identify and serve a specific resource (e.g., an HTML file, an image, etc.).
+*   **`#fragment`**: This part, also known as the hash, is *never* sent to the server. It's entirely handled by the client-side (the web browser).
+
+### `HashRouter`: The Static Hosting Friend
+
+*   **URL Structure:** `https://yourdomain.com/#/blog/my-post`
+*   **How it Works:**
+    1.  When a user navigates to a URL with a hash (e.g., `#/blog/my-post`), the server (in this case, GitHub Pages) only sees the part of the URL *before* the hash: `https://yourdomain.com/`.
+    2.  GitHub Pages, being a static file server, simply looks for and serves the `index.html` file located at the root of your deployment.
+    3.  Once `index.html` loads, your React application starts. `HashRouter` then inspects the full URL in the browser's address bar, extracts the route information from after the hash (`/blog/my-post`), and renders the corresponding component.
+*   **Why it Works on GitHub Pages:** Because the server never sees the route information (e.g., `/blog/my-post`), it never tries to find a physical file at that path. It always serves `index.html`, and your client-side JavaScript handles all the routing. This makes `HashRouter` a very robust and straightforward choice for static hosting where you don't have server-side routing capabilities.
+
+### `BrowserRouter`: The Clean URL Enthusiast (with a Catch)
+
+*   **URL Structure:** `https://yourdomain.com/blog/my-post`
+*   **How it Works:**
+    1.  When a user navigates to a URL without a hash (e.g., `/blog/my-post`), the server receives the *entire path*: `https://yourdomain.com/blog/my-post`.
+    2.  GitHub Pages, as a static server, will then try to find a physical file at `/blog/my-post`.
+*   **Why it's Tricky on GitHub Pages:** Since your React application is a Single-Page Application, there isn't a physical file named `my-post` (or `blog/my-post`) on the server. All your application's code is bundled into `index.html` and its associated JavaScript files. Consequently, GitHub Pages returns a 404 "Not Found" error because it can't find a file at the requested path. Your `index.html` is never served, and your React app never gets a chance to load and handle the routing.
+
+## The `404.html` Workaround for `BrowserRouter` (and Why It's Often More Trouble)
+
+To make `BrowserRouter` work on GitHub Pages, a common workaround involves creating a custom `404.html` file. This file contains a JavaScript script that, when served by GitHub Pages (because a 404 occurred), attempts to:
+
+1.  Rewrite the URL in the browser's history to the original requested path (e.g., `/blog/my-post`).
+2.  Redirect the browser to your `index.html`.
+
+The idea is that once `index.html` loads, `BrowserRouter` will see the rewritten URL and render the correct component. However, this approach is often fraught with issues:
+
+*   **Timing and Browser Behavior:** The script's execution, `history.replaceState`, and the subsequent redirect can be sensitive to browser behavior, caching, and network timing.
+*   **Flickering/Double Redirects:** Users might experience a brief flicker of the 404 page or multiple redirects before the correct content loads.
+*   **Debugging Complexity:** Debugging issues in this setup can be challenging due to the asynchronous nature of the redirects and the interaction between the server's 404 handling and client-side JavaScript.
+
+## Conclusion: Choose Wisely for Static Hosting
+
+For projects deployed on static hosting services like GitHub Pages, `HashRouter` offers a simpler, more reliable, and less problematic solution. While `BrowserRouter` provides aesthetically cleaner URLs, the effort required to make it work consistently on static hosts often outweighs the benefits, especially for personal projects or portfolios where server-side configuration is not an option. If clean URLs are an absolute requirement, a more robust hosting solution with server-side routing capabilities (like Netlify, Vercel, or a custom server) would be a better fit.