DEV Community: Mike Cronin

An Intro To JS Higher Order Array Functions

Mike Cronin — Wed, 01 Dec 2021 06:56:37 +0000

One of the most crucial skills in JS is understanding how higher order and callback functions work. Simply put, a higher order function is a function that: 1) takes a different function as an argument and/or 2) returns a new function. That's it. A callback function is just the function that gets passed in. These are comp-sci words that hides simple concepts. For example, this is basically all forEach does:

const fakeForEach = (arr, callbackFunction) => {
  for (let i = 0; i < arr.length; i++) {
    const value = arr[i]
    const index = i;
    const givenArr = arr;
    callbackFunction(value, index, givenArr)
  }
}

const myArr = ['a', 'b', 'c']
const myCallback = (val, idx, arr) => {
  console.log('Value at index:', val);
  console.log('Current index:', idx);
  console.log('Original array:', arr);
};

// these will log the same things!
fakeForEach(myArr, myCallback);
myArr.forEach(myCallback);

By passing in a function but not calling it we allow a higher order function, in this case fakeForEach or .forEach to invoke it with each iteration of the loop. Now lets break down some the major higher order array functions that come built in with JS.

Also, you can of course define the callback functions inline, but for the following examples, I'm explicitly creating a variable just so it's perfectly clear what the callback refers to.

// inline
arr.forEach((val) => {
  console.log(val)
});

// variable
const callback = (val) => {
  console.log(val)
});
arr.forEach(callback);

// both are fine!

.forEach

Function Description

.forEach iterates through an array without caring about return values. If you essentially want a basic loop or mutate an existing object, this is your method.

Callback Description

The callback for forEach takes in the value, the index, and the original array during each iteration. The return value of the provided callback is ignored.

Example

const letters = ['a', 'b', 'c'];
const callback = (val, idx, arr) => {
  console.log('Value at index:', val);
  console.log('Current index:', idx);
  console.log('Original array:', arr);
};
letters.forEach(callback);
// Value at index: a
// Current index: 0
// Original array: [ 'a', 'b', 'c' ]
// Value at index: b
// Current index: 1
// Original array: [ 'a', 'b', 'c' ]
// Value at index: c
// Current index: 2
// Original array: [ 'a', 'b', 'c' ]

.map

Function Description

.map is a lot like forEach, except that it builds up and returns a new array.

Callback Description

Like forEach, the provided callback gives you access to the value, the index, and the original array. Each individual return value from the callback is what gets saved to the new array.

Example

const numbers = [10, 20, 30];

const callback = (val, idx, arr) => {
  console.log('Value at index:', val);
  console.log('Current index:', idx);
  console.log('Original array:', arr);
  return val * 100;
};
const bigNumbers = numbers.map(callback);

console.log('bigNumbers: ', bigNumbers);
// bigNumbers:  [ 1000, 2000, 3000 ]

.filter

Function Description

filter is used to return a new array based off of values that pass a condition.

Callback Description

The callback has the value, index, and array, however it is the return value that's interesting. If an iteration has a truthy return value, the value in the array at that iteration gets saved to the new array.

const names = ['tom', 'ezekiel', 'robert'];

const callback = (val, idx, arr) => {
  return val.length > 3;
};
const longNames = names.filter(callback);
console.log('longNames: ', longNames);
// longNames:  [ 'ezekiel', 'robert' ]

.some

Function Description

Some returns a boolean if at least one of the elements in the array meets the given condition.

Callback Description

It's a standard value, index, arr situation. However, unlike the other methods so far, once the callback returns true, some will stop iterating through the array. That's becuase theres no need to keep going. Remember, some only cares if there's at least one value, if you want the exact number of truthy values, you should use either forEach and keep a count variable, or filter and then just use the length of the new array. The only way some will iterate through the entire array is if it never finds a value that returns a truthy value. At which point some will return false.

Example

const numbers = [1, 4, 9001, 7, 12];
const callback = num => {
  console.log('num: ', num);
  return num > 9000;
};
const isOver9000 = numbers.some(callback);
// num:  1
// num:  4
// num:  9001

console.log('isOver9000: ', isOver9000);
// isOver9000:  true

.every

Function Description

every returns a boolean, true if every value in the array passes the callback's condition, and false otherwise.

Callback description

The callback has the value, index, and array, we've come to know and love. It works exactly like some, where it evaluates the return values as truthy/falsy. However, it abandons iteration if a single value returns falsy, which is the opposite of some. It's kind of like || vs && short circuiting.

Example

const numbers = [9001, 9002, 7, 12];

const callback = (num) => {
  console.log('num: ', num);
  return num > 9000;
}
const areAllOver9000 = numbers.every(callback)
// num:  9001
// num:  9002

console.log('areAllOver9000: ', areAllOver9000);
// areAllOver9000:  false

The more complicated iterators

The next methods depart somewhat from the val, idx, arr pattern of callbacks and are a little more complicated. As such, let's explain them a little more in depth.

.reduce (basic use case)

This method reduces an array of values into a single one. The provided callback's first argument is the accumulator. The second argument is the current value. The main trick with reduce is that whatever the iterator returns from one iteration becomes the accumulator for the next. The final return value of reduce is whatever the accumulator has been built up to by the final iteration.

What about the first iteration?

reduce has an optional, but highly recommended, second argument that sets the initial value for the accumulator. If no initial value is provided, reduce will essentially take the first value of the array, treat that as the initial value and the second value in the array as the current value. In general, you should just always provide an initial value, as it leads to fewer bugs.

const numbers = [12,8,23,5];
const startingVal = 0;
const callbackFn = (accumulator, currentVal) => {
  console.log('Accumulator', accumulator);
  console.log('Value at index:', currentVal);
  // console.log('Current index:', idx);
  // console.log('Original array:', arr);
  return accumulator + currentVal;
}

const total = numbers.reduce(callbackFn, startingVal);
// Accumulator 0
// Value at index: 12
// Accumulator 12
// Value at index: 8
// Accumulator 20
// Value at index: 23
// Accumulator 43
// Value at index: 5
console.log('total', total);
// total: 48

.reduce (advanced use case)

At the end of the day, reduce just adds things up into an accumulator. But no one said the accumulator couldn't be...an object?? Look how you can use reduce to build up an object. For comparison, we do the exact same thing but using .forEach. The crucial thing to remember is now the initial value must be explicitly set an object. Also, we don't need them in this case, but the idx and arr parameters are still available.

const arr = ['x', 'y', 'z', 'z', 'x', 'z'];
const countForEach = (arr) => {
  const result = {};
  arr.forEach((letter) => {
    result[letter] = (result[letter]) ? result[letter] + 1 : 1;
  });
  return result;
};

const countReduce = (arr) => arr.reduce((acc, letter) => {
  acc[letter] = acc[letter] ? acc[letter] + 1 : 1;
  return acc;
}, {});

console.log(countForEach(arr));
// { x: 2, y: 1, z: 3 }
console.log(countReduce(arr));
// { x: 2, y: 1, z: 3 }

.sort

The default sort() method sorts things alphabetically. Which means [1, 3, 2, 11] would get sorted into [1, 11, 2, 3].` This is not ideal. To sort numbers correctly, you need to pass in a compare callback function. The compare function needs to return a positive number, a negative number, or 0. JS will then use these numbers to determine if the values are in the right order. So kind of like this:

js const compare = (a, b) => { if (a is less than b by some ordering criterion) { return a negative number; } if (a is greater than b by the ordering criterion) { return a positive number; } // a must be equal to b return 0; }
That's a very manual setup, which may be useful for sorting non-numeric values. However, if you're comparing numeric values, you can get away with a drastically simpler callback that still does the same thing:

js // sorts smallest to biggest (ascending) let compare = (a, b) => a - b; // sorts biggest to smallest (descending) compare = (a, b) => b - a;

Used in context, sort looks like so.

js const numbers = [4, 2, 5, 1, 3]; numbers.sort((a, b) => a - b); console.log('numbers:', numbers); // [ 1, 2, 3, 4, 5 ]

The compare function can easily deal with objects as well, simply access whatever property to need.

js const houses = [ {color: 'blue', price: 350000}, {color: 'red', price: 470000}, {color: 'pink', price: 280000}, ]; houses.sort((a,b) => a.price - b.price) console.log('houses:', houses); // houses [ // { color: 'pink', price: 280000 }, // { color: 'blue', price: 350000 }, // { color: 'red', price: 470000 } // ]

Something important to note here is that unlike the other iterator functions on this list, sort is not pure; it will mutate the original array instead of making a new one.

More higher order functions await!

This is just the base of the higher order mountain, there is so much more to explore about this concept. But, you should now have a pretty good grasp on the basics, and I encourage you to open up a console and play around with the values until it just feels second nature.

happy coding everyone,

mike

JS Constructor Params vs This: Which Do You Use?

Mike Cronin — Wed, 11 Aug 2021 13:22:08 +0000

I still never quite know what to do with JS constructor parameters and functions used in the constructor. I'll explain what I do and my logic behind my reasoning, but I'd like to hear what you all do in the comments. I haven't had much luck really Googling this particular topic so I hope this sheds some light on the subject.

This vs Parameters

Take the example below, would you do it like this:

class Person {
  constructor(name, age) {
    this.name = name;
    this.age = age;
    this.bio = this.setBio();
  }

  setBio() { 
    // pretend this is more complicated 
    return `Name: ${this.name}, Age: {this.age}`;
  }

  doThing() {
    // some server call that uses name and age 
  }
}

Or, would you do:

class Person {
  constructor(name, age) {
    this.name = name;
    this.age = age;
    this.bio = this.setBio(name, age);
  }

  setBio(name, age) { 
    // again, assume this was complex
    return `Name: ${name}, Age: {age}`;
  }
}

So, that's an extremely contrived example, but I think you get the idea. When dealing with constructor helper functions, do you pass in arguments, or just use this? Personally, my little rule is:

any function using properties inside the constructor uses the constructor parameters, not class properties

And the reason for that is that this technically breaks:

class Person {
  constructor(name, age) {
    this.bio = this.setBio();
    this.name = name;
    this.age = age;
  }

  setBio() { 
    // pretend this is more complicated 
    return `Name: ${this.name}, Age: {this.age}`;
  }
}

Since we're using class properties, you can't tell from line 3 that setBio has to be run after name and age have been set (again, pretend this is a more complicated function). However, using the parameters directly would prevent the order from mattering.

Generated on Generated

Then you can also have situations that require generated properties to exist.

class Person {
  constructor(name, age) {

    this.name = name;
    this.age = age;
    this.bio = this.setBio(name, age);

    sendEmail(this.bio)
  }

  setBio(name, age) { 
    // pretend this is more complicated 
    return `Name: ${this.name}, Age: {this.age}`;
  }

  sendEmail(bio) { 
    // some AWS ping to send an email
  }
}

Again, SUPER simple example, pretend that bio was actually worth a helper function to generate. But what do you do in that situation? I feel silly passing in a this property to a function, but if I don't I run into the same issues as before, that it's not clear that sendEmail can only be run after setBio is generated. And yes, comments or something could clear this up, but I would prefer programmatically safe code.

What are your thoughts?

So that's what I do, what have you come up with? And yes, I know that functional, non-class setups could side step this issue altogether. But I'm specifically looking for your take on class based decisions. Let me know what you think below and as always, happy coding everyone.

Start Using The jq Tool For JSON in the terminal

Mike Cronin — Tue, 03 Aug 2021 14:00:11 +0000

The jq command line tool is definitely one of my favorite finds. If you've ever "prettified" JSON by copying it into VScode, I'm about to save you like 6 seconds by showing how to format (and even filter!) JSON right in the terminal.

Download page, but on mac it's easiest to brew install jq if you already have homebrew installed

Pretty print json

First, look at the difference of this command line output:

It's night and day. The way to do this is couldn't be simpler, just pipe some output into jq:

# from a curl
curl -s https://api.spacexdata.com/v3/launches/latest | jq
# from a file 
cat raw.json | jq

Filtering your output

Besides nicely formatting your output, jq can also do some object and array filtering. Check out the official docs, but here's the tl:dr; on the handiest features.

Grab specific property or index

Sometimes your data isn't at the top level:

curl -s https://swapi.dev/api/people/ | jq
{
  "count": 82,
  "next": "http://swapi.dev/api/people/?page=2",
  "previous": null,
  "results": [
    {
      "name": "Luke Skywalker",
      "height": "172",
# ...

If we only care about the results array, we can specify that:

curl -s https://swapi.dev/api/people/ | jq .results
[
  {
    "name": "Luke Skywalker",
    "height": "172",
# ...

That jq .results tells jq to show us the results property. That . stands for the current input, in this case the curl response. If the response is already an array, you'd use .[0], or if a property points to an array, you'd put the property name and then the index:

curl -s https://swapi.dev/api/people/ | jq .results[0]
{
  "name": "Luke Skywalker",
  "height": "172",
# ...

Format objects in an array

We can filter for specific properties in each object pretty easily:

curl -s https://swapi.dev/api/people/ | jq '.results[] | .name'
"Luke Skywalker"
"C-3PO"
# ...

Instead of using an index, we just use [] to say we want the whole array. And by using the | pipe we are saying "pass each item in the array into this filter and show only the select properties". Two important things here: the whole argument needs to be wrapped in a string, and the second . now refers to each object getting piped in, not the original response.

Multiple properties

You can select more than one property by using comma separated values, but it's not super clean:

curl -s https://swapi.dev/api/people/ | jq '.results[] | .name, .mass'
"Luke Skywalker"
"77"
"C-3PO"
"75"
# ...

Instead, I recommend the object syntax:

curl -s https://swapi.dev/api/people/ | jq '.results[] | {name: .name, character_mass: .mass, vehicles: .vehicles[0] }'
{
  "name": "Luke Skywalker",
  "character_mass": "77",
  "vehicles": "http://swapi.dev/api/vehicles/14/"
}
{
  "name": "C-3PO",
  "character_mass": "75",
  "vehicles": null
}

The name of the property can be anything, and keep in mind that you can go as deep as you want. Finally, you'll notice that these objects are just floating in space. If you wanted to output this to a JSON file that's not good, so we can wrap the entire string argument in an array to get an array output:

curl -s https://swapi.dev/api/people/ | jq '[.results[] | {name: .name, character_mass: .mass, vehicles: .vehicles[0]}]'
[
  {
    "name": "Luke Skywalker",
    "character_mass": "77",
    "vehicles": "http://swapi.dev/api/vehicles/14/"
  },
  {
    "name": "C-3PO",
    "character_mass": "75",
    "vehicles": null
  },
# ...

And there you go! That's probably 90% of what you'll use this little tool to do. But still, check out the jq site for more methods and an online playground.

happy coding everyone,

mike

How to Make a Good Pull Request

Mike Cronin — Thu, 29 Jul 2021 13:38:06 +0000

Asking people to code review your pull requests can be terrifying when you’re starting out. You don’t want to bother anyone, but your work has to be reviewed! Part of growing as a developer is asserting yourself more and putting your work out there, but there are steps you can take to make your code an easy review. And once you start being in charge of projects, having easy to review code can be the thing that saves you from missing deadlines.

Leave PR line comments yourself

If you take nothing else from this article, take this: Line comments are a phenomenal way to tell people what you were thinking without having to get into the "is this comment necessary?" debate. You can leave overly mechanical comments on the PR itself that will speed up the review, without cluttering the codebase with things that can be figured out. Like this:

We had to switch all these h1s to h2s due to accessibility. Given that forms are only used inline and not as pop up modals anymore, best practice states that titles should be a sub heading. The style is still h3 anyway, so when QAing there should be no change.

That would be a terrible comment to actually add to the code. It's way too long, could be figured out by reading enough of the code, and talks about QA on the ticket. But as a PR line comment, it's great. It answers a question your reviewer might have and explains what behavior it should lead to during testing. You should add these comments when:

The logic might take a second to work through, so a hint would help
It requires knowledge of best practices that reviewers might not have
It takes information from other, non-altered files that don't appear in the review (eg, telling the review the shape of the object that a pulled in function returns, so they don't have to read the other file)

All these comments do is speed things up and decrease the number of questions the reviewer will have.

Limit your PRs to 100 lines* or less

This tip is more along the lines of "Ok we all know it, now actually do to it." There's a joke that says if you give programers 10 lines, they'll find 10 issues, but if you give them 1000, they'll say, "looks good!" It's funny because it's soul crushingly true. If you start to get into the several hundred line territory, or even the thousands, there's literally no way that someone will be able to understand it without taking days to figure it out. By keeping it to 100 lines territory, there's a decent chance that a reviewer can isolate your work against the previous code and find critiques to give. But the real trick to keeping your PRs small, starts with the ticket.

*That total doesn't include tests, snapshots, or generated files

Anything unrelated goes in a new ticket

This is kind of crucial because adding in a few unrelated lines here and there is probably the most common way that scope creep hits your work. It can be tempting to refactor things as you see them, but that can cause confusion when it comes to review. Did that other function NEED to be refactored for your new ticket to work, or is it just something you happened to fix while you were in the file? Remember, it won't always be clear to your reviewer. Instead, if you notice anything unrelated to you current ticket, you should categorize the work into a new ticket and throw it into the backlog. That keeps all your tickets tightly focused and easier to work on. And if your original ticket turns out to encompass more work than you thought, break it up into multiple tickets or multiple PRs. The bottom line is: keep your chunks of work small.

To be clear though, feel free to refactor and improve anything that is relevant to your work. If the very function that you're there to add something to could use some polish, go for it! Refactoring necessary code will make your review easier to read. But if a function has nothing to do with your current task, break out that refactor work into a new ticket.

Write tests like user stories

The reason that tests get a soft pass on that line limit is because they should be helpful to a reviewer. If they see tests like "renders a new modal when button is clicked," "has the 'next' button disabled when modal first appears," and "doesn't enable submission until all fields have valid entries," it's pretty clear what your code is supposed to be doing. In addition to giving more explanations, lots of tests will take some of the pressure off of your reviewer. They are no longer the only thing between production and your code, there are a bunch of new tests that programmatically take the guess work out of your feature. This diffusion of responsibility will make your PRs less stressful, so people will be more likely to pick them up.

Explain exactly how to test and QA it

If there's a special way to set up the environment, or certain inputs that need inputting, tell people! Basically, if there were ever steps that you had to take to set things up while you were doing the work, you have to write that down for your reviewer and QA team. Something like:

"In order to test the new validations, fire up the dev environment, and fill out the form to the last section. Then, try adding a bad phone number, email or name. The 'submit' button should stay grayed out, and each bad input should have a red ring around it. Specifically, add numbers and characters like !, $, ^ to the name field. Those should fail now."

Acceptance Criteria is a must

If your team doesn't have "Acceptance Criteria" on your tickets by default, I strongly recommend adding it in. This will give your reviewers concrete examples of what to look for when running your code. Ideally, those situations will also be put into tests as well. Also, if you're doing anything on the front end, adding screenshots of the before and after will help. Especially if there are several different outcomes that a user can see.

Assume no one knows what you're doing

Weird tip, but stay with me. Whenever you do a ticket, there's always some aspect of discovery. But, there's no reason to assume your future reviewer also had those revelations. Sometimes, people are asked to review work in projects they aren't that familiar with. If you had some epiphany that allowed you to complete the work, leave a sparknotes version of that as a line comment.

I know on one project I did there were two indexes that kept popping up. But, it turns out, only the first one was an index, the second was actually an op-code that got called several functions deeper. I added some named variables to remove the index assumption, but I also added a PR comment mentioning the exact function that the op code was used in, and what that function returned.

Listen to critiques

This is probably the MOST important one of all, because no matter how good your stuff is, no one will want to review it if you're an ass. Disagreements are fine, but always remain professional and courteous when getting feedback. You never want to become that dev who can't take constructive criticism. When someone points out an issue or question, assume they are right, and work from there. Don't instantly brush them off or ignore them. If you're right, prove it with examples, references, and business needs. And if it turns out you're wrong, that's ok! The point of a review is to use the team to come up with the best code, not just use your code.
Remember, any review where you learn something is a good review.

Happy coding everyone,

mike

Should You Use JavaScript Maps And Sets?

Mike Cronin — Mon, 19 Jul 2021 20:14:05 +0000

JavaScript sets and maps have been around for a few years now, but I still get a lot of questions about them. My students wonder if they should be substituting traditional objects and arrays with these new data types. While there are some killer use cases for sets and maps, you should really look at them like specialized tools and not Swiss army knives.

When to use sets

A Set is a collection, like an array, except each value must be unique. They’re like what would happen if objects and arrays had a baby. Here’s a crash course:

const mySet = new Set();

mySet.add(1); // add item 
mySet.add('a');
mySet.size; // 2 
mySet.delete(1)
mySet.has(1); // false
mySet.clear(); // empties set

You need to remove duplicates

This is probably the only time I’ve actually seen sets used in the wild. It’s a handy one liner:

const arr = [1,2,3,4,4,5,6,7,7,7]
const unique = [...new Set(arr)]
// unique equals [1,2,3,4,5,6,7]

You’re doing algorithm challenges

If you’re trying to solve literal set problems, sets are obviously the go to. You can see on the set docs how to implement the basic set operations. This stuff will probably come up when doing algorithm challenges, so it’s worth it to take a look.

When to use maps

Maps are honestly something that I personally thought would take over the landscape. But, then when you get down to it, they’re not as much of an upgrade as you might think. They are another way to store key/value data, but they’re more purpose-driven than objects, so they have some added benefits. Here’s a crash course:

const myMap = new Map();
myMap.set('a', 1);
myMap.set('b', 2);
myMap.set('c', 3);
myMap.get('a'); // 1
myMap.set('a', 'ok');
myMap.get('a'); // 'ok'
myMap.size; // 3
myMap.delete('b'); // removes b key/value
myMap.clear() // empties map

You need non-string keys

This is the most obvious benefit to maps, they can take pretty much anything as key. Objects will always stringify anything used as a key. For instance, if you tried to use unique objects as object keys themselves, they would all get stringified into '[object Object]' and overwrite each other. Luckily with maps, that’s not a problem! Each object would function perfectly well as a unique key. And if you used the same object key with a new value, it would overwrite the original value, just like you’d expect. It’s not a super common scenario, but it’s a good trick to know.

You care about insertion order

Technically, objects do kind of maintain insertion order with modern JS. HOWEVER there seem to be some caveats to maintaining key order. If you really need to be sure that your key/value pairs maintain their order for iteration, use a map.

You have a truly massive dataset

It varies by browser, but for Chrome browsers, Maps could hold 16 million entries, while objects could only hold 11 million. So … this is technically a thing, I just doubt you’ll ever hit it (if you do, please tell me what data you were wrangling).

And that’s about it!

If you thought those seem like pretty specialized situations, you’d be right. I bet you that there are edge cases that I missed (please post below if you know of any), but those situations above are the good stuff. Which means that you’re safe to keep using regular objects a vast majority of the time. If you really want to use maps and sets for readability or something, go for it. Just don’t feel like you’re missing out if you don’t.

Other gotchas

JSON can’t encode maps and sets properly yet, so that’s something that you may want to consider if you’re dealing with APIs. You’ll need to convert each map or set back into a plain old JS object first. I’m sure this will change in the future.
Also you might hear that some people say that Maps are worth it because they are iterable by default. However, since we’re already using ES2015+ syntax to get maps, then we’ll also have the Object.keys, values, and entries iterating functions as well. Which, sort of steals that thunder a bit. And to my knowledge, maps don’t have any iteration speed bonus. Which leads me to my last point.

Aren’t maps and sets faster?

…Maybe? On MDN’s maps page it says that they, “Perform better in scenarios involving frequent additions and removals of key-value pairs.” However, I personally haven’t seen that to be the case in my tests or research. It is true that the Map.delete function is faster than the object delete keyword, but there’s a catch. The Map.set function is slower than the internal object’s set method, so whatever bonus you get from faster deletes would get a huge chunk taken out by slower inserts. Also, certain browsers implement things differently, which means it’s not a consistent boost. In my, albeit limited, testing, I found objects were always faster, but not by much.

As for sets, there can be no debate that set.has is faster than array.includes (that’s O(N) for arrays vs. O(1) for sets). Unfortunately, set.add seems much slower than arr.push. So, if a list were big enough where searching was costly, the process of creating the set in the first place would be so slow that any speed boosts from repeated searching would be lost. I think if you were searching hundreds or thousands of times on a list with a ton of items, then sets might be worth it.

I’d always recommend actually performance testing your application before swapping anything. Just making up isolated JSPerf tests can't tell you nearly as much as actually timing your application. I don’t think there are any blanket cases where maps or sets have an edge with performance. I’m 100% sure there are edge cases, but those would need to be discovered after unique investigations. So far, it just seems like JS hasn’t prioritized performance with these new data types.

Final verdict

With the exception of those specialized use cases, there isn’t much of a reason to use the new data types. They’re new tools to add to your toolbox, not replacements.

happy coding everyone,

mike

How Recursion Works: The Easy Way (No Fibonacci)

Mike Cronin — Mon, 19 Jul 2021 13:48:19 +0000

If you’ve struggled to learn Recursion by using fibonacci or exponential JavaScript functions, then this article is for you. I had trouble with recursion at first because there are almost 2 aspects of “math” based recursion: the actual recursion, and the ever changing return values. Luckily, if we remove the return values from the equation, things get a lot simpler. We can accomplish this by focusing on iterating through an array.

What is recursion?

For a function to be recursive, it only has to do 2 things: 1) Call itself and 2) Know when to stop calling itself. That’s it, that’s all it takes. Technically, you don’t even need the second one. Sure, without it your function will explode, but it’ll explode recursively.

Let’s build a simple function

To start off, let’s make a base function. All it does is log a value in an array:

const recursiveFunc = (arr, idx) => {
  console.log(`- ${arr[idx]}`);
};

const arr= ['a', 'b', 'c'];

// this would log each value
recursiveFunc(arr, 0);
recursiveFunc(arr, 1);
recursiveFunc(arr, 2);

You might notice that the way to log each value is to call it with the index that’s one bigger. Right now we are the ones calling the function and incrementing the index, but what if the function itself did?

Making the function recursive

Let’s add the incrementing and calling inside the function.

const recursiveFunc = (arr, idx = 0) => {
  console.log(`- ${arr[idx]}`);
  recursiveFunc(arr, idx + 1);
};

There it is: a recursive function. It looks odd to see a function call itself, but all programming languages are more than capable of doing this. However, if we ran this as is, it would blow up. That’s because we never tell it to stop at any point. We still need requirement #2, a stop condition:

const recursiveFunc = (arr, idx = 0) => {
  if (arr[idx]) {
    console.log(`- ${arr[idx]}`);
    recursiveFunc(arr, idx + 1);
  }
};

Now, once we hit an index that’s not in the array, it won’t do anything and the whole chain of recursive functions comes to an end.

What’s actually happening

If you were to run this function, this is what you would get:

recursiveFunc(['a', 'b', 'c']);
// Logs out:
- a 
- b 
- c

Internally though, this is what’s going on

As you can see, we keep increasing the value of our index by one each time, so we move through the entire array. While the index value changes, the array does not. Once there is no value at the index, the function has nothing more to do, so we exit out of the function, which then completes all the functions moving up the chain. Take a minute to really internalize the logic of what’s happening here, because this is the focal point of how recursion works.

We have to go deeper

Our function meets our definition of recursion, but it can’t iterate through nested arrays recursively. This is no good, since that’s actually one of the real-world applications for recursion. See, loops handle iterations better, but they can’t easily handle nesting of unknown depth. That’s because if a recursive function found another nested array, it can just call itself again on that array.

To account for nesting, all we need to do is add a step where we check if the value is an array. If it is, we start over at index 0, if not, we carry on as we normally would:

const recursiveFunc = (arr, idx = 0) => {
  if (arr[idx]) {
    if (Array.isArray(arr[idx])) {
      recursiveFunc(arr[idx]);
    } else {
      console.log(`- ${arr[idx]}`);
    }

    recursiveFunc(arr, idx + 1);
  }
};

recursiveFunc(['a', ['x', 'y'], 'd']);

// logs 
- a 
- x
- y
- d

Here is a new version of our previous diagram:

What this does is start another chain of recursive calls on the new array. Look at how we pass in the new array and default back to 0 to start the new sequence. Once that sequence is done, we come back to our main chain. Also, notice that the final recursiveFunc call is after and outside of the array check. That’s because after we go down into an array, we always want to keep going when we come back up. For simplicity, we only nest once, but this could work with many more levels.

Double check by getting fancy

To ensure you understand the main concept, why not try adding another parameter? Let’s add a level parameter for nicer printing:

const recursiveFancy = (arr, idx = 0, level = 1) => {
  if (arr[idx]) {
    if (Array.isArray(arr[idx])) {
      recursiveFancy(arr[idx], 0, level + 1);
    } else {
      console.log(`${'- '.repeat(level)}${arr[idx]}`);
    }
    recursiveFancy(arr, idx + 1, level);
  }
};
recursiveFancy(['a', 'b', ['q', ['x',]], 'c']);
// returns 
- a
- b
- - q
- - - x
- c

Notice where we +1 idx and level, it’s not identical. We only increase level if we are dealing with a nested array, and we only increase idx if we are moving forward in an array. Now that the basics are done, it should be much easier to learn about recursive return values. Check out how they work with the fibonacci interview question.

Drawbacks to recursion

If recursion is so simple, why don’t we use it everywhere? Why are loops better for pure iterations? The reason has to do with the JavaScript Call Stack. I recommend checking it out, it’s a fundamental part of programming. But the long and short of it is: when you call a function, it gets placed on the call stack. Once it’s finished, it’s removed. But, the problem with recursion is that the first call can’t finish until all of the children functions finish. That means the call stack gets taller and taller. If it gets too high, it will all break.

That’s the issue with recursion, there is a maximum depth. You want one function that has a for loop that a million iterations? Neato. But a recursive function can start hitting issues way quicker. That doesn’t mean loops are better. It means we have to use recursion for more specific problems, like unknown depth or recursive data structures (Binary Search Trees). It’s just about finding the right tool for the problem.

Happy coding everyone,

mike

9 Neat JavaScript Snippets For Algorithms And More

Mike Cronin — Mon, 12 Jul 2021 17:52:20 +0000

Knowing certain JavaScript one liners can save you valuable time while developing or interviewing. Here are some of my favorite “once you know, you know” snippets that I have actually used while coding. Only one of them is a bit code golf-y, and unsurprisingly it uses reduce.

Wrap around a list

Spinning is a neat trick, but so is wrapping. A lot of times in algorithms you will need to wrap around a list. Meaning move a number of spaces, and if you reach the end of the list, go back to the first index. So if a list is 8 values long, but you have to move 10, you would need to land on the second index. You could use a bunch of complicated if statements, OR…

const wrap = (arr, steps) => arr[steps % arr.length];
wrap(['a','b','c'], 0) // a 
wrap(['a','b','c'], 1) // b
wrap(['a','b','c'], 2) // c
wrap(['a','b','c'], 3) // a 
// etc ...

You can implement this differently based off steps, but the key thing to understand is the modulo. It’s a handy little operator, keep it in mind when looking at “overflow” type problems like this.

Log a variable with its name

This is such a great trick when debugging. Thanks to object shorthand notation we can log out variables with names by default.

const someVar = 1;
console.log({ someVar });
// logs out { someVar: 1 }

If you put in a bunch of logs (and you totally will when debugging), it can be hard to keep track of which is which with all the asyncs, fetches, and loops flying around. Instead of having to take the time to type multiple args like console.log('some var', someVar), toss in some curly brackets and call it a day.

Optional properties in objects

If you don’t want properties pointing to undefined or null , you might use some if statements to optionally add properties:

//...
const obj = {
  a: 'whatever',
};
if (b) {
  obj.c = 'ok';
}
return obj;
//...

However, it’s verbose and I’ve always hated it. It may be clear, but it’s clunky. Well, thanks to object spreading, it’s a thing of the past:

return {
  a: 'Whatever',
  ...(b && { c: 'ok'}),
};

We can use a spread and && logical short circuiting to dynamically check whether or not to add the property by spreading it. This comes most in handy when you just want to return an object, and don’t want to create a temporary variable.

Sleep in JavaScript

A few times I had to deal with a terrible API that was slow and didn’t have a hook to say when it finished. So, we just had to wait a second to make sure it loaded. We also wanted to use promises instead of setTimeout callbacks, so using a sleep function was ideal. We could simply await for a second and then move on. No need for callbacks!

const sleep = (ms) => new Promise(r => setTimeout(r, ms));

Here’s how to promisify setInterval as well.

Swap variable values

Before modern JS, if you wanted to switch the values of two variables, you’d have to introduce a 3rd ‘temp’ value. Now that we have array destructuring and assignment, we can do it in one line:

a = 10;
b = 5;
[a,b] = [b,a];
// a is 5, b is 10

Round to nearest 10, 100, 1000…

This one is useful in algorithms if you need to rough out numbers to various levels. Basically, what you’re doing is dividing first to move the decimal up. With the “useless” numbers now decimals, you can round them off. To get the number back up to its desired size, you multiply it. The ignored numbers now become zeros. It’s a neat trick for dealing with money or logarithm-like scales where after a certain point, small numbers can be rounded off.

const rounder = (val, place) => Math.round(val / place) * place;
rounder(1549, 100); // 1500
rounder(15590, 1000); // 16000

Remove duplicates with Set

I just wrote about Sets, and apparently this is kind of their only use. If you have an array and you want to remove the duplicates, you can do so with a Set.

const val = [...new Set([1,2,1,3,1,4])];
// [ 1, 2, 3, 4 ]

Don’t forget to spread the new Set back into a regular array. Note: be careful with massive lists, as this may not be the most performant solution.

Count character instances

If you have an array (or array from a string) and want to know how many times characters appear, there’s a super slick way to do this with reduce.

const charTotals = (arr) => arr.reduce((totals, char) => ({ 
  ...totals, [char]: (totals[char] || 0) + 1, 
}), {});
charTotals('Hi there!'.split(''));
// { H: 1, i: 1, ' ': 1, t: 1, h: 1, e: 2, r: 1, '!': 1 }

This one might not be all that useful, but there are 2 techniques that I want to make sure you know: dynamic object properties and implicit returns with an object. Both of those things are crucial knowledge, and if you don’t understand reduce, then read this.

ID maker/counter

I think I needed to dynamically create non-db temp ids for react components and squished a classic counter into one line. Each time the function is called, the counter increases, and no other function can alter its internal state. It uses a closure, Immediately Invoked Function Expression, and a default value to keep things tight.

const counter = ((num = 1) => () => num++)();
counter() // 1
counter() // 2
counter() // 3

Also bonus tip to use default values in function parameters to avoid needing a new line. And you can stop making it an IIFE if you actually want to make the starting number dynamic:

const startCounter = (num = 1) => () => num++);
const counter100 = startCounter(100)
counter100() // 100
counter100() // 101
counter100() // 102

A word on readability

Look, I’m all about readable code and I’ll be the first person to say that some of these snippets aren’t super straightforward. What you get in brevity you lose in readability. Now, personally, I don’t think any of these are too wild, but others might disagree. That’s why you should try to use small, named functions and descriptive variables. These pieces can be the crucial tip to help your code click for others. But, ultimately it comes down to what you and your team like, so feel free to modify or expand anything here. And if you have any clever one liners you love, please show them off in the comments!

happy coding everyone,

mike

How to Use Context with React Hooks

Mike Cronin — Thu, 06 Aug 2020 00:37:11 +0000

Context is probably my favorite React feature, especially when using hooks. It’s not bleeding edge tech anymore, so you should take a second to learn how it works. We’re just going to create a Context component, and then read/set values from it in our main app. It’s going to be a very simple project, but one that shows the basics and how you can build on it in the future. Here is the code on GitHub.

What is Context?

Context lets you have global properties and functions that can be accessed from anywhere in your project. This is pretty much what Redux does, and the best way to distinguish Redux from Context is size: Context is smaller and simpler. The model for a Redux Store is usually a intricate, immutable object, whereas with Context it would be more helpful if you think about it like a floating component that can talk to any other component. You also don't have to use reducers, which can also drastically simplify things.

Setup

Use create-react-app and that's it. We aren't going to have any external dependencies. We're going to create a Context component, give it an internal state, and then share that state with the rest of our app. All our app is actually going to do is save an input string to Context. I encourage you to read them all the same. It's good to know both the hooks and state version, since your company may not be using the latest React.

Step 1: Create a Context component

In src/ create a context/ directory and inside it put index.js and ContextProvider.js. Let's fill out index.js first:

import React from 'react';
const AppContext = React.createContext({});
export default AppContext;

I'm going to explain that second line, but first let's also create ContextProvider.js:

import React, { useState } from 'react';
import AppContext from '.';

const ContextProvider = ({ children }) => {
  const [example, setExample] = useState('Hello there')
  const context = {
    setExample,
    example,
  };
  return (
    <AppContext.Provider value={ context }> 
      {children}
    </AppContext.Provider>
  );
}

export default ContextProvider;

Step 1a: What did we do

Alright, let's talk about createContext and AppContext.Provider. We actually create our Context in index.js, this is the "raw" Context if you will. See, context itself is really just a value, but React incorporates it into its system and gives it Consumer and Provider components. Now, hooks let us bypass the need for a Consumer component, but we still need to have a parent Provider component.

What our Provider component does is take a value (we're calling it context, but it can be named anything) and then make it accessible to any of the children components. This value is our global store. Also, if you aren't familiar with children props, we'll talk about it in the next step.

Internal state

Notice what we pass into our context value: it's a useState hook and its accompanying value. That's the best part about this setup, we're simply tracking a regular component's state. When an external component needs to update the store, there's no magic, it's merely updating the internal state of the Context component. That change is then updated wherever it gets read, like a different version of props. There's nothing new here except where the data is being stored. You can of course add as much as you like to this object, but for now we're keeping it pretty bare bones.

Step 2: Plug your Context into your app

In order for Context to do anything, we need to make it available. Any child component of our ContextProvider component will have access to the store. That means, we need to put it somewhere very high up in the component chain, so I usually put it at the top in the src/index.js file:

import React from 'react';
import ReactDOM from 'react-dom';
import ContextProvider from './context/ContextProvider';
import App from './App';

ReactDOM.render(
  <React.StrictMode>
    <ContextProvider>
      <App />
    </ContextProvider>
  </React.StrictMode>,
  document.getElementById('root')
);

This is also where the children prop in our ContextProvider comes into play. Recall our return statement in our provider component:

return (
  <AppContext.Provider value={ context }>
    {children}
  </AppContext.Provider>
);

By nesting out <App> inside <ContextPrivider>, our main app and all its child components are now the children of the <AppContext.Provider> component. That's what actually lets our app get access to our Context and prevents unnecessary renders. Here's a quick article on props.children if you aren't familiar with it.

Step 3: Use your Context in a component

Alright, here we go! All we're going to make is a little form that lets us set the string value of example in our Context. And we'll display it with the useEffect hook and a console log. We're going to keep things simple and do it all in our main src/app.js file:

import React, { useContext, useState, useEffect } from 'react';
import './App.css';
import AppContext from './context';
const App = () => {
  const { example, setExample } = useContext(AppContext);
  const [formText, setFormText] = useState('');
  useEffect(() => {
    console.log('context here: ', example);
  }, [example]);

  const handleChange = (e) => {
    setFormText(e.target.value);
  };
  const handleSubmit = (e) => {
    e.preventDefault();
    setExample(formText);
  };

  return (
    <div className="App">
    <form onSubmit={handleSubmit}>
      <label htmlFor="example">Example: </label>
      <input
        type='text'
        value={formText}
        onChange={handleChange}
      />
      <button>DO IT</button>
    </form>
    </div>
  );
};
export default App;

There's the whole thing, and here are the parts that use Context:

import AppContext from './context'; 
// ...
const App = () => {
  const { example, setExample } = useContext(AppContext);
  useEffect(() => {
    console.log('context here: ', example);
  }, [example]);
// ...
  const handleSubmit = (e) => {
    e.preventDefault();
    setExample(formText);
  };

  return (
// ...
      <input
        type='text'
        value={formText}
        onChange={handleChange}
      />

We just feed our Context into the useContext hook and then pull out the properties we want to use. The way you use those properties is pretty much the same as you would a useState function or value. Remember the Context object is the one defined in index not the ContextProvider component, that's only ever used in a single place. This is surprisingly simple, but that's all thanks to hooks. They all work together seamlessly that Context really fits right in.

That's pretty much it

There used to be a bit more pomp and circumstance when using Context with class based components, but hooks make it like another useState (if you need class based components, check out Wes Bos's tutorial, I just adapted the pattern for hooks). And of course things can get more complex, like multiple Contexts or a useReducer instead of useState, but at it's core, it's a simple concept.

happy coding everyone,
mike

JavaScript Interview Prep: Primitive vs. Reference Types

Mike Cronin — Fri, 26 Jul 2019 19:39:20 +0000

original article
In a JavaScript interview, they might ask if you understand the difference between primitive and reference data types. Luckily for you, this topic is one of the few in computer science where the names explain it all. There are two ways data types can store info: as a slot in memory, or as a reference to a slot in memory somewhere else. Can you guess which is which?

First up: Primitive types

Primitive data types are: numbers, strings, booleans, undefined, and null (also symbols so check those out). Basically, if it's storing a simple piece of data, it's stored simply. When you set a variable with this type, the variable is that exact value and that's all. If you change that value, the variable simply becomes a new value.

Next: Reference Types

That means the two reference types are objects and arrays (technically one, since arrays are objects). When you create an object, that value is not directly assigned to the variable. Instead, a reference to that value is what gets set. All that variable knows about is the location of the object, not the object itself.

Explaining it with a chore metaphor

Let's say you need to remind yourself to clean the dishes. If you were to store it primitively, you would take a piece of paper and write down "do the dishes." But what if your roommate already did them? Now your chore is take out the trash. Since it's primitively stored, you just take that piece of paper, erase "do the dishes" and write down "take out the trash."

To save your chores by reference, your roommate would keep a list of all the chores. When you need to know what's left or cross one off, you ask them, and they access the list. You don't have the list yourself, you just know where to find it. But enough with metaphors, let's look at some code.

Code that copies a value is where it counts

This all really comes into play when copying or transfering values. Look at this code that copies primitive values:

let color1 = 'green';
let color2 = color1;
color1 = 'purple';
console.log(color1);
// 'purple'
console.log(color2);
// 'green'

color1 is assigned the string value 'green', which means the variable color1 is essentially the same as just a string 'green'. When we use color1 to assign a value to color2, it would've been the same as if we literally assigned it a string value. So when we reassign color1's value, it has absolutely no impact on color2. Both values were always just saving strings, they had no lasting bonds between them. This is not the case with reference types. Look:

let car1 = {
  wheels: 4,
  seats: 2,
};
let car2 = car1;
car1.brand = 'ford';
console.log(car1.brand);
// 'ford'
console.log(car2.brand);
// 'ford'

Huh. We never assigned car2 a brand property, yet it has one. Despite the situations looking the same as our primitive example, the behavior is the opposite. That's because car1 was never assigned the value of the object, only the reference to it. So if you change car1, that will alter the same spot in memory that car2 is looking at:

Solving the reference problem

By adding that brand property, we permanently altered the original object. That is called a mutation, and it's not great when we accidentally do it to more than our intended target. To get around this, we just have to create a new reference to a new object. That way, each variable will point to its own object and not have any overlap. The most common approach is to use Object.assign or the spread operator. For brevity, let's use a spread:

let car1 = {
  wheels: 4,
  seats: 2,
};
let car2 = {...car1};
car1.brand = 'ford';
console.log(car1.brand);
// 'ford'
console.log(car2.brand);
// undefined

One last thing

Objects are mutable, meaning they can change (unless you freeze it. However, primitive types are immutable. See, you can't actually mutate the number 1 into 2, you just replace the value. Meaning we didn't change our 'green' string, we just straight up replaced it with a new string, 'purple'. It's a sneaky little technicality, but now you know! So good luck on those interviews and as always,

Happy coding everyone,

Mike

Like this? I have more articles