Todd Cage Computer

In attempt to deeply (or even shallowly) understand core.async - I will be reading the book by C.A.R. Hoare.

Chapter 1

Objects interact with one another & with us.

This is described as actions and events.

Toaster Oven:

set timer (st)

set heat (sh)

open (o)

close (c)

insert food (i1f)

ding when finished (timer event) (o1ding)

Vending Machine:

insert quarter (in1q)

insert dollar (in1d)

extract cookie (cookie)

extract chips (chips)

extract quarter in change (out1q)

Classes vs Occurrences

In CSP, in1q is a "Class". There can be many occurrences of a "Class". This also has something to do with the letter "h"....?

Event - there are event Classes and event Occurrences

Class - an event description (something that can happen)

Occurrence - an actual occurrence of a described event in time

Alphabet - set of names of *EVENTS* considered relevant for a particular description of an OBJECT (like a vending machine)

~ An object can never engage in an event outside of its alphabet!

Events - should be instantaneous and atomic... Time consuming events *SHOULD* be denoted with 2 EVENTS: [start-event completion-event]

^ Time-consuming events split out this way allows for other events to occur between start/stop of a time consuming event.

Simplifications:

we ignore time (how long it takes for event x to conclude)

we ignore causality (internal mechanism vs. outside agent)

Process - the behavior pattern of an object

Simple Vending Machine: αVMS={coin, chips} Complex Vending Machine: αVMC={in1p, in2p, small, large, out1p}

This is how we define the alphabet of processes.

The alpha symbol denotes "alphabet"

The capital letters VMS (Vending Machine Simple) denote the object aka the Process

The lower case letters within the set denote events_

Key for Formulae:

words in UPPERCASE -> distinct processes

word in lowercase -> distinct events

P, Q, R -> arbitrary processes

a, b, c -> distinct events

x, y, z -> variables denoting events

A, B, C -> sets of events

X, Y -> variables denoting processes

For the components/CSS, I have been thinking:

Background Layer (hold the setting, not interacted with)

Interaction Layer (where on-click events and other interactive components will live)

Animation Layer (on top of everything, visible, not always in use)

How can I have a visible animation layer on top of everything that doesn't interfere with the Interaction Layer? Something to think about.

Features:

Game state save (in local storage)

Music on/off functionality (I have played with the idea of music in a webpage & it seems that user must interact with the page for this to work...not sure if that's accurate)

Dialogue that types and reveals itself as though its being typed (terminal text)

An original Lucas King font

I am thinking I will start small. Have two decision trees with two different outcomes.

I envision the first scene being a living room in the Old Turkey Point house. Perhaps I can do the drawings at first and when its ready to be presented to Lucas, we can spice it up with his incredible drawings.

The interaction layer, I would like to have arrows for look left and look right. Then, some items that can be interacted with.

I can never find this part of the codebase so I am making this post for my future self. It lives in dashboard.navigation, alright?

Let's examine what it's doing...

It's just a big cond statement. A function that returns true or false. The arguments are old-page and page. So we are comparing the page we are going to with the page with are leaving.

Each condition considers the old/new handler & the old/new route params. This makes enough sense to me.

But what happens when the function evaluates to true (the else AKA default case!!!!)?

trigger-page-shared-reset evaluated to true:

The re-frame app/db atom is modified

swap! is called to replace :app/shared-page with '{}', an empty map

Arguments of fns are also annotated with TS types. Return types are specified after the arg list:

Typescript is stricter abt calling fns with more vars than are set in the fn arity.

You can make args optional by setting a default value:

Objects in typescript need specified keys and value-type. You can set keys to readonly (so they won't be modified on accident). This is done with "type":

Right.

You can use "&" and "|" to spec out types that superset multiple types or vars that can be multiple types.

I'm watching MOSH.

Static Typing: type of variable is specified (not dynamically typed).

Javascript allows types to change at runtime. Typescript doesn't.

Downsides: compilation step is required + more strict, more annoying

So far it looks like the main benefit of Typescript is setting the variable type upfront to get LSP features and compile time errors based on types.

Seems useful.

Typescript Types

any - wildcard variable, can be anything (but this goes against the whole point of TS)

arrays - use type annotation like "let numbers: number[] = []" to specify what values are permitted

unknown - a typesafe version of "any" -> much more restrictive

never - useful in throw cases where we should "never" have a value

enum - best defined as a "const". This specifies a new type that can be accessed. I think this is used for props in React with TS? I think so...

Write.

Right.

For a long time I have wanted to work on a point and click adventure game. Primeagen is always saying that the best way to get better at something is to build projects related to what you are learning.

Specifications:

This will be a react application. I want access to bare bones CSS and Typescript. It would be a good idea to do a quick tutorial on typescript because I truly don't know anything about it.

I'll try this one out with Mosh Hamedani. I used to take his courses when I started out. He's good enough for me. Blog posts will come, yeah, yeah, yeah, yeah.

It will be a stateful application. I want to store the game state in local storage. I want there to be an option to clear local storage (to restart the game).

This is an entirely front end application. No databases.

React.js

Typescript

Svelte

Let's see how far we can get without any additional libraries. I am not opposed to adding external libs when needed, but I want to try to keep it bare bones for the sake of learning (even though it will be annoying sometimes).

Goals:

Strengthen understanding of CSS (animation, flex/grid, organization)

Strengthen understanding of React JS

Have fun doing a creative project

What now?

Well, I guess I am going to build it out. I want to draw up some designs on where components will live (container element, chapter components to render as the game progresses).

Let's begin this post with a lie:

"A component re-renders when its props change"

It isn't ******* true. **** you for saying that. I can't believe you would say such a thing.

What is the truth?

Really, think about it. Is there such a thing as the truth? jk lolololol

The Truth: Re-renders occur when state is changed. The component where the state is declared re-renders and then all of its children re-render.

If a state update does not occur, changing props will be swallowed.

Example?!!?!???

You have a local variable dingus set to true. If the variable dingus is set to false && dingus is passed as prop to a child component, what do you think is gonna happen? Nothing. Nothing will happen because dingus will be swallowed since no state change has occurred as far as react is concerned.

Remember: "Dingus will be swallowed."

It's important to remember that.

React.memo

A challenger appears in the fog. React.memo changes the above behavior. Nothing is static, everything is up for debate I guess, and when you think you understand something - the truth is that you just don't and you probably never will.

React.memo is a higher order component. If you wrap a component in React.memo, react will stop behaving as it normally does - and it WILL check for changes in props!!!!

If there are no changes in props, the re-renders of the children will not happen at all!

Don't use React.memo all the time, you sicko!! It's complicated!! You don't even understand it!!! But we will be covering it later as we continue reading this book. Just knowing about it is key. A better solution is to simply localize the state to prevent re-renders:

Nice. What have I learned today?

Rule of thumb: change of state causes a re-render in react

When a state change occurs -> the component and all of its children will re-render

Move state down (localize it) is a good pattern to prevent unnecessary re-renders

Changing props doesn't matter unless it's wrapped in React.memo (which is complicated and should not be done willie nilly)

A book about React...that I am reading...Let's look at an application that has a bunch of stateful components that take forever to load:

Wow. This sucks. How am I supposed to deal with this?

Allegedly, many react developers are saying that React.memo and useCallback is a good trick to stop all these slow components from re-rendering over and over again.

There are three parts of a component's lifecycle in React

Mount

Re-Render

Unmount

Can you believe that?

Mounting: the component instance is created for the first time. State is initialized. Hooks are run. Elements are appended to the DOM.

Re-Rendering: an already existing element is updated. State change is what causes a re-render. So - when state changes in a parent component, all of it's child components are re-rendered as well.

Unmounting: it's removed, whatever.

So we can see the problem here:

The state exists in the App component. When that state changes, all of the child components will be re-rendered (even if it only affects the Button and Modal Dialog). It's just the way react works. State change in the parent === re-render of all the children. Get it through your **** skull you freak ****.

I am not getting much out of chapter 3 of Advanced React. Allegedly, this is important information and I am trying to absorb it. My React knowledge is consistently biting me during work hours and I don't like being bitten.

Conditional Rendering and Performance

If an element is defined within a parent component - it isn't rendered until it's rendered. Otherwise, it just exists in memory. See here:

The footer will only render when it renders (when isDialogOpen resolves to true). This important because I guess it wouldn't be performant if it rendered right away behind the scenes. Creating objects in memory is much cheaper than re-rendering.

Default Values for Prop Elements

Looks like there are color and size props that can be passed to the icon. This ****** is saying that they may be left out on accident and *should* have fallback values. Sure. There is a lot of emphasis on overriding the defaults with provided values. That seems pretty obvious to me. Maybe I have an attitude problem today.

The concept of upsert in postgres....It's something like...

*Inserting* when the data is novel to the system & *Updating* when the data is already in the system (but how do it know?)

In Postgres, UPSERT is performed via INSERT...

But How Do It Know?

we must specify with *ON CONFLICT*

INSERT INTO tasks (name, priority) VALUES ('Respond', 3) ON CONFLICT DO NOTHING

If there is a unique constraint on name, and 'Respond' already exists in the database, nothing will happen.

But what if we want to update the 'Respond' row?

INSERT INTO tasks (name, priority) VALUES ('Respond', 300) ON CONFLICT (name) DO UPDATE SET priority = EXCLUDED.priority

See here, that the column name must be specified.

BONUS: You can call functions to unite the original row value with the incoming row value. Let's look at it

INSERT INTO tasks (name, priority, tags_array) VALUES ('Respond', 3, ARRAY['urgent']) ON CONFLICT DO UPDATE SET priority = EXCLUDED.priority tags = array_cat(EXCLUDED.tags, tasks.tags)

But what about trying to do this seemingly basic task in the twisted clojure honeysql syntax...

It cannot be as easy as this, can it?

Hmmm.....yeah it doesn't look too ****** up, I guess...

So, we have access to a function called (hdb/upsert-values-set-excluded) and another function called (hdb/upsert-values-do-nothing)

Let's start with the easier one I guess:

(hdb/upsert-values-do-nothing customer-schema/tasks [{:name "Respond" :priority 3] [:name] {:tracking? false})

Right, so it's a vector of values...that makes sense. You specify the "ON CONFLICT" columns in the third argument. Okay, sure. The tracking? map appears to be an option that specifies whether or not we pass auditing information to the database. OKAY, I UNDERSTAND EVERYTHING. If there is already a database row with :name value provided, then the row will be left alone, no update at all.

Looks like it's the same deal for upsert-values-set-excluded. For some reason, "set-excluded" confused me in the past. It still seems like a bad name for the function. I think I would have called it upsert-values-set-on-conflict, but that's my brain and I am a young old man.

Let's say we have a unique constraint on two columns and we want to upsert on them...

(hdb/upsert-values-set-excluded customer-schema/cars [{:make "Chevrolet" :model "Prizm" :rating 2000}] [:make :model])

If Chevrolet Prizm already exists in the database, the row will be updated with the new rating. It looks like our codebase doesn't have built-in ability to make function calls upon SETTING values.

Future topics I'd like to understand:

Async Clojure

Websockets