There is consistent tension in how much I let myself desire femininity. I rarely let go, but when I do, it re-enters with violent immediacy. Like punching a hole in your lungs and letting all the water rush in. The flip is usually accompanied by a few weeks of concerted effort towards achieving some sort of gender-euphoric acceptance. My evidence for believing myself is unfortunately the same evidence that invalidates it, and guarantees plausible deniability should I change my mind.

All sorts of events have contributed to why I think this is who I am, or could be. Personifying myself as “her” is mostly done by feminizing myself through objects and association to said things. When I experience self-denial, I suppress any positive associations I had about presenting myself as “she” because it’s easier to just be a dude, or a gender-neutral person who happens to like objectively girly things.

The crux for me is that it seems obvious until it doesn’t, so I forget about it. Because I forget about it, new evidence that “I don’t want it as much as I think” scores itself against the version of me who just wants to let go.

June 9

I got a nice haircut today. I’ve been somewhat indifferent about my gender expression lately, but getting a femme haircut was a lovely reminder of how modifying your identity sometimes only takes small votes of courage. These votes are sources of feedback for your brain and how you are perceived socially. Physical identity is proof staring you in the face, no questions asked, and you can use it as leverage in other areas of your life where you may need more confidence.

Aug 4

Read a great post after stumbling on Ava’s review of Whipping Girl. Afterwards I read for about an hour straight on trans identity and how "proof" can only come from you.

You decide. You set the conditions. If you believe yourself and your certainty comes from a place of love and understanding, it's right. If there’s a sense of joy, perhaps a giddy feeling about the thought of being a girl, or a boy, it’s right.

It’s easy to look back and see the signs; it’s easy to paint a narrative as well. I’m unsure of what to think, but I know that I love thinking of myself as her.

“We have to accept human behaviour the way it is, not the way we would wish it to be.”

The Design of Everyday Things

I feel as though it’s important to respond to randomness with curiosity. Whether behavioural or environmental, most things that happen are pretty random. Outcomes repeated are not necessarily any more frequent; rather, you prioritize thinking about them due to their familiarity.

If I’m curious about my own behaviour, I could ask why I chose the response that I did. Directed at someone else, I could take interest in what I don't understand about the other person. If I lived her life, would I do the same?

Ultimately, we are in control of our behaviour at all times. Suppose someone cuts you off in traffic; if you were to answer the phone from your grandmother at the precise moment you felt angriest, would your engraged demeanor not immediately assume a more pleasant tone?

Maybe the situation you’re facing is based on a decision made in the past. The decision at this point doesn’t exist, but its side effect does. While you are you, as the version you know yourself today, your past decisions will eventually knock at your window, asking if you still want to accept them.

Some decisions are nicer than others, and some will throw a rock through your window.

July 15

“Correcting a bias - Do the opposite of my instincts. If I tend to walk away, I choose to stay. When I notice I’m prejudiced against something, I choose to get to know it and appreciate it.”

Excerpt From Useful Not True Derek Sivers

Lately I’ve been thinking about decisions and their hidden motivations. Good intentions that genuinely benefit other people may still exist to serve yourself. Extending grace towards another person for an action they feel guilty about could be a way of excusing your own selfish motivations.

You might also want to do the thing they’re feeling bad about, but don't want to admit it. If that's the case, this is an opportunity to reflect and establish connection.

“Hey, that thing you feel weird about, I also think about that stuff too, and we could probably navigate this together.”

I had a great conversation last night that was both empowering and vulnerable. Things became far more interseting once the "I see you, just say what's on your mind" blockers came down. Once we started digging into the thorns, everything was much lighter and more fulfilling.

Practicing critical thinking before googling it

A great post I read recently was about how to practice abstinence from search / research when faced with something you don’t know. e.g., don’t turn to AI and instead reason in why an outcome is the way it is, then search and see how logical your thinking was.

July 22

Yesterday, I saw 4-5 baby owls. There's a riverbed close by that looks like what I can only imagine the earth would have looked like in the Mesozoic era or something. Whenever I’m here, I tend to think about how if I died today, I’d be quite happy.

I have been hyper-focused on pursuing my career these last two years; while very gratifying, I find my presence is both here and not at the same time. Every day I wake up and make decisions towards what I want to learn in a day. Is the majority of my time spent enjoying the things I think I enjoy? If not, what am I doing?

Awareness is a finite, limited resource. The fewer things I have to consider, the better, generally. Physically, if I understand the cues from my body, whether emotionally or physiologically, I can choose to respond to them as they come up. However, this doesn’t mean I am automatically attuned to how much I am enjoying my life, and if this happened to be my last moment, is it a moment I’m grateful for?

I do think it is somewhat impossible to persist all of the mindsets that add value to your life at any one time. For example, sustained attention on learning needs space, and that space has to isolate you from certain things in order to achieve the benefit of you choosing to learn this thing.

So what do we do? I believe that the answer is to know what trade-off you’re making at any given moment and regardless of the outcome, know that you made a choice (from hopefully a higher state) and if it doesn’t go your way, you’ve learned something about yourself and what you would choose to prioritize or do differently in the future.

If you’re not making changes based on the feedback of your prior understandings of a decision, then you’re putting your effort on a treadmill.

Nginx Config:

Server block:

The configuration in this document is written to serve a containerized application with local port mapping on PORT :8080 -- as well as :80 when deployed to Vercel.

The following two lines specify where Nginx is going to serve your static web-app from.

root /usr/share/nginx/html; index index.html;

In this example, I've pre-built a little web-app that is pre-rendering dynamic data at build time in order to achieve SSG. Afterwards, I just copied the build directory over to this new repo. To keep the scope of this write-up small, I won't really get too deep on the build process.

absolute_redirect off

In a container-based application, your Nginx server is configured to manage incoming requests.

If we had a multi-service architecture, we could setup Nginx for reverse-proxying and distribute requests internally to each of your containerized apps/services, e.g., the front end and a backend.

When the absolute_redirect directive is turned OFF, Nginx will send back only the relative path ----> /blogs/blog-post-1 while letting the browser resolve the origin domain.

e.g, Vercel.com/app-name/blogs/blog-post-1

As a default, Nginx is configured to have the absolute_redirect directive set to: ON.

If we left it that way, there would be a few weird problems because Nginx will build a new URL out of three pieces of inferred information.

• The Scheme (http)
• Host Header (app-name.vercel.app)
• The Port (8080)

Vercel terminates TLS at their edge network when requests are made to our container; so, internally Nginx would infer that the entire website must be HTTP.

Nginx will also append the port the URL -- Each time a user requests an end-point like /blogs or /blogs/blog-post-1 - Nginx would re-direct the user to something like:

http://app-name.vercel.app:8080/blogs/blog-post-1

That URL doesn't exist outside of the internal container environment and creates a strange user-experience.

Location Assets Block:

Vercel & Browser Cache

As you would guess, a containerized app isn't an effective way to utilize Vercel's CDN. Normally if you weren't trying to overly complicate your little static site like I am, you'd deploy directly on Vercel to take advantage of that built-in feature.

*Vercel's CDN caches your content (including pages, API responses, and static assets) in data centers around the world, closer to your users than your origin server.

When someone requests cached content, Vercel serves it from the nearest region, cutting latency, reducing load on your origin, and making your site feel faster everywhere.*

In a container based app, Vercel routes all traffic to the container itself.

To benefit from the Vercel CDN, we have to add some additional HTTP headers in the Nginx config file. Without these headers, users will experience cold-starts every time they visit our app, which basically means, the container will need time to boot up on each request.

Another detraction is that you would eventually hit a Vercel usage limit that throttles the entire account; which disrupts any other applications hosted on the platform. No bueno!

Compiled Javascript, CSS & Image content

location ^~ /assets/ {
        try_files $uri =404;
        add_header Cache-Control "public, max-age=31536000, immutable";
        add_header Vercel-CDN-Cache-Control "public, max-age=31536000";
    }

Both headers in this block are set to have a max-age of one year.

When you re-build your application, the assets/ directory will generate brand new unique files. Even tho the user may have previous cache data that relates to an older file, it won't matter as each subsequent build, distributes new content to the user untracked in their cache.

Location / Block:

try_files $uri $uri/index.html =404;

If you look in your build directory, Nginx will match the uri to the directory name, and the index.html file at that level, else 404.

On redeployments, Vercel wipes its CDN cache data, so on each deploy, a new version can be cached for the user until our next release, or the year has lapsed.

In the browser, we would want the user to be able to access our newest deployment, so we set the max-age to zero.

Website Routing / Pages

location / {
        try_files $uri $uri/index.html =404;
        add_header Cache-Control "public, max-age=0, must-revalidate";
        add_header Vercel-CDN-Cache-Control "public, max-age=31536000";
    }

The Browser cache will give users faster load times for contents/routes that haven't changed. So while we may re-build and deploy this application periodically, the cache will remain consistent.

Even on a rollback, the cache is still sitting their dormant, so users who have previous experience with your app still benefit from faster load times.

Testing

To validate that this worked, once you've deployed your app to Vercel, hit it with a curl request and watch it cache your deployment in real time.

curl -sI https://vercel-container-ten.vercel.app/ | grep -i x-vercel-cache

It will respond back with MISS at first, and then HIT on the second request.

Location = /index.html Block:

The last location block indicates that if someone tries to type in index.html literally in the search bar, that the app will default back to / route, which is what they would have wanted anyways.

server {
    listen 8080;
    listen 80;
    server_name localhost;

    root /usr/share/nginx/html;
    index index.html;

    absolute_redirect off;

    location ^~ /assets/ {
        try_files $uri =404;
        add_header Cache-Control "public, max-age=31536000, immutable";
        add_header Vercel-CDN-Cache-Control "public, max-age=31536000";
    }

    location / {
        try_files $uri $uri/index.html =404;
        add_header Cache-Control "public, max-age=0, must-revalidate";
        add_header Vercel-CDN-Cache-Control "public, max-age=31536000";
    }

    location = /index.html {
        return 301 /;
    }
}

Docker Files

The Nginx config is the meat of this process, so let's get into what you're adding into your dockerfile(s), yes more than one.

• Select your base image
• Copy the nginx conf file we just created into the assumed location that nginx expects
• Copy your pre-built app into the location that nginx serves content from
• Since it's a container, expose it internally on port 8080
• Run nginx -t, which just checks for errors in your nginx config file.

FROM nginx:1.27-alpine

COPY nginx.conf /etc/nginx/conf.d/default.conf

COPY build/client/ /usr/share/nginx/html/

EXPOSE 8080

RUN nginx -t

Vercel Dockerfile

In a Vercel deployment, you provide a second Dockerfile either called, Containerfile.vercel, or Dockerfile.vercel - I preferred container file to differentiate them more obviously.

FROM nginx:1.27-alpine

COPY nginx.conf /etc/nginx/conf.d/default.conf

COPY build/client/ /usr/share/nginx/html/

EXPOSE 80

RUN nginx -t

These are the exact same, you just expose Vercel on port 80.

Deploy it!

To deploy on Vercel, all you need to do is push this bad boy to Github and sync your repo with your Vercel account. That's literally it.

Look at this tiny, beautiful, maintainable repo - chef's kiss

and the Cache test.

Pre-built app

To cover my bases, I wanted to showcase the react router config file as well so you can see how minimal it is. Surely you can serve a static site however you want, but I like React, and often I pre-build dynamic end-points before serving statically.

import type { Config } from "@react-router/dev/config";

export default {
  appDirectory: "app",
  ssr: false,
  async prerender() {
    const res = await fetch("http://localhost:3000/api/v1/birds")
    const birds: string[] = await res.json()
    return ["/", "/birds", ...birds.map((b) => `/birds/${b.toLowerCase()}`)]
  },
} satisfies Config;

If this was an SSR app you'd probably have something like this:

import type { Config } from "@react-router/dev/config";

export default {
  appDirectory: "app",
  ssr: true,
  routeDiscovery: { mode: "initial" },
  async prerender() {
    const res = await fetch("http://localhost:3000/api/v1/birds")
    const birds: string[] = await res.json()
    return ["/", "/birds", ...birds.map((b) => `/birds/${b.toLowerCase()}`)]
  },
} satisfies Config;

Same-same but different. Flip SSR to true, and add the route discovery property if you want to load every route, asset all at once when the user visits your page. By default it's set as "lazy" which for an SSR app just means that it loads each slug as it's requested to maintain performance.

Hey, did you know that the browser has native functionality that maintains the history of pages accessed by a user? As you build up your website, a small UX consideration you might want to make is tracking said URL history to improve the UI.

MDN History API

Scenario 1: Let's say I mozy over to the log in page. Once logged in, maybe the app pushes me to the home page. Cool!

Scenario 2: Now, let's say I want to access a protected route. Once I've logged in, the app should boot me back to the route I was originally trying to access.

To access the location aka URL metadata, React provides a built in hook called useLocation

Usage

import { useLocation } from "react-router-dom"

const location = useLocation()

Console logging the value of location provides you an object that looks something like this:

{pathname: '/home', search: '', hash: '', state: null, key: 'default'}

The main thing we care about here are the pathname and state properties.

Conditionally, if a user hasn't been authenticated, we can use/ask the <Navigate /> component to push them to the /login endpoint.

<Navigate /> accepts a state prop and works cohesively with a users location history. Because of this, we can create a link between the previous attempted path, and a login page.

In our Navigate component definition we create a state object with a new key called "prevLocation", or whatever you want; and give it the value of our location path.

const protectedRoute = () => {
    const isLoggedIn = localStorage.getItem("loggedin")
    const location = useLocation()

    if (!isLoggedIn) {
        return (
            <Navigate 
                to={"/login" }
                state={{
                    prevLocation: location.pathname
                }} 
                replace
            />)
    }
    return <Outlet />
}

After the user is forced to our logic screen, the metadata of location now looks like this: {pathname: '/login', search: '', hash: '', state: {prevLocation: '/home'}, key: 'er30evaf'}

If the user is logged in, then we'll render all of the protected routes via the <Outlet /> component.

On the login page, inside our authentication logic, we can specify that should any state exist in our path metadata, then boot the user back to that path, else just go back to the homepage.

Ignoring what an actual login component might have, a VERY simplified version of the location logic might look something like this:

import { useLocation, useNavigate } from "react-router-dom"

const location = useLocation()
const navigate = useNavigate()

	navigate(
	location.state // If there's state aka `prevLocation`
		? location.state.prevLocation // go to the url they originally wanted
		: "/home", { replace: true } // else, just go back home
	)}

In this example we sub out the component version of <Navigate /> with the useNavigate hook. They are one in the same; all you need to know is that:

== <Navigate /> == - If you need automatic or conditional navigation during the render process (e.g., redirection after successful login etc.).

useNavigate - You need navigation to occur in response to user actions or events (e.g., button click, form submission, or similar interactive events).

If you're wondering what the { replace: true } object is. Similar to a call stack, the browser gives us some built functionality called the History stack. replace = true just means that our navigate hook is going to replace the current location, which at this point would be /login, with the previous location ..

which would be something like:

/blog/secret-post-behind-auth-wall

User-flow

User tries to get this end point

Is booted to the login

• Previous path was /home/secret
• Current path after the Navigate push is /login
• URL history now contains a state object with `prevLocation: '/home/secret'

User is navigated to the original page after login

Thoughts on Static Site Generation in React

Suprisingly, static site generation (SSG) is somewhat counterintuitive for native React/React Router apps; why is this?

Generally, a static site is quite easy to churn out. Like me, if you’re a year 1-ish developer, you're probably working on a little portfolio proj.

If you're looking to pad your resume with simple get-to-know-me style site, save yourself some time and just use GH pages.

For this site, that won't really work, because:

• a) the project is a monorepo and relies on external data.
• b) my experience maintaining the site matters, and I have specific requirements for how it is updated.
• c) i want to use the patterns I learned in school and get practice working in larger codebases.
• d) building a thing exactly to my spec, I would consider a form of self love! :)
• e) doing hard stuff is fun.

Huge caveat; part of my frustration with SSG is probably self inflicted as I get closer to waving goodbye to this phase of the project.

e.g., “if it’s not released, then it can’t be judged, and I can maintain a belief about myself that goes unchallenged/unseen”.

However, if you're reading this, then that means I've most likely released it out into the world; which also means I've gotten over that weird internal belief and conquered the SSG behemoth.

Weird things

My confusion is mostly re: Dynamic Routes and some discoveries I’ve had while exploring React’s nuances.

I hoped (assumed) that React, out of the box, would provide an opportunity to perform SSG, and technically it does, if you use React Router… in Framework mode.

Over the summer I finished Scrimba's React course - highly recommend. In that course, as well as college, the learning arc for React is that you build in Declarative mode, using BrowserRouter, Routes, Route etc.

The way React was described to me was that, it’s a declarative framework, just generally.. not that it’s declarative nature was a component of its Declarative modality.

In this new mode, all of the same rules, structures and patterns are more or less what you’re used to, but if you’ve already built an application in Declarative, it takes a fair bit of refactoring to adjust to Framework mode.

I would appreciate if more introductory tutorials disclosed that React has different modes, because the fundamental patterns change a little bit when you alter the mode. Learning anything has a sweet spot for maintaining inertia and I found context switch here to be a pretty jarring.

Maybe the folks at Vite could build some of these questions into the npm create vite@latest command. Perhaps: what are you building, does it have a backend? etc - then have it select your mode for you.

Like most technical documentation, software people aren’t always writers, which means that there’s lots of documentation out there that doesn’t effectively speak to the reader.

There are many options for SSG and most options don’t require that you pivot from Declarative mode. For me, I didn’t want to throw away the monorepo pattern and I’d like to gain more experience working on full stack applications. I also think it’d be advantageous if the codebase could resond to change. That way, I can practice a multitude of deployment strategies, on an architecture I’m familiar with.

Static site? Yep. Containerized app? Yep. I could easily convert and deploy this on an EC2 instance as well.

There’s lots of language surrounding SSG and it seems most commonly recommended that you use Next.js for SSG as the framework is built for it. Which again, what the heck is Next.js?

Coming from solely React, adopting another framework felt like a lot of overhead just to pass the build stage. Then I found that there are SSG frameworks like Astro. Which also seems very intriguing, but the same issue here. I just spent the last few months learning the ins and outs of React, to adopt a new framework?

Anyway, if your situation is similar to mine and you’re looking to do React native SSG without adding another framework or library, then your app needs to be in Framework mode.

I’ve landed on using React Router’s native SSG functionality and I’m sticking with it god dammit. In the refactor process, I did have to throw away a bunch of hooks and context wrappers. Which overall simplified my app, but I was a little sad to throw away.

React Router allows you to pre-render whatever endpoint you want. When you build your app, all of the data fetched from the backend can also be included in your static build. A couple things need to happen to make this work.

You need to use loaders. Loaders are essentially just React Router reserved functions that you use to fetch data. Whatever file fetches data, add a loader to the top of that file ‘loader’.

1. Inside the function, make a fetch request and return the data in whatever format you need for the component file you’re in.

2. In the component definition add a parameter called loaderData. Inside your component above your return, assign the value to the loaderData.

3. The loader is important because in your react router configuration file, it will look for a loader, and then go “ah, yes, a loader, I can see this data, I will preserve this data in your static build”.

4. You also need to make a fetch request in your pre render block, which seems a little redundant, as a pattern, but oh well. That’s ALMOST it. The rest is just getting your mind around the formatting of how Framework mode structures the route table, then writing your almost usual react code to build your pages.

5. When you’re building, make sure you run the backend server so that the data can be queried from the frontend during your build. Once it’s built, you can serve the build files on whatever platform you like.

Below is some technical documentation I’ve written on how you could implement a simple monorepo application using Express on the backend, with a React (Framework mode) frontend, that at build time pre-renders all dynamic routes into a zippy little static site.

react-router.config.ts

import type { Config } from "@react-router/dev/config";

export default {
  appDirectory: "app",
  ssr: false,
  async prerender() {
    const res = await fetch("http://localhost:3000/api/v1/birds")
    const birds: string[] = await res.json()
    return ["/", "/birds", ...birds.map((b) => `/birds/${b.toLowerCase()}`)]
  },
} satisfies Config;

In Framework mode you'll have a new file called react-router.config.ts - inside this file you specify your rendering strategy. Note that the above example assumes you're working in a mono-repo, and the backend is fetching "birds" from somewhere else.

In the config, do three things:

• Prefix a property called prerender() as an async fetch request to any endpoint(s) your Frontend needs from the Backend
• Set SSR to false
• indicate the root directory of your frontend.

The simplest file structure you could have is something like this:

frontend/
├── .react-router/
├── app/
│   ├── routes/
│   ├── app.css
│   ├── root.tsx
│   └── routes.ts
├── node_modules/
├── public/
├── .gitignore
├── package-lock.json
├── package.json
├── react-router.config.ts
├── README.md
├── tsconfig.json
└── vite.config.ts

Note: The backend would be at the same level as the frontend dir

In the return block, specify all of the routes you'd like to pre-render, which is likely all of them. The third route in my example is where your app may deviate from mine.

In this example, I'm dynamically generating slugs using data from the backend via the map method. The data being returned in this example is an Array with three values, so there's nothing fancy going on here; however, your fetch request could look something like:

return ["/", "/birds", ...birds.map((b) => `/birds/${b.slug}`)]

Dependent on the shape of your data coming in of course.

I'm not going to explain the format of how Framework mode asks you to set up routes, but as an example, here's a basic route hierarchy containing:

"/"
"/birds" "/birds/:slug" <-------- (dynamic)

routes.ts

import { type RouteConfig, index, prefix, route } from "@react-router/dev/routes";

export default [
    index("routes/home.tsx"),

    ...prefix("birds", [
        index("routes/birds.tsx"),
        route(":slug", "routes/birdslug.tsx")
    ]),
    ] satisfies RouteConfig;

And by golly, we've made it to a component definition. This is your bread and butter right here. Notice the use of loader at the top.

The Birds component accepts loaderData which is equal to our backend response.

**`birds.tsx

import { NavLink } from "react-router";
import type { Route } from "./+types/birds";

export const loader = async () => {
  const res = await fetch("http://localhost:3000/api/v1/birds")
  const birds: string[] = await res.json()
  return { birds }
}

const Birds = ({ loaderData }: Route.ComponentProps) => {
  const { birds } = loaderData

    return (
        <div className="bird-div">
            <h1> Birds </h1>

            <ul>
                {birds.map((b) => (
                    <li key={b}>
                        <NavLink to={b.toLowerCase()}>
                            {b}
                        </NavLink>
                    </li>
                ))}
            </ul>
        </div>
    )
}

export default Birds

Look at this beautiful app. Wow :')

/birds route in the browser

Here's our dynamic page that renders a unique bird depending on what the user clicks on

birdslug.tsx

import type { Route } from "./+types/birdslug";

export const loader = async ({ params }: Route.LoaderArgs) => {
  const res = await fetch("http://localhost:3000/api/v1/birds");
  const birds: string[] = await res.json();
  const bird = birds.find((b) => b.toLowerCase() === params.slug.toLowerCase());

  if (!bird) throw new Response("Not Found", { status: 404 });

  return { bird };
};

export default function BirdSlug({ loaderData }: Route.ComponentProps) {
  return (
    <div className="bird-div">
      <h1>{loaderData.bird}</h1>
    </div>
  );
}

The params parameter in this loader is just looking for the part of the URL that is dynamic. In our case, it'll will be the name of a bird e.g., "bluejay". If that looks odd, don't worry. Just pass the params parameter to all of your dynamic routes and write your logic however you see fit. I match the bird to the slug, but you can probably achieve this a zillion other ways.

The type import at the top is a form of type safety imposed by React Router.

React Router generates types for each route in your app to provide type safety for the route module exports.

Again, not going to go into much detail here, as I myself am not very familiar with the intricacies of Type Safety in React Router, but if you don't see these types anywhere, you'll get a bunch of red squiggly's. You can generate these types for your app via the react-router typegen CLI command.

React Docs on the topic

**`/birds/:slug (bluejay) route in the browser

Cool, okay, so we're ready to build our app.

Run the backend, then in a separate terminal, run your build command.

In your frontend directory, if you want to inspect the contents of your build, run the npm run preview command, and voila.

Javascript Sort() Behaviours

Something I learned today that I find interesting is how the sort() method in Javascript selects its sorting method at runtime. I was playing around on pythontutor.com while practicing the "is it an anagram?" leetcode challenge on Scrimba and noticed something odd.

When you sort the string "convexsphere" is compares index 0 with index 11.

However, if I sort the string "rosie" (my cat) it compares index 0 with index 1 first ... huh?

Apparently the sort sequence is chosen by the Javascript engine under the hood. In this example the sort method decided what characters to sort first based on the length of the array.

HOWEVER, this isn't accurate as of July 2026, because I checked what node version pythontutor.com was running and it returned v.6.0.0, which uses an older sorting alg that assesses sort order based on character length. In v6, smaller arrays used to default to an insertion sort, whereas longer arrays defaulted to quick-sort.

None of this matters anymore because the most up-to-date JS engine uses something called Timsort, which scans the array to find small segments that are already sorted, and then a bunch of other more efficient oprerations.

TimSort begins by examining the first two elements of the array, but after that I'm not entirely sure what it would do to the previous two examples.

Anyways. Fascinating stuff. I mainly wanted to look this up because I was curious what the values of a, and b were in the callback method. So, in case you ever wanted to know, the a and b in your callback are simply whichever two elements the engine has decided to compare at that moment.

Visual Example

[!NOTE] What's happening??

• SomeComponent passes a function as a prop called doSomething.
• Within the component definition doSomething is given a state value
• Because the value is unknown at the top level, the component passes a value upwards in the hierarchy

In the below example, the App level component is in charge of determining the jsx that gets rendered. Internally, the Decision component has a boolean state value that flips back and forth on an onClick event.

When clicked the variable is passed to the render prop, which is passing a function. The function accepts a boolean and then renders conditional logic based on the true/false value. When clicked the page displays a different message.

import React from "react"
import Decision from "./Decision"

function App() {
    return (
        <div>
            <Decision render={(goingOut) => {
                return (
                    <h1>
                        Am I going out tonight?? {goingOut ? 
                        "Yes!" : "Nope..."}
                    </h1>
                )
            }} />
        </div>
    )
}

export default App

import React from "react"

export default function Decision({ render }) {
    const [goingOut, setGoingOut] = React.useState(false)

    function toggleGoingOut() {
        setGoingOut(prev => !prev)
    }

    return (
        <div>
            <button onClick={toggleGoingOut}>Change mind</button>
            {render(goingOut)}
        </div>
    )
}

The rendered page: