Taking a turn off of Global Variable road.

[TangibleDream]

In this stateful architecture plan I've got going* in my mind, I felt like I had two choices.

1. Pass important data from function to function in a kind of basket weave pattern.

2. Pass any important stuff to a global variable, and end the function.

Even if I had made a game loop work in a js/html operation, I would have made storage variables in the game loop wrapper function. Option 2 was fast and easy (at least in the early stages) but I'm feeling dirty, and I keep adding more variables as I progress.

Option one has a problem.

1. how do you pass a parameter to the next state change if the calculating function has ended?

Theory for an option one approach. You can bind the 'important stuff' as parameters to an addEventListener. The function can end, but the eventListener will remember the data because it is tied to the element..... I hope

I've assigned myself some light reading...

https://gist.github.com/hallettj/64478

https://www.lambdatest.com/blog/why-global-variables-shouldnt-be-much-global/

https://howtodoinjava.com/javascript/javascript-correct-way-to-define-global-variables/

• check last comment

[TangibleDream]

Article report: 1st one was from 12 years ago when var was the only option.

2nd is from 2018, but repeats the first's warnings, it also offers an excellent definition of memory leakage.

Memory leakage can occur when global variables pile up storing unnecessary info in main memory for occasional use. Your memory/speed is leaked out of the app when it is burdened with a grocery list of global variables.

If this was an enterprise application I was making, and not a mere chess game, overuse of global variables can be a real pain in the ass.

If I'm reading the lesson here, a global variable should be applied if it is used by x or more functions. Otherwise you should really try to pass it as a parameter. If my theory above works. It's a better solution as the memory allocated to the bound parameters will go to garbage collection once the eventListener or the element is removed.

3rd while a little challenging to read, as I interpreted, this suggested that I may be able to assign variables to a window object in the dom. I think from here I may be able to create variables that are local to a specific element. This may be useful because the variable is in ram only during eventListeners? I think?

Certainly ideas to experiment with.

[TangibleDream]

One nagging question to research. Can you use removeEventListener() on a listener with an anonymous wrapper function or .bind?

document.getElementById('actionButton').addEventListener("click", function(){stateOne('White')});

or

document.getElementById('actionButton').addEventListener("click", stateOne.bind(null, 'White'));

more about anonymous functions to pass parameters into listeners

[TangibleDream]

I left gameState a global because it just seemed the place to be. Same with color changed to colorPlaying.

[rcullito]

Hey Rob! It seems like your reasoning so far makes a lot of sense. Beyond memory leakage, my concerns with global vars would be around who is accessing the game state, and is this easy to reason about? A lot of frontend frameworks seek to tackle this by limiting, or at least applying conventions, as to when, where, and who, can write to the state, or in your case, the game state.

It looks like you already have a lot of nice functions like movePiece for incrementally updating state, the biggest concern I would have in working with global vars would be that only one actor is moving at a time, and that subsequent moves always are working with the latest board state (I see that you also have the refresh function). The JSON representation seems pretty cool for this. While I haven't done frontend JS in a minute, I know there are also some recent libraries dedicated to immutability on the frontend such as https://immutable-js.github.io/immutable-js/ (though it looks like you have enough light reading already!) It has some cool features like deep-freeze etc...