rewrite

interfaces/Catcrafts-Blog.cppm

@@ -1,68 +0,0 @@
-/*
-catcrafts.net
-Copyright (C) 2026 Catcrafts
-
-The source code of this website is made available for viewing purposes only. 
-No permission is granted to copy, modify, distribute, or create derivative works.
-*/
-
-export module Catcrafts:Blog;
-import Crafter.Graphics;
-import std;
-using namespace Crafter;
-
-export namespace Catcrafts {
-    struct BlogPost {
-        std::string name;
-        std::string slug;
-        std::string date;
-        std::string content;
-    };
-    std::vector<BlogPost> posts {
-        {
-            "Hello World! 2?",
-            "hello-world-2",
-            "2026-07-18",
-            R"(So this blog has been mega dead but today i bring something exciting that was already released months ago but never deployed xd.
-
-            Crafter.CppDOM is dead, long live Crafter.Graphics!
-            
-            This website is now updated to use the new Crafter.Graphics library, which allow for C++ manpiulation of the DOM, and as a new feature WebGPU!
-
-            And what better way to flex WebGPU than ray tracing? Here's a little scene traced live in your browser, shadows and all, straight from the same C++ compiled to WASM that rendered this very post:
-            )"
-        },
-        {
-            "In WASM, Exit doesn't mean done.",
-            "in-wasm-exit-doesnt-mean-done",
-            "2025-11-14",
-            R"(So if anyone looked at the source code for this website pefore this post you would have seen that everything was allocated with new, for example this very blog was defined as <code>std::vector&lt;BlogPost&gt; posts = new std::vector&lt;BlogPost&gt;{...};</code><br><br>
-
-            Reason for this was that everything became corrupted when callbacking from JS, not knowing sure as to why this was the fastest solution, but after debugging the problem became clear.<br><br>
-            
-            When we reach the end of <code>int main()</code> from the eyes of C++ we're finished, deconstruct everything and wrap it up. Unkowing that we just registered a bunch of event handlers with JS.<br><br>
-            
-            This caused all the memory corruption errors since everything was destructed.<br><br>
-            
-            Luckily this is a very simple fix of adding <code>-fno-c++-static-destructors</code>, and the ease of things like this is also one of the reasons i use clang instead of gcc.<br><br>
-
-            So now all examples and this site have been updated to use normal variables again.<br><br>
-
-            Stick around for the next post for the <strong>CI/CD nightmare</strong> (not for the faint of heart))"
-        },
-        {
-            "Hello World!",
-            "hello-world",
-            "2025-11-12",
-            R"(Welcome to catcrafts.net!<br><br>
-            Here we believe optimization is everything and C++ is a gift from god.<br> 
-            This blog will mostly be dedicated to random tidbits i come across while working on my Crafter series of libraries.<br><br>
-            
-            Like this website which is fully written in C++ using the Crafter.Graphics library.<br>
-            And source available too!<br>
-            <a href="https://forgejo.catcrafts.net/Catcrafts/catcrafts.net">https://forgejo.catcrafts.net/Catcrafts/catcrafts.net<a>)"
-        }
-    };
-    void RenderBlog();
-    void RenderBlogPost(const std::string_view slug);
-}

interfaces/Catcrafts-Root.cppm

@@ -2,7 +2,7 @@
 catcrafts.net
 Copyright (C) 2026 Catcrafts
 
-The source code of this website is made available for viewing purposes only. 
+The source code of this website is made available for viewing purposes only.
 No permission is granted to copy, modify, distribute, or create derivative works.
 */
 
@@ -12,5 +12,16 @@ import std;
 using namespace Crafter;
 
 export namespace Catcrafts {
-    void RenderRoot(const std::string_view route);
-}
+    // Render the route currently in the address bar and rebind its links.
+    void RenderCurrentRoute();
+
+    // Navigate client-side: push history, then render. Used by the link
+    // interception in BindLinks(); also the entry point for any programmatic
+    // navigation.
+    void NavigateTo(std::string_view path);
+
+    // Link interception is internal to the client-rendered fallback path — a
+    // server-rendered page never intercepts, because normal navigation to
+    // another fully-rendered page is already fast and hijacking it would only
+    // add ways to be wrong.
+}

interfaces/Catcrafts-Views.cppm

@@ -6,8 +6,16 @@ The source code of this website is made available for viewing purposes only.
 No permission is granted to copy, modify, distribute, or create derivative works.
 */
 
+// Browser-side page chrome and content loading.
+//
+// This partition is the wasm half of the split: it owns the DOM and the VFS,
+// and calls into Catcrafts.Shared for every piece of markup. Nothing in here
+// builds HTML by hand — that all lives in Catcrafts.Shared:Views so the server
+// renders byte-identical pages.
+
 export module Catcrafts:Views;
 import Crafter.Graphics;
+import Catcrafts.Shared;
 import std;
 using namespace Crafter;
 
@@ -17,6 +25,11 @@ export namespace Catcrafts {
     // children don't get yanked out of the DOM. Must be called from main()
     // — the Crafter.Graphics Dom bridge is only safe to use after wasm
     // instantiation hands control to user code.
+    //
+    // When SSR lands this becomes an adopt step rather than a build step: the
+    // chrome will already be in the document and re-creating it would discard
+    // server-rendered markup and flash. Keeping chrome construction separate
+    // from route rendering is what keeps that change local to this function.
     void InitializePage();
 
     // Per-render scratch ref to the <main> content container created by
@@ -24,4 +37,32 @@ export namespace Catcrafts {
     // document.getElementById; in return we don't have to thread a long-lived
     // reference across module boundaries.
     inline Dom::HtmlElementPtr MainContent() { return Dom::HtmlElementPtr("main"); }
+
+    // Site content, parsed once at startup from the bundle. Crafter.Build
+    // copies content/*.json to the bundle root and runtime.js fetches every
+    // files.json entry into memory before _start, so the reads behind this are
+    // plain synchronous ifstreams that never touch the network.
+    const Views::SiteContent& SiteData();
+
+    // Read a file from the wasm VFS by bundle-root name. Returns empty on
+    // failure: a missing content file degrades to an empty section rather than
+    // a broken page.
+    std::string ReadBundleFile(std::string_view name);
+
+    // document.title is reachable only through Window::SetTitle, so the router
+    // needs a Window to set a per-route title. Rather than thread one through
+    // every render call, main() registers the live Window once and the router
+    // calls SetDocumentTitle. A null window makes SetDocumentTitle a no-op, so
+    // ordering mistakes degrade to a stale title instead of a crash.
+    void SetActiveWindow(Window* window);
+    void SetDocumentTitle(std::string_view title);
+
+    // True when the document arrived server-rendered, i.e. InitializePage
+    // adopted existing chrome rather than building it.
+    //
+    // The distinction matters: on an SSR'd page the DOM is already correct for
+    // the URL and must not be re-rendered, while on the static fallback shell
+    // (served when the backend is down) the app has to render everything
+    // itself. Both paths exist, and this is how the router tells them apart.
+    bool AdoptedSsr();
 }

interfaces/Catcrafts.cppm

@@ -8,6 +8,5 @@ No permission is granted to copy, modify, distribute, or create derivative works
 
 export module Catcrafts;
 export import :Views;
-export import :Blog;
 export import :Root;
 export import :Demo;