More Javascript Operators

I found out about even more question mark operators in Javascript that I had no idea about. Looks like Javascript overloads ? for a few different things, let’s compile them here:

1. Ternary operator ?:

The classic conditional expression has been around since C.

const status = condition ? true : false

2. Optional chaining ?.

This was a new one for me. It’s a way for an object to safely access a property/method only if the property/method before it isn’t null/undefined. Stops evaluation and returns undefined instead of throwing. A great way to test if a property exists in an object without using a try catch, which means you can further chain it with other operators.

user?.profile?.name  // property access
user?.getName?.()  // method call that only calls if getName exists
arr?.[0] // array/computed access

3. Nullish coalescing ??

It’s like ||, it returns the right value only if the left value is null or undefined. || triggers the right value if the left is falsy. This version keeps it strict to null or undefined.

const value = value1 ?? value2
//if value1 is not null/undefined, set to value1. Else set to value2

4. Nullish coalescing assignment ??=

Basically an assignment version of nullish coalescing:

options.timeout ??= 5000 //assigns only if the variable isn’t currently null or undefined

Speaking of the nullish coalescing assignment, there’s also the other assignments for the guard operator and OR operator: &&= and ||=. They basically shorten things like:

value &&= newValue //sets to newValue if value is truthy
value ||= newValue //value is set to newValue if value is falsy

Express Project Structures

The first focus of FSO part 4A is on project structuring. Best practices when working with node/express is to split the app and server files. Splitting them will make it easier to maintain, re-use and test separately. This concept is called separation of concerns.

In order to follow best practices, moving route handlers to a dedicated module is required. The router object on express is a middleware, something like a ‘mini-app’, it’s only able to perform middleware and routing functions. It’s self contained and has no server of its own. Its pathing is also relative to where it was mounted. E.g.

const notesRouter = require('./controllers/notes.js')
app.use('/api/notes', notesRouter)

So instead of .delete('/api/notes/:id', (request, response, next) => {, it’s now just .delete('/:id', (request, response, next) => { inside the notesRouter itself.

Also,

const app = express()

This creates a top level application object. It’s the actual server instance that listens to the port on the machine. Which means that backend software has no awareness of domains, DNS, or URLs at all. It’s the thing above the backend that handles the translation of (URL -> DNS -> IP -> backend url) like Heroku/Render/etc.

What exactly handles the translation on PaAS is a reverse proxy (nginx, a cloud load balancer, etc). It is the thing that listens on the public-facing port (442), terminates HTTPS, and then forwards the request internally to whatever the app is actually running. This video is a fantastic resource that explains how nginx works internally.

I looked more into express project structuring and this article lays it out in more detail than FSO. Also, FSO’s note project structure is missing a services folder. Some of the files in FSO are combined together (E.g. controller file is combined with the service file, the route handler functions include logic that manipulates the data)

Project structure should be as follows:

controllers

• For files that deal with HTTP requests
• Validates/parses inputs
• Calls appropriate service/model
• const noteService = require(‘../services/noteService’)

const getAllNotes = async (req, res) => {
  const notes = await noteService.getAll()
  res.json(notes)
}

const createNote = async (req, res) => {
  const savedNote = await noteService.createNote(req.body)
  res.status(201).json(savedNote)
}

module.exports = { getAllNotes, createNote }

models

• Database stuff. Data schema definitions

const noteSchema = new mongoose.Schema({
  content: String,
  important: Boolean
})

module.exports = mongoose.model('Note', noteSchema)

services

• For program logic, like calculations, data handling etc
• The stuff handles the manipulation of data, the stuff the controller will call for their HTTP requests
• Doesn’t contain raw connection/query code for the database (that should be in model instead)

const Note = require('../models/note')

const createNote = (body) => {
  const note = new Note({
    content: body.content,
    important: body.important || false,
  })
  return note.save()
}

module.exports = { createNote }

utils

• Small pure functions like date formatting, currency conversion etc
• Type of tools that can be copy pasted into completely different projects without any modification whatsoever

exports.formatDate = (date) =>
  new Intl.DateTimeFormat('en-US').format(date);

routes

• Maps the URL/methods to controller functions
• Should not contain any logic

const notesRouter = require('express').Router()
const notesController = require('../controllers/notes')

notesRouter.get('/', notesController.getAllNotes)
notesRouter.post('/', notesController.createNote)

module.exports = notesRouter

config

• For configuration files (e.g. dotenv etc)

It’s going to take a lot of practice before I can instinctively separate things out like so. That’s many files and folders to traverse.

For security reasons, browsers have a Same Origin Policy.

Same Origin Policy (SOP): Scripts from one origin cannot modify other origins. What constitutes the same origin: If their protocol (http vs https), their host (URL) and port is the same.

This is to stop websites from reading or modifying other websites maliciously (DOM access, response content of fetch/XHR, localStorage etc). Some things are allowed cross-origin, but restricted: Cross-origin image,script or iframe (but reading its content is not allowed) Sending cross-origin form submissions or ‘simple’ fetch requests, but you can’t read the response without CORS headers allowing it.

Also, this means that a single origin could modify the DOM of another tab if the origin has reference to the tab’s window object and is of the same origin (e.g. Tab A opens Tab B via window.open() or iframes)

Cross-Origin Resource Sharing (CORS) is a mechanism that helps allow origins to request data from other origins. Basically the server receiving the request needs to have their Access-Control-Allow-Origin header to explicitly allow the origin to make requests (or use a wildcard * to allow any origin to make the request). If there’s a mismatch, the browser errors.

It’s important to note that it’s the browser that blocks reading the response, and it’s the server that tells the browser if a request from an origin is allowed.

Browsers also preflight requests. For ‘non-simple’ requests (PUT/DELETE, custom headers, json content etc), the browser sends an OPTIONS request to check permissions via Access-Control-Allow-Methods and Access-Control-Allow-Headers before sending the actual request.

The wildcard * doesn’t work with credentials. If the request includes cookies or Authorization headers, & is rejected by the browser. The server MUST specify an exact origin and set Access-Control-Allow-Credentials to true.

Deploying to the Internet with Render

With Render, I began my very first exposure to hosting a full stack web app on the internet.

Render is a Platform-as-a-Service (PaaS) provider. Basically, we can deploy our web apps to the service and it takes care of the deployment, scaling, SSL certificates, OS, middleware, databases and other services to host our application.

In cloud computing (Which is basically on demand rental IT resources and computing services, like servers, storage, databases, over the internet. Pay as you go services), there are four services:

• Infrastructure-as-a-Service (IaaS)
• Containers-as-a-Service (CaaS)
• Platform-as-a-Service (PaaS)
• Software-as-a-Service (SaaS)

It’s a lot and a lot to cover, a really useful resource that goes through all of them is this article from Google Cloud.

This image from the article summarises each service pretty well:

Anyway, for Render, it works via pointing it to a git repo and it builds the application and deploys on push.

So far, pretty good. Getting my web app hosted was really that easy with it. I completely understand why Heroku was so popular back when it was still a free service.

Now for the database, FSO goes with MongoDB provided by Mongo Atlas. And as for using the database in our codebase, we use the mongoose library.

From this part of the course onwards, I can see how overwhelming web app development is and how many software devs say that they barely write code nowadays. With this much tooling and middleware, it’s seriously no surprise. I genuinely feel like this reddit post right now:

The dashboards themselves are incredibly overwhelming as well. I barely understand what’s going on and what I’m looking at.

But for now, I’ll cross my fingers and believe that a rough high-level understanding of what’s going on is sufficient. I never knew what every single button and menu did on Adobe Premiere or Photoshop myself after all.

Progress so far in a Diagram

A simple block diagram explaining the state of the stack:

This is what people call a MERN stack, which stands for: MongoDB, Express, React, Node.js

Alright, let’s take a look at the new theories introduced.

What is Node?

FSO and Node themselves state Node as: “Node.js® is a free, open-source, cross-platform JavaScript runtime environment that lets developers create servers, web apps, command line tools and scripts.”

That doesn’t really tell me much. But thankfully reddit users break it down perfectly in this thread. The tldr is:

• Node lets you run Javascript code outside of your browser
• Node is able to run HTTP applications written in Javascript

Node uses require() to import modules. This is because back when Node.js was created back in 2009, Javascript had no native module system (import/export ES modules only standardized in ES2015). So Node adopted CommonJS, which uses require() to import modules. Node currently supports ES6 modules, but in FSO they’re sticking to CommonJS modules.

Semantic Versioning

Semantic versioning is a way of naming versions numbers following the semantic versioning spec. It makes it easier to tell how much the new version has changed and if it’s backwards compatible.

So what’s this? OwO

"dependencies": {
  "my_dep": "^1.0.0",
  "another_dep": "~2.2.0"
}

The caret in front of ^1.0.0 means that if and when the dependencies of a project are updated, the version of Express that is installed is at least 1.0.0. But the installed version can have a larger patch number (the last number) or larger minor number (the middle number). The major version (the first number) has to be the same.

~ means that it only accepts patch releases (the last number).

const variables in javascript and pain

Javascript is such a special language because ahahaha ooh my GOD what is happening here?? I briefly mentioned it once in my previous post but my goodness, const not actually being an immutable constant is such a trip.

So how does it work?

In Javascript, a const is a constant reference to a value. Which means that it’s the memory address that the variable points to that cannot be changed. This is why you can modify attributes in a Javascript object but not re-assign it to a whole new object. The former is modifying the data in the same memory address, the other is re-pointing the variable to a different object in memory. This makes it much easier to remember and understand.

About HTTP requests

Some useful acronyms I’ll run into often in web development and network architecture:

REST (Representational State Transfer) is an architectural style meant for building scalable web applications.

CRUD: Create, read, update, and delete. The four basic operations of persistent storage.

There is also a request type HEAD, which does not return anything but status code and response headers (no response body).

The HTTP standard talks about two properties related to request types:

• Safety: Executing requests must not cause any side effects on the server (aka the GET request cannot cause any database changes). The response must only return data that already exists on the server.
• All HTTP requests should be idempotent: If a request does generate side effects, then the result should be the same regardless of how many times the request is sent. So HTTP PUT requests should result in the same thing no matter how many times the same PUT request is sent.

Both safety and idempotence are recommendations in the HTTP standard and not something that is guaranteed based on the request type.

I decided to try hosting this document on my github pages. For now I’ll be lazy and simply continue writing this in a google document, then export it all as a .html and push it onto the repo. The website is not the most readable and the content is stuck to the left of the container. I’ll have to do something about this.

Though to be honest, I’m not really sure how I would fix this. I guess I could make some sort of markdown viewer/generator that converts my entries into raw HTML that I’ll just tack onto the bottom of the page? That’s very neocities-esque but not quite smart web development wise.

There has to be a way to store each post data in some format and then get something to display it in some other format. I just don’t know enough to know how to transform that in this context (github pages). I’ll look into what Jekyll is.

EDIT 2026/07/12: I’ve ported the website to Jekyll. Now I need to look into making it look more interesting than the default minima theme

Full Stack Open (FSO) Progress thus far

In terms of FSO, I’ve finished up the optional exercises (part 2.18 to 2.20). Making something completely from the ground up all over again was a whole ride. My biggest trouble with the exercises was setting the states. It’s important to remember when I can use a component to display derived data and when I should use a state (the data is ‘interactive’ and changeable independent of other variables).

For example:

function App() {
  const [inputText, setInputText] = useState(null)
  const [countries, setCountries] = useState(null)


  const states = {
    inputText, setInputText,
    countries, setCountries,
  }

const Results = ({states}) => {
  //Filter search results based on what's inside inputText
  const filteredCountries = states.countries && states.inputText
    ? states.countries.filter(c =>
      c.name.common.toUpperCase()
      .includes(states.inputText.toUpperCase()))
    : []
 
  //Too many countries to display (more than 10 results)
  if (filteredCountries.length > 10) {
    return (
      <div>
        Too many matches, specify another filter.
      </div>
    )
  //Show list of countries that match search result
  } else if (filteredCountries.length < 10 && filteredCountries.length !== 1) {    
    return (
      <ResultsList countries={filteredCountries} />
    )
  //List only contains 1 country result.
  } else if (filteredCountries.length === 1) {
    return <CountryDetails country={filteredCountries[0]} visible={[filteredCountries[0].name.common]}/>
  }
}

When the user searches for a country, we return a list of the countries that match their search input. The data used in Results does not need to use a state, as it’s completely dependent on the input text box. If the input text changes, it re-renders the page, recomputing the filteredCountries array. It doesn’t hold any independent data that needs to persist through each page render.

I may sound like I am repeating myself, which I am (I already talked about this over a week ago calculating most votes), but writing these posts is really just part of how I study.

The real trouble I faced was actually adding a button that showed country details for each search result.

Now, the show button meant introducing an interactive element to the filtered search results. I first tried adding a visible attribute to the entire country and then using that button toggle that attribute each time it was clicked.

if (!countries) {
  axios
  .get(`https://studies.cs.helsinki.fi/restcountries/api/all`)
  .then(response => {
    setCountries(response.data.map(data => {
      return {
        ...data,
        visible: false
      }
    }))
  })
}

It worked perfectly fine, but it seemed incredibly wasteful to add a visible attribute to each and every (200+) country object in the array, when only the filtered results should care about something like that.

Adding the visible attribute to each object in filteredCountries was an idea, but it’s a derived variable. When I made the show button execute a function that changed visibility in the filteredCountries array, React has no idea that values on the page have been directly mutated, so it doesn’t rerender the component to show the updated values.

And since it’s a derived variable, when the page does get rerendered by some other state change, the filteredCountries array is remade and the visibility attribute is reset across the board again.

So I went back to the drawing board and thought about using a state for the filteredCountries result, but it was a pretty bad idea as it causes an infinite render loop whenever I set its state. Because when it updates, it re-renders the page, causing it to satisfy both countries and input box conditions, causing it to recalculate and set its state and re-render again, and so on.

I could fix it with useEffect, but it’s not a wise idea to use a setState inside of a useEffect, as it causes an extra unnecessary render. Inefficient.

The final fix was to create a state array of visible countries. Any country name present in the array means that its details are shown on the page.

const toggleVisibility = (visible, setVisible, countryName) => {
  //If country is not in the visible list, add to visible array
  if (!visible.find(c => c === countryName)) {
    setVisible([...visible, countryName])
  //Else remove it
  } else {
    setVisible(visible.filter(c => c !== countryName))
  }
}

And then each list item returns as such:

const list = countries.map(country =>
    <li key={country.name.common}>
      {country.name.common}
      <button onClick={() => toggleVisibility(visible, setVisible, country.name.common)}>show</button>
      <CountryDetails country={country} visible={visible}/>
    </li>
  )

Now the country details component can decide whether to be visible or not based on the visible array.

This was challenging but also incredibly fun. I have a very long way to go before I’m ready with all of this.

Callbacks:

Appears to be a fancy way people describe ‘a function that calls another function when necessary’. Like the anonymous function that is called during an addEventListener. Callbacks were used in Javascript for async code before promises became a thing.

There are two kinds of callbacks:

• Synchronous callback: Runs functions passed into it immediately, during the outer function’s execution. E.g. forEach, map
• Asynchronous callback: Runs functions passed into it after the outer function returns. E.g. setTimeout, addEventListener, Promise .then

Promises:

• Are a way to handle asynchronous code, it lets us wait for some code to finish before going to the next step
• Is an object, initialised by the Promise class, it requires a function as an input argument
• Runs whatever in the input argument function immediately
• There are two functions to run inside the input argument function of a promise, resolve and reject:
  • Both are functions for when the async work finishes, it becomes the function to pass the final value into .then
  • resolve is for when it succeeds, reject is when it fails
• Whatever after/outside the promise still runs immediately in its own thread (this allows Javascript to do multiple things concurrently)
• .then runs a function with the result of the promise after the promise is fulfilled
  • It always returns a new promise, which is why you can chain them together
  • Errors skip to .catch

Example:

const myPromise = new Promise((resolve, reject) => {
  setTimeout(() => {
    const success = true;
    if (success) {
      resolve('success!'); // this becomes the value in .then()
    } else {
      reject(new Error('failure'));
    }
  }, 1000);
});

myPromise.then(result => console.log(result));

Promise.all() lets us run multiple promises at the same time, and wait for all of them to finish
Promise.all([
  new Promise(resolve => loadProducts(() => resolve())),
  new Promise(resolve => loadCart(() => resolve()))
]).then(() => {
  renderOrderSummary()
  renderPaymentSummary()
})

Async:

• Returns a promise by wrapping whatever in the function in one
• Whatever the function returns gets converted into a ‘resolve(returned value)’
• Async lets us use await

I finished the supersimpledev tutorial today. Fortunately I haven’t forgotten React too much after this 5 day detour, and after 30 minutes of staring and console.log’ing my previous code for FSO, I’ve gotten comfortable with my code again.

The logical OR || operator in Javascript is so interesting. Like the logical AND (guard operator? They call it?), it returns actual values instead of pure true/false like in C.

OR Operator (||)
Const result = value1 || value2;
If value1 is true, the result will be value1. Else, the value will be value2.

A much shorter version of the ternary operator. And it plays into how Javascript has ‘falsy’ and ‘truthy’ values.

Falsy values are: null, undefined, false, NaN, 0, -0, 0n, ‘’ and document.all

Everything else computes to a truthy value. So an empty array or object is technically true in Javascript.

FSO uses the axios library to handle the RESTful requests to the backend. So no manually writing it out with fetch and await. I still find promises confusing, I need to get even more practice with it.

My ear infection meant staying home instead of going to work. And that means… More code time!

Useful array methods: .find helps find an element in an array. .filter helps filter elements in an array (returns a filtered array) .reject does the same thing as filter, but eliminates elements that fit the filter requirement .reduce uses an accumulator (I really need to find better words for this)

I need to look into what useEffect() (in React) is for exactly… I still have no idea what its purpose is, how to use it and when to use it.

I also should really look into promises, await and async in Javascript. The .then keyword is still confusing for me…

Copy-by-reference

I did not expect to get tripped up so quickly on how Javascript does copy-by-reference.

document.querySelectorAll('.js-add-to-cart')
  .forEach((button) => {
    button.addEventListener('click', () => {
      const productName = button.dataset.productName
      let matchingItem;

      cart.forEach(item => {
        if (item.productName === productName) matchingItem = item
      })

      if (matchingItem) {
        matchingItem.quantity += 1
      } else {
        cart.push({
          productName: productName,
          quantity: 1
        })
      }
      console.log(cart)
    })
  })

I was following a tutorial on vanilla Javascript (brushing up and need to get to understanding promises with SuperSimpleDev) and I was puzzled by how we created a new variable (matchingItem), then assigned it one of the objects in the cart object array, and then modifying matchingItem also modifies the element in the cart object array itself!

Wow! That’s so much more confusing than I expected! No wonder React has so much fuss about “do NOT modify the original value, use states and always copy by value”. It’s so easy to modify values directly in this language. const doesn’t allow direct modification but it allows… this… whatever this is…

So, .forEach in javascript goes through elements in an array directly (with no return value in each loop nor at the end of it all), while .map maps a new element to the array per element, and will finally return a whole new copy of the array.

One thing that I feel nice about is how much I’ve been having a blast using the array functions I’ve learned. Even though this is vanilla javascript and he never uses these in his code, I use them myself to make my code much shorter.

const totalPriceCents = cart.reduce((accumulator, cartItem) =>
  accumulator + ((products.find(product =>
    product.id === cartItem.productId)).priceCents * cartItem.quantity
), 0)

It’s shorter but it’s not too clean or readable. Oops.

Continuing this javascript tutorial side quest, I’m learning about Jasmine and testing frameworks.

Note to self: I need to look up the this key word in Javascript. And how its usage differs in classes, functions and arrow functions.

I thought I understood how states worked, but turns out, I don’t. Now, my understanding of it was simply “any element that refreshes its data on the page due to user interaction should use state”. But I realised that I didn’t need to use state for the most votes calculation (and display).

const App = () => {
  const [anecdotesObj, setAnecdotesObj] = useState(anecdotes);
  const [selected, setSelected] = useState(0);
};

const Display = ({header, anecdotesObj, selected}) => {
  return (
    <div>
        <h1>{header}</h1>
        {anecdotesObj[selected].quote}
        <p>has {anecdotesObj[selected].votes} votes</p>
    </div>
  );
};

const MostVotes = (anecdotesObj) => {
  let highestVote = {
    index: 0,
    anecdote: "",
    votes: 0
  };
 
  anecdotesObj.forEach((element, index) => {
    if (highestVote.votes < element.votes) {
      highestVote = element;
      highestVote.index = index;
    }
  });
  return highestVote.index;
};

From my primitive understanding of React, it appears that I can directly calculate the most votes because it derives its data from calculating the anecdotesObj. And each time a new vote is cast (and setAnecdotesObj is used), it will refresh anecdotesObj, causing React to re-render App, re-calling the MostVotes function.

Also, I had no idea that in Javascript, primitive types are copied by value, while objects (including arrays and functions) are copied by reference. So it’s like… C? Except with support for objects, and much more, of course.

Off-topic-ish Ramble

Those marathon length tutorial videos, turns out, are actually really useful and are the best thing ever! All this time I’ve been fumbling in the dark when all I needed was the foundational knowledge of computer science subjects, these videos and some documentation and I’d no longer be perpetually confused!

The people who yell “go build projects instead of following tutorials” are wrong. I tried doing that for years and would only get confused in my own search. Missing missing reasons is a massive obstacle for someone who doesn’t even understand the basics of x framework, library or language. People seem to forget that.

Or perhaps… I’m just too bad at this? I don’t think so.

Figuring how React works (The ‘what’)

React is so difficult to wrap my mind around. But in general, I feel this way towards any incredibly high level language. Tutorials simply tell you “when you declare/write … etc etc, you MUST do this.” But why?

There are many more new things to follow when working with something like React. For example:

function ChatMessage(props) {
  return (
    <div>
      {props.message}
      <img src="media/user.png" width="50px"/>
    </div>
  )
}

const App = (
  <>
  <ChatInput />
  <ChatMessage message="hello" />
  </>

In C, props in the function argument would be illegal, as the ChatMessage function call in App does not explicitly pass any variables/arguments into the function. Heck, the fact that there’s a const variable containing what looks like HTML that is also able to call other functions in the file is incomprehensible to me.

The answer is that JSX is syntax that gets translated into javascript by Babel afterwards. What is:

<ChatMessage message="hello" />

is translated into:

React.createElement(ChatMessage, { message: "hello" })

Which made me think… And realise that the way Babel works is not so foreign after all! In CS50W project 1, creating your own markdown to HTML translator with regex is an optional challenge. Babel follows the same principle. Apparently, Babel is what is called a source-to-source translator (aka transpiler). Though Babel’s own website calls itself a compiler. Is it a transpiler or compiler? Stackoverflow users say that they’re both.

Other notes

In any case, my arduous journey of learning Reacts syntax and their huge library officially begins…

Guard Operator (&&)
Const result = value1 && value2;
If value1 is true, the result will be value2. This works like an if-statement.

This is some Javascript syntax that’s useful to remember. I can use this for inserting if-statements directly in the JSX that renders HTML components. Like so:

return (
  <div>
    {sender === 'robot' && <img src="media/robot.png" width="50"/>}
    {message}
    {sender === 'user' && <img src="media/user.png" width="50"/>}
  </div>
)

Note to self: I really need to properly look into arrow functions and what’s the deal with them.

When I first tried to emulate the ‘I’m Feeling Lucky’ Search button, I used a hidden input field like so: <input type="hidden" name="btnI" value="I'm+Feeling+Lucky"> But I quickly realised it turns the regular Google Search button into an ‘I’m Feeling Lucky’ one too.

So I tried manually creating the logic for button click behaviour with some Javascript.

<script>
    const SEARCH_ENDPOINT = 'https://www.google.com/search';


    let luckyButton = document.getElementById("luckyButton");
    let regButton = document.getElementById("regButton");


    //Listen for button click event
    regButton.addEventListener("click", () => search("reg"));
    luckyButton.addEventListener("click", () => search("lucky"));


    function search(type) {
        let q = document.getElementById("inputBox").value; // search query by user


        // only search when the input box has a value
        if (q) {
            const url = new URL(SEARCH_ENDPOINT);
            url.searchParams.set('q', q);


            // if user clicked the lucky button instead
            if (type === "lucky") {
                url.searchParams.append('btnI', 'I\'m Feeling Lucky');
            }
            window.location.href = url.toString();
        }
    }
</script>

Interestingly enough, I noticed that the final line that sends the user to the new URL does not fire properly as long as the input form has the <form> tags in place. What would happen was that the javascript script fires first, and then the form (with no action parameter filled) redirects the user back to the home page, so nothing happens for the user. I created my own race condition.

Removing type="submit" didn’t work on the search buttons, because turns out, type="submit" is the default behaviour for buttons in the first place.

Though finally… I realised that all of that was incredibly unnecessary, I could have just used the name and value attributes to tack on parameters to the lucky search button itself..

<form action="https://www.google.com/search">
    <div class="row justify-content-center" style="padding-bottom: 1rem;">
        <div class="col-auto">
            <img src="media/logo.png">
        </div>
    </div>


    <div class="row justify-content-center" style="padding-bottom: 1rem;">
        <div class="col-md-4">
                <input id="inputBox" type="text" name="q" autocomplete="off" class="form-control">
        </div>
    </div>


    <div class="row justify-content-center">
        <div class="col-auto">
            <button type="submit" class="btn btn-light">Google Search</button>


        </div>
        <div class="col-auto">
            <button type="submit" name="btnI" value="I'm Feeling Lucky" class="btn btn-light">I'm Feeling Lucky</button>
        </div>
    </div>
</form>

Buttons in forms are both a part of form control and form submission data. Text field input name value pairs are always included during submission, but for buttons, they are only submitted when the specific button is used to submit the form.

This is a much better solution than the first idea of using a hidden text input field to tack on the search parameters. I feel pretty silly for not realising this at first. Oh well!