React – replacing an asynchronous .forEach() with for…of (and why it’s better that way)

In this post: My investigation into why ESLint didn’t like my .forEach loop and why for...of is the better choice for an asynchronous loop.

Key words: React, TypeScript, loops, JavaScript array iterators, forEach, for let, asynchronous

So there I was, .forEach-ing through some post replies when I noticed the code was triggering an ES-Lint error, no-loop-func:

Line 73:28: Function declared in a loop contains unsafe references to variable(s) 'repliesTotal' no-loop-func

My code seemed to work fine as it was, though.

const processUnreadReplies = async (userPosts: Post[]) => {
  let repliesTotal = 0;
  for await (let post of userPosts) {
    const replyArray: Array<Reply> = await getRepliesToPost(post.pid);
      replyArray.forEach((reply: any) => {
        if (!reply.read) {
          post.unreadReplyCount = (post.unreadReplyCount ?? 0) + 1;
          repliesTotal++;
        }
      });
  };
  setUnreadRepliesTotal(repliesTotal);
}

In English, this is what this code is doing:

  1. It gets all of the user’s posts as userPosts (and they are of type Post)
  2. It loops through each post in userPosts, getting that post’s replies as replyArray
  3. For each reply in replyArray, it checks each one to see if it is read or not by waiting on an asychronous function call
  4. If the reply is not read (reply.read is false), then it increases the post’s unreadReplyCount
  5. When it’s done with the loop, it sets a state variable called unreadRepliesTotal to the total it tallied up during the loop

ES-Lint’s documentation for no-loop-func was informative, but the examples didn’t make it clear enough to me what I had done wrong. Their “don’t do this” examples were "let i = 0, i < n; i++" and do ... while style loops, and I had a .forEach. They also didn’t have anything on the topic of asynchronous loops.

(Could my code be so awful that they didn’t even consider including it as a “do not do this” example? :D )

I decided to investigate.

First, I had to rethink my assumption that .forEach was the preferred ES6 style – maybe it wasn’t always the case, and maybe my case was one of them.

Two helpful (ie: plain English) posts I read while researching this problem:

For...in iterates through the enumerable properties of an object or array, which means it steps through all the X in object[X] or array[X]. You can still use it to access the elements of an array like so:

for (const idx in cars) {
  console.log(cars[idx]);
}

But that a more roundabout way of accessing the array data, and I soon found a more direct approach:

For...of was the next thing I tried and it worked just as well as my .forEach, but the linter liked it better.

const processUnreadReplies = async (userPosts: Post[]) => {
  let repliesTotal = 0;
  for await (let post of userPosts) {
    const replyArray: Array<Reply> = await getRepliesToPost(post.pid);
      for (let reply of replyArray) {
        if (!reply.read) {
          post.unreadReplyCount = (post.unreadReplyCount ?? 0) + 1;
          repliesTotal++;
        }
      };
  };
  setUnreadRepliesTotal(repliesTotal);
}

But why? I went back to the MDN docs and discovered an important tidbit I overlooked earlier:

forEach expects a synchronous function

forEach does not wait for promises. Kindly make sure you are aware of the implications while using promises (or async functions) as forEach callback. 

from the MDN docs on forEach

As far as ESLint could tell from looking at the code, every loop run by .forEach was returning void. Furthermore, using await does not pause the .forEach (I didn’t expect it to pause it, and I don’t need the previous iteration’s result for the next one, but I wanted to make note of that important distinction anyway).

In any case, this seemed like one of those times where the thing appeared to be working to the user, but could be done better and for...of was the preferred approach here. (There are plenty of opinions and debates about this, though.)

In summary

  • Use for...of for asynchronous loops in JavaScript/TypeScript
  • let creates a block-scoped variable, so in the case of my code the let is creating a new “reply” instance for each iteration of the for...of and each “reply” will be an individual reply from the array
  • .forEach() does not wait for asynchronous code to complete, which may not be a problem in your specific use case but ESLint can’t tell that so it flags it as a potential problem
  • await suspends the current function until it is resolved
  • for...of creates an individual function call for each loop, whereas .forEach() counts as one function call for all iterations

So there we have it – a better, ESLint-approved, way of writing an asynchronous loop in TypeScript/JavaScript.

Related

Godot 3.0: Exporting game data from Google Sheets into a staticData .gd file using node.js

If you’re making a Godot game with a bunch of “static data” such as items with stats and effects, quests, characters with stats, enemies, loot tables, spawn tables, etc. – then you might be wondering where to put your game’s data (and how to format it) in a Godot project.

When I first set out to do this I couldn’t find a great guide so I decided to figure it out and make one. My way isn’t perfect, but it gets the job done. 

My goals (and what I ultimately built):

  • Organize my game’s data into separate tabs in a Google Sheets spreadsheet.  Advantages: I would get to use Sheets’s validation features, I can access/edit my data from any computer anywhere, working in Sheets is easy and familiar to me and anyone who has used Excel.
  • Export from Sheets into something I can process into Godot objects. I went with JSON. (More on this later)
  • Turn the exported JSON into a game data file, which would be “globally” available for my game’s code to use
  • Easily access items, mobs, etc. by ID from within the game’s code. I want to do something like this: var sword = allItems[“Rusty Sword”].duplicate()

Setting up the game data in Google Sheets

If you’re doing something similar feel free to build your data however you like. I liked rows, with the thing’s id in the first column. 

This first example is the items sheet. These are all the swords, robes, armor pieces, crafting items, quest items, etc. in the game. Every item has a name, a “slot” it goes into, class restrictions, and stat bonuses. Typical RPG stuff. This sheet is very large, but it’s easy to search and I color coded by slot to help make it easier to find things. 

The next example is my game’s enemy (mob) data. Enemies (mobs) in my game just have a few stats, but you can see how the data could be built out to support much more complex monsters.

You might have noticed that the mobs have loot tables. Loot tables are yet another tab in the data sheet.

Google Sheets lets you set up “validation” so that some cells can only contain data from another sheet. (You can type the loot table name or pick it out of the dropdown that Google Sheets generates when you use validation.)

Adding a simple validation here helps cut down on typos and errors that result from things getting renamed. 

There are more data sheets for my game, but this should be enough to give you an idea of how to put your game data in a spreadsheet. Next up, exporting.

Exporting the game data as .json

I picked .json for a few simple reasons:

  • It’s easy to find Google Sheets to JSON exporters
  • I’m already familiar with JSON and it’s fairly human-readable
  • Godot has some built-in capabilities for parsing JSON

For the export itself, I used the free “Export Sheet Data” Google Sheets add-on (link). Just install it and find it in the Add-ons dropdown.

There are a bunch of settings in here to play with depending how you want your data formatted.

I wanted mine to be an array of objects, so the settings I checked are:

Checked settings: JSON format, current sheet only, Replace existing file(s), Export cell arrays, Export contents as array.

The exported data looks like this. (This is a super truncated version of what the items tab gets exported as.)

[
  {
    "name": "Novice's Blade",
    "icon": "sword1.png",
    "bodySprite": "sword1.png",
    "itemType": "sword",
    "consumable": false,
    "prestige": 0,
    "slot": "mainHand",
    "rarity": "common",
    "classRestriction1": "warrior",
    "classRestriction2": "",
    "classRestriction3": "",
    "classRestriction4": "",
    "classRestriction5": "",
    "hpRaw": 0,
    "manaRaw": 0,
    "dps": 2,
    "armor": 0,
    "strength": 0,
    "defense": 0,
    "intelligence": 0,
    "noDrop": false
  },
  {
    "name": "Rusty Mace",
    "icon": "mace1.png",
    "bodySprite": "mace1.png",
    "itemType": "mace",
    "consumable": false,
    "prestige": 0,
    "slot": "mainHand",
    "rarity": "common",
    "classRestriction1": "cleric",
    "classRestriction2": "paladin",
    "classRestriction3": "",
    "classRestriction4": "",
    "classRestriction5": "",
    "hpRaw": 0,
    "manaRaw": 0,
    "dps": 2,
    "armor": 0,
    "strength": 0,
    "defense": 0,
    "intelligence": 0,
    "noDrop": false
  }
]

Turning the exported .json into a .gd file for Godot 

Here’s what we need to do:

  • Open the .json file(s) (remember there’s one .json for every tab in the spreadsheet)
  • Parse it line by line and make any formatting changes necessary
  • Write the parsed and modified data to a .gd file that contains all of the game’s “static” data
  • Access the static data in the .gd file from the game’s code 

There are practically infinite number of ways to accomplish these steps (it’s just some file i/o and text parsing), but I went with what I already knew – Javascript. My quick-n-dirty parser (named “Parsely”) is far from beautiful code but it gets the job done.

You can see it in its entirety here: Parsely.js gist.

Parsely’s code is written specifically for my project, but one thing I want to point out is the way it transforms my objects. 

An object comes out of the Google Sheets exporter like this simplified example:

[
  {
    "name": "Novice's Blade",
    "icon": "sword1.png"
  },
  {
    "name": "Awesome Weapon",
    "icon": "sword2.png"
  }
]

But what I really need is this:

{
  "Novice's Blade": {
    "name": "Novice's Blade",
    "icon": "sword1.png"
  },
  "Awesome Weapon": {
    "name": "Awesome Weapon",
    "icon": "sword2.png"
  },
}

Notice the array has become one giant object, and each object is a property within that object. I want to grab my item by its name, ie: “Novice’s Blade”, and get the associated object data. I also want all this stuff to be in one giant object so I can grab objects directly without having to iterate through it (as I would have to if it were an array). 

So that’s what Parsely is doing when it does this:

for (var value of fromJSON) {
  var key = "";
  if (file == "items.json") {
    key = value["name"];
    formatted[key] = value;
  } ...
... 

It’s getting the name and making that the key, and it’s getting the whole object and making that the value. Now I have a giant object full of smaller objects, where each smaller object is a unique item in the game (like the second JSON example above).

Also, sometimes I wanted to add more parameters to an item at runtime, such as a unique ID or a boolean representing whether it was an enhanced item or not. Those things don’t exist in my spreadsheet, they’re just slapped on when this script is run. 

Here’s an example from parsely.js of three new params (“itemID”, “improved”, and “improvement”) being added to each item as it is processed.

For the sake of keeping everything related to my project in one place, I placed parsely.js and the .json files it processes in my Godot project folder like so:

When I export from Google Sheets, I download the .json file it generates and place the .json file in the appropriate folder (names, staticData, or timedNodeData). Parsely handles files from different source folders slightly differently, ie: files from names get built into arrays, files from timedNodeData get some “inProgress”, “readyToCollect” booleans attached, etc.

Finally, we can run it! I open a Terminal window and navigate to the Parsely folder. To run, I type:

node parsely.js

It then grabs those json files, processes them, and places them in res://gameData (which is where I want them to go).

Inside each of these .gd files is an object or an array formatted as one long line.

This is staticData.gd:

Here’s our data, organized into separate objects.

Using the data in my Godot project

Finally, make the staticData.gd file global by adding it in Project Settings > Auto Load. Now it’s accessible everywhere in the project. 

Now, throughout the project items, mobs, loot tables, etc. are all accessed from staticData like in these examples:

var newItem = staticData.items[itemNameStr].duplicate()

var loadout = staticData.loadouts[loadoutIDStr]

And that’s it! Now my game has all of its items, spawn tables, loot tables, quests, crafting recipes, and more pre-loaded as data objects and universally available anywhere in the game’s code.

JavaScript and Regex: Using a regular expression and .replace() to strip (foo) from a string

Here’s a quick tutorial on using regular expressions in JavaScript to edit a string and return the modified result. My strings looked like this:

"Toyota (1999 - 2005)"
"Ford (1995 and up)"
"Honda (up to 2015)"
"Kia or Chevy (any)

In this case, each string was the name property on an object. (Ie: you’re not looking at an array of strings in the example above.)

For display purposes, I wanted to show (in my app’s template) only what came before the first parenthesis, like so:

Toyota
Ford
Honda
Kia or Chevy

Thanks to guide on how to use regex to remove everything after a particular character, and this refresher on how .replace() works, I had this problem solved in a matter of minutes with the following expression, where params[0] is the string (more about why my method looks like this after the code):

export function stripParensFromCarData(params/*, hash*/) {
  return params[0].replace(/\(.*\)/,'');
}

I used this method in an Ember helper I wrote to format strings for display in a handlebars template. The helper was hooked up like so in the .hbs file:

{{strip-parens-from-car-data carString}}

My favorite tool for testing regular expressions as I write them is regexr.com.

AngularJS Infinite List – How to create a list that automatically adds a blank textarea as the user adds new data

This tutorial is about a neat trick you can use with ng-repeat and inputs using AngularJS. This is just one tiny part of a larger AngularJS project of mine you can explore here: Chicken Breast Meals on GitHub.

Let’s say you are building a user input form that lets the user input series of items in a list, such as ingredients in a recipe. You could have the user click a link to add a new input field before typing in each ingredient, but that’s an extra (and annoying) step nowadays for users.

What you really want is a list of inputs that grows itself, offering a new blank input in response to each addition the user makes:

dynamic_list_animation
Infinitely-expanding list grows as the user adds to it

PLUNKER DEMO

The rest of this tutorial uses the Chicken Breast Meals project code to explain how this feature was made.

Part 1: In the view (.html file)

The html code (and Angular directives) that create the ingredients list above is in app/views/admin/admin-edit-meal-view.html

<h2>Ingredients</h2>
  <ol class="ingredients-list">
  <!-- loop through and display existing ingredients -->
    <li data-ng-repeat="ingredient in formMeal.ingredients track by $index">
    <textarea name="ingredientLines" 
              type="text"
              data-ng-model="formMeal.ingredients[$index].name"
              placeholder="Add ingredient"
              data-ng-change="changeIngredient($index)">
    </textarea>
 <!-- trash can button -->
 <a href="" data-ng-show="ingredient" 
            data-ng-click="formMeal.ingredients.splice($index,1)">
 <img src="/assets/delete.png"/></a>
 </li>
 </ol>

When the user selects a recipe to edit in the admin page, that selected recipe is represented by an object called formMeal. Inside formMeal are properties like:

  • name (which is saved as a String)
  • yield (saved as a Number)
  • cookTime (another Number)
  • ingredients (an Array of Objects)

On the <li>

The ng-repeat directive builds the list of ingredients by creating a <li> and a <textarea> for each ingredient already found in the saved recipe data.  Each ingredient has an index in the ingredients array, so we grab its name out of the array of ingredient objects like so:

formMeal.ingredients[$index].name

Immediately following the ng-repeat directive is $track by index. This bit of code is easy to overlook but it’s very important: it’s what keeps the user’s current textarea in focus while the user edits it. Without $track by index, the app kicks the user out of that text box after the first typed letter. (Ask me how much fun I had debugging this lose-focus problem…)

In the <textarea>

Each ingredient is represented by a <textarea>, and each one has its own ng-model directive pairing it with that particular index in the array.

data-ng-model="formMeal.ingredients[$index].name"

This lets us edit an existing ingredient anywhere in the list by that ingredient’s index. Since ingredients is an array, we need to pass it the index of the ingredient we’re editing via the <textarea>. (You can read more about ng-repeat and $index here in the Angular documentation.) This placeholder part is straightforward:

placeholder="Add ingredient"

This is what puts the default text into each <textarea> when the user hasn’t entered anything yet. It’s just a nice UX touch.

Finally, we have an ng-change directive. You can read more about ng-change here, basically all it does is call the method (or do the thing) you tell it to do any time there’s a change in the <textarea> it’s associated with.

data-ng-change="changeIngredient($index)"

A change to the <textarea> (ie: user typing) causes the method changeIngredient() to run with each change.

Wait, where’s changeIngredient()? It’s over in app/js/controllers/cbm-admin-controller.js, which we will look at next.

Part 2: In the controller (.js file)

Now we’re inside app/js/controllers/cbm-admin-controller.js looking at the changeIngredient() method.

We already saw that whenever the user updates text inside one of those <textarea> regions, this method gets called. (If you were to put a console log inside changeIngredient(), you would see it called every time you typed a letter into the textarea.)

$scope.changeIngredient = function(index) {
   if (index == $scope.formMeal.ingredients.length -1){
     $scope.formMeal.ingredients.push('');
   }
};

changeIngredient(index) checks the index that’s been passed in:

  • if that index is at the end of the array (ie: its index number is one less than the array’s length), then we are editing the last ingredient in the list and we need to push an empty ingredient (”) to the ingredients array to make the empty box appear at the end
  • if that index is not at the end of the array, we just update whatever’s at this index since it’s an ingredient that already exists. This is why you don’t see an empty box get added to the end of the list if you’re editing a field that’s not at the end.

It’s important to observe that this method works by checking that the user is editing the last index (which is always the empty <textarea>). This is how we  don’t spawn new, empty textareas for editing earlier ingredients in the list.

What updates the ingredients list automatically? That’s Angular’s two-way data binding at work. Any time you update a model the change happens in real time.  If you’re new to Angular, here’s a Plunker demonstrating a very simple implementation of Angular’s two-way data binding.

Part 3: Offering an empty field by default

When you initialize your data or your app, you’ll need to include something like:

$scope.formMeal.ingredients = [''];

or

$scope.ingredients.push('');

so that the ingredients list has an empty one in it by default. Your implementation needs will vary, of course, but hopefully this little guide gave you enough of a start to build this “infinity list” into your own AngularJS form!

Don’t miss the Plunker demo of a simplified version of this feature that you can play with and adapt to your own project.

Book Review: You Don’t Know JS – Scope & Closures by Kyle Simpson

scope_and_closures_book_JS_kyle_simpson
Scope & Closures by Kyle Simpson

If you’re an intermediate JavaScripter who’s tired of weighty tomes and arcane examples, You Don’t Know JS – Scope & Closures by Kyle Simpson is right up your alley. This smart book takes a laser-focused look at scope and closures in JavaScript.

My rating: 5/5

Who it’s for: Intermediate JavaScripters. If you’ve heard of scope, closures, JS compiling theory, but aren’t sure you really understand them as well as you should, then this book is for you.

Review

Let me preface this review by saying I’m not a big fan of coding books.

I have been frustrated by out-of-date books, untested code, and overly complex explanations from coding wizards who have long since forgotten what it’s like to be a newbie. I’ve always been more of an in-the-trenches doer than an ivory tower studier, anyway.

So, I wasn’t expecting to like Kyle Simpson’s You Don’t Know JS: Scope & Closures book so much. A programmer friend insisted I read it, and 87 pages of golden JS secrets and epiphanies later, I’m glad I did.

This book is…

  1. Brief. No long-winded explanations or storytelling.
  2. Focused. One topic, explored deeply FTW.
  3. Short examples, usually just a handful of lines total.
  4. Easy-to-follow examples with good style choices, such as verbose variable names and comments listing the expected result.
  5. Concepts are explained and re-explained before moving on. This is complicated stuff for us intermediate JavaScripters, and he takes the time to attack topics from multiple angles.

Highlights

You Don’t Know JS – Scope & Closures covers:

  • variables: declaring, setting, and updating
  • scope
  • lexing
  • hoisting
  • closures
  • how the JavaScript compiler reads code
  • tokenizing

This book deserves credit for explaining the compiler’s process of operations in a way that actually clicked for me.

I also loved the short examples. They were easy to follow, none of that 30+ lines of code spread across two pages stuff you see in other books.

The book’s small size is a plus.  I took it with me on a day trip – hooray for books that aren’t the size of my laptop.

Criticisms?

The only thing I might say is that some examples in the book are like, “Yeah, duh, don’t do it that way” but to be honest, I probably had to be told some of these “duh” things myself when I was starting out a few years ago.

Overall, I’d give this book an A+. It fits into the vast gulf between “total n00b” and “JavaScript Jedi”.

Check it out on Amazon.com for the current price (as well as any coupons and deals that might be running).

Note to readers: TILCode is an Amazon Affiliate. Purchases made through some links on this site help support the site at no extra cost to you. Read the full disclosure here.

Read this: Airbnb’s Excellent JavaScript style guide

Today I learned… that Airbnb has a fantastic JavaScript “style guide” available for free on github. The guide is light on long-winded explanations and big on DO and DON’T examples. Check it out, it’s a 15 min read at most.

Here are just a few of the things I learned from it:

Declaring multiple variables

A long list of variable declarations should be done with the unassigned variables last, and all declarations can share one use of var.

// multiple var declarations like so:
var items = getItems(),
    daytime = true,
    length,
    i;

I’m definitely guilty of var var var var var… but I’m not sure how I feel about this particular style. I like the clarity and editability of beginning each line with var, but for declaring lots of like items, I can see the usefulness of this style.

Shortcuts for the win

Instead of writing “if this thing is greater than zero”, you can just write “if this thing”.

Here’s an example:

// bad
if (cars.length > 0) {
  // ... code here
}

// good
if (cars.length) {
  // ... code here
}

Easy enough.

Comment with good style

Oops, I’ve definitely been getting this one wrong. Comments belong on their own line, not off to the right of the line the comment explains.

// bad
var active = true;  // is current tab

// good
// is current tab
var active = true;

Guilty. I’ll quit doing this, as tempting as it is for the sake of shorter files…

Saving a reference to “this”

Oops, here’s another mea culpa. I’ve been saving reference to “this” as “self”, but the style guide suggests _this as a better alternative.

I’m inclined to agree – I found “self” confusing the first time I encountered it, and its relation to “this” wasn’t immediately apparent.

// bad
function() {
  var self = this;
  return function() {
    console.log(self);
  };
}

// bad
function() {
  var that = this;
  return function() {
    console.log(that);
  };
}

// good
function() {
  var _this = this;
  return function() {
    console.log(_this);
  };
}

Those are just a handful of the discoveries I made while exploring this guide.

Be sure to check it out yourself and see what you could be doing better, and don’t miss the giant list of resources at the bottom of the page!

Declaring a variable as a number before adding to it with +=

Today I learned… that you have to explicitly declare a number variable as a number before you can increment it with += in JavaScript.

This is probably a boneheaded newbie mistake, but it had me stumped for several minutes. I declared a variable, var total; and then tried to add to it by writing total +=5.  And then I scratched my head as my code returned NaN.

1
2
3
4
var total;
 
total += 5;
console.log(total); //prints "NaN"

This happens because “undefined” and zero are not equivalent in JavaScript! 

Even though JavaScript isn’t “strongly typed”, you can’t add numbers to something that isn’t a number yet.

Declaring total by setting it to an actual number, ie: var total = 0, fixed my “NaN” problem.

1
2
3
4
var total = 0;
 
total += 5;
console.log(total); //prints a 5