DEV Community: dianakw8591

Recursion vs. Iteration in a binary tree

dianakw8591 — Fri, 21 Aug 2020 17:22:16 +0000

When approaching an algorithm, often you have to choose between a recursive approach or an iterative approach. Although some problems or languages naturally favor one approach over another, really they can be used interchangeably. It's all a matter of understanding how to frame the problem.

Both recursion and iteration run a chunk of code until a stopping condition is reached. With recursion, you repeatedly call the same function until that stopping condition, and then return values up the call stack. With iteration, rather than building a call stack you might be storing data in a particular data structure, often a stack or queue, and then running a loop that utilizes that data until the stopping condition is met.

To make these ideas more concrete, here are two solutions to check if a binary tree is symmetric - one recursive and one iterative. This problem is from Leetcode if you want to submit your own solution there! Binary trees are very conducive to recursive solutions, since each piece of a binary tree is just another binary tree. But iterative approaches can be used as well, in this case by utilizing a queue.

Here's the basic problem: a binary search tree is symmetric if it is a mirror image of itself down the center. So this tree is symmetric:

but this tree is not:

The Tree class is already defined for us, and the left, right, and val properties are available to use:

 //Definition for a binary tree node.
 function TreeNode(val, left, right) {
    this.val = (val===undefined ? 0 : val)
    this.left = (left===undefined ? null : left)
    this.right = (right===undefined ? null : right)
 }

Given the root node of the tree, the problem is to write an algorithm to check if that tree is symmetric. Whichever approach is used, the solution needs to check that the left branch of the left branch equals the right branch of the right branch (left.left === right.right) and the right branch of the left branch equals the left branch of the right branch (left.right === right.left). If this condition holds for every subtree, where left and right are the mirror nodes of each other, than the tree is symmetric.

First let's look at the recursive solution. In this solution, a sub-function takes left and right as arguments and compares those values, and then calls itself on the left and right children of those nodes. Here's the full implementation:

const isSymmetric = root => {
  function compare(left, right) {
    if (left === null && right === null) {
      return true
    } else if (left === null || right === null || left.val !== right.val) {
      return false
    } else {
      return compare(left.left, right.right) && compare(left.right, right.left)
    }
  }
  if (root === null) {
    return true
  }
  return compare(root.left, root.right)
};

Before calling compare at all, we check if the root is even a tree. If it's not, there's no work to do. But assuming if is, we start off our recursive calls with root.left and root.right. First we check if both left and right are null, since we can't call .left or .right if those are not actually TreeNodes! This is one of our stopping conditions, and matching null values in the left and right position meet the criteria for a symmetric tree, so true is returned up the call stack. In the next line, the conditions that violate a symmetric tree are checked. Again, since .left and .right cannot be called on a null value, those cases are checked first. If the values do not match, the tree is not symmetric and false is returned up the call stack. Those are the two stopping conditions. Finally, if neither of those conditions are met, the compare function is recursively called down each branch of the tree. The && ensures that both sides must return true for the outer function call to return true - if any of the inner calls resolve to false, that will be passed up the call stack and the function with ultimately return false.

It's important to remember that in a recursive solution the inner return values must be passed up the call stack! There are no implicit returns in JavaScript, so the recursive calls of compare must be explicitly returned as well. The use of return is one of the key differences between the recursive and iterative solution - let's look at the iterative solution now:

const isSymmetric = root => {
  if (root === null) {
    return true
  }
  let queue = []
  queue.push(root.left, root.right)

  while (queue.length > 0) {
    let left = queue.shift()
    let right = queue.shift()
    if (left === null && right === null) {
      continue
    } else if (left === null || right === null || left.val !== right.val) {
      return false
    } else {
      queue.push(left.left, right.right, left.right, right.left)
    }
  }
  return true
}

Again, the first step is to confirm we actually have a TreeNode to start. If we do, we initiate a queue with root.left and root.right. From there, the code logic is nearly identical to the recursive solution. The big difference is that rather than building a call stack, we are adding nodes to our queue and running the while loop until the queue is empty. Another important difference is the use of return. In the first condition left === null && right === null, rather than stop the loop and return true, what we want is to continue checking other nodes. Returning true there would break out of the loop and return true from the isSymmetric function immediately, since we aren't buried in a call stack. Knowing where to use return and what function it is ending is key to building iterative vs recursive solutions. On the other hand, in the next condition, if a false condition is found, we're done! We do want to end the while loop and immediately return false. Only if no false condition is ever found do we hit the last line and return true.

I hope this provides a concrete example of moving between recursion and iteration. For me, understanding what return is doing and the different stopping conditions is key to moving between these two approaches.

Thanks for reading!

Object Destructuring in JavaScript

dianakw8591 — Fri, 14 Aug 2020 18:06:50 +0000

I recently found myself struggling with adding CSS classes to a React component. Once I understood the classes object and how it was created, most of my confusion stemmed from basic object destructuring. So I decided to write this post to solidify my understanding of destructuring assignments in JavaScript! Hopefully it will provide some clarity for others working through this concept as well.

A Quick Review of Objects

An object literal in JavaScript is constructed with key, value pairs separated by a colon. Each key, value pair is separated from the next pair by a comma. Values can be any datatype - arrays, objects, strings, functions, etc - while keys must always be strings, or something that JS can convert to a string, like a number.

let myObj = {a: 1, b: 2}

In myObj, a and b are both strings and JS gives me the shortcut of skipping writing the quotes around those.

To access values of myObj, I can use either dot notation or bracket notation:

myObj.a
//1
myObj["a"]
//1

In order to use dot notation to access an object property, the key must be a valid JavaScript identifier. From the MDN web docs, an identifier is a "sequence of characters in the code that identifies a variable, function, or property". Importantly, an identifier cannot begin with a digit. So, if I created an object like so

let numObj = {1: 'a', 2: 'b'}

I can access values with bracket notation

numObj[1]
//"a"

numObj['1']
//"a"

but dot notation results in an error:

numObj.1
// Uncaught SyntaxError: Unexpected number

Note that with bracket notation, JavaScript coerces 1 to the string "1". However, myObj[a] would result in an error - a is expected to be a variable in that case.

Basic Destructuring

A destructuring assignment allows the mass assignment of variables to object (or array) values. Using the previous myObj for example, I could assign variables to access values like so:

let a = myObj.a
let b = myObj.b
a
//1
b
//2

Or with a destructuring assignment, I can assign both those variables in one line:

let { a, b } = myObj
a
//1
b
//2

During destructuring, I can also assign new variable names:

let {a: first, b: second} = myObj
first
//1
second
//2

In this case, a and b are not simultaneously assigned as variables.

Nested Destructuring

Destructuring assignments can also handle nested objects. Let's start with myNestedObj:

let myNestedObj = {a: 1, b: {c: 3, d: {e: 4}}}

To assign the values of a and d I can destructure like so:

let {a, b: { d }} = myNestedObj
a
//1
d
//{e: 4}
b
//undefined

In this case, b is a 'step' to access d, and is not assigned in the destructuring. I can add the assignment of b like this:

let {a, b, b: { d }} = myNestedObj
b
//{c: 3, d: {…}}

Of course, I could destructure further to access e and assign new variable names if I felt like it too:

let {a: outer, b: { c, d: { e: inner }}} = myNestedObj
outer
//1
a
//undefined
b
//undefined
c
//3
d
//undefined
inner
//4
e
//undefined

The Power of Destructuring

Destructuring is an excellent way to access the properties of an object that might be passed into a function or as the props of a React component. Rather than write a line of code to assign a variable to each property, or use dot or bracket notation every time for access, objects can be destructured for code clarity and ease of writing. Destructuring can even happen in a function definition by destructuring the arguments! Overall, it's an incredibly useful concept and important to become comfortable with if you are developing in JavaScript.

Thanks for reading!

A Senior Dev's List of Key Unix Utilities, Explained by a Junior Dev

dianakw8591 — Fri, 07 Aug 2020 19:40:27 +0000

If you are a developer working on a Mac, chances are you've used a Unix utility or two. At least to cd around to different directories or touch a new file. But chances are you haven't used the vast majority of Unix programs you have on your machine - I have 1325 on mine! Luckily, there's no need to sit down and memorize them all. What is important is to recognize the power of the Unix command line, and to know a few commands that will make your life in the terminal much easier. Below is a list of those commands. But first, a couple notes about using Unix commands in general.

General Rules of Unix Utilities

Commands are lowercase
Options modify the command. They are often single letters added in short form with a single dash -. Some have long form options added with a double dash --.
Options can be combined. For example, adding the -a and -l options to ls can be written as ls -a -l or ls -al
Commands can take arguments, often filenames
Options come before filenames
There must be spaces between commands, options, and filenames

Unix Utilities to Know by Heart

ls

Lists all your files in the current directory. There are a few important option flags to know as well.

-a will also show all the hidden files in a directory (those that start with a .).
-l will list the files in long format, showing permissions, size, and modified date
-lh lists in long format with readable file size (eg 1K, 23M)
-s lists the allocated size of each file in blocks

cp source destination

Copies the source to the destination. Source can be one or more files or directories. Destination is the name of the directory to copy to or the name of the new file. When copying directories, the -r (or -R) flag must be used. This copies recursively, and will ensure that the contents of a folder is also copied.

cd

Change directory. cd with no arguments will bring you to your home directory, which is represented by ~. You can also pass a pathname or make smaller "steps" with cd .., which will move to your parent directory. cd will take relative or absolute pathnames, which can be built with ~ (home directory), .. (parent directory), . (current directory) and / within directories. Note that if you are in a directory with a subfolder test, cd test is equivalent to cd ./test and both will move you into the test folder.

mv source destination

Moves (or renames) source to destination. If the destination is an existing directory, source(s) will be moved there.

rm source

Removes files or directories. Similarly to cp, to remove directories the -r or -R flag must be used which will recursively removed the contents of the directory.

mkdir directory

Create a new directory. The -p flag is used to create parent directories if they don't already exist. For example, if I am in a directory with a subdirectory test and want to create a director example within test, I could run mkdir -p test/example. Since test already exists, a new folder example would be created in test. However, if test didn't exist, the command would simply create test and then create example within test. Either way there are no errors.

grep patterns file

Searches for patterns in each file, and prints each line that matches. This is a really useful command for finding other commands you've used if they are in your logs. The -r flag reads files in subdirectories recursively. -n adds to the output the line number in the file where the match occurred.

cat filename

Used to view the contents of a file. With an argument of a filename, cat will simply print the content of that file. Other options can be added to view only parts of the file or to write contents to a new file.

echo

Displays a line of text. Most often used in scripts and other commands where you need to insert text.

head filename

Output the first part of the file. By default, head prints the first 10 lines. Useful when you only need to see the beginning of a file with lots of content.

tail filename

Output the last part of the file. Like head but for the end of the file.

less filename

Opens a file in the terminal and allows forward and backward navigation within the file. In this mode, patterns can be searched for with /pattern and using n and N to move backwards and forwards between matches. There are a bunch more navigation options to use as well. q will exit navigation.

Unix Utilities to Know About

find

Searches for files based on some user specified criteria, and returns a list of the found files. The search criteria could be pattern matching, a file type, or file name to name a few. For example, find . -name 'test*' would search the current directory for filenames that started with 'test', with * being a placeholder for anything that might follow.

curl

A tool to transfer data to or from a server, using any of its supported protocols (FTP or HTTP for example). There are whole bunch of options for using curl but know that it exists so you can search for the specifics when you need it! wget is a similar command with a couple differences, mainly its ability to download recursively.

vim filename

Opens a file with the vim text editor. Using vim is a whole other blog post, but it is a powerful tool that many developers swear by.

sed

Used to perform text transformations on an input stream (a file or input from a pipeline). It can be used to search for strings in a file, update content, and replace content.

awk

Another big topic, awk can run programs written in the AWK language that are used to transform text in a file. awk can pattern match and perform operations on matched lines, useful for file formatting.

pipes

Piping is a process of sending the output of one command as the input to another. The syntax for a pipe is | and information flows from left to right. So, to pipe the output of ls into less for example, you could write ls | less, and enter the less navigation with all the filenames in the directory - the output of ls.

xargs

Converts standard input to arguments. Useful with commands that only accept arguments and do not read standard input such as echo and rm. With piping, input can be piped to xargs which will execute a given command for each input. A common use of this is with the find command. Results of find can be piped to xargs to run an operation on each result, such as rm. For example, to remove any file that begin with test, I could write find . -name 'test*' | xargs rm.

And there's so much more

The internet is your friend when it comes to learning the details of Unix utilities! Don't be afraid to play around in your terminal either and see what you can do. Hopefully this is a good start for some useful commands to know about and the basics of how to use them. Thanks for reading!

RockOn pt 6: 5 Useful Lodash functions

dianakw8591 — Thu, 30 Jul 2020 20:53:54 +0000

This is the sixth and final post in my series about building RockOn. Get the full background starting here.

In last weeks post, I left off with an array of filtered "entry" objects. The final step is presenting stats and graphs of that data, but there's still more manipulation needed. That's where Lodash comes in - a Javascript library that provides a ton of useful methods for working with arrays, objects, and other data types. The collection methods can be used for both arrays and objects which is incredibly useful. Lodash has excellent documentation, but I'll share a handful of methods I found particularly useful and how to implement them.

To review, here is an example of an entry object and the different keys I used to group and sort by:

{
 climb: {
  area_array: ["International", "Europe", "Spain", 
   "Catalonia", "…],
  climb_id: 110372,
  full_type: "Sport",
  key_type: "Sport",
  name: "La Discórdia",
  numeric_rating: 13,
  rating: "5.10"
 }
 beta: "",
 notes: "very cold and raining...",
 outcome: "Onsight",
 partners: "",
 pitches: 1,
 rack: "",
 start_date: "2019-11-23",
 style: "Lead",
}

My initial data was an array of these objects - when I use array in the examples below, that is the array I'm referencing.

Getting Started with Lodash

Install Lodash in your React app with yarn or npm, and then import specific functions into a component like so:

import { startCase } from 'lodash';

or the whole library:

import _ from 'lodash';

When the whole library is imported, functions all begin with _. (startCase becomes _.startCase) but with cherry-picked functions you can simply call startCase.

Useful Lodash Methods

_.groupBy
Takes a collection and method by which to group elements of that collection, returning an object where the keys are the result of applying that method to each element, and values are arrays of the elements that produced each key. In my case, I often wanted to group by different keys in my entry object, start_date for example:

const groupByDate = _.groupBy(array, 'start_date')

groupedByDate is an object where the keys are every unique start date, and the values are arrays of entries that have that start date. With this function I could easily group climbs that happened on the same day! Let's say I wanted to see all the climbs from yesterday - 2020-07-29. I could simply call groupByDate['2020-07-29'] and get an array of all climbs from yesterday!

By linking _.groupBy methods together, I was able to easily collect all entries of a particular type, grade, and style which I used specifically to build my bar chart.

_.maxBy
Takes a collection and a method (iteratee) invoked on each element, and returns the element that generates the maximum value when the iteratee is called. I used this method to select the hardest climb by grade on each day.

 _.maxBy(value, 'climb.numeric_rating')

where value is the array of climbs on a given day - for example, groupByDate['2020-07-29']. To create an array of entries that were the hardest climb done each day I combined this with...

_.map
Similar to Javascript's built in map, but can be applied to an object as well as an array. With an object, the values are the first argument passed to the iterator function - index/key and collection can also be passed. Returns an array.

const maxByDate = _.map(groupByDate, (value) => _.maxBy(value, 'climb.numeric_rating')

_.sortBy
Similar to groupBy, sortBy takes a collection and the method by which to sort the elements in ascending order, returning a sorted array. Using this method I easily sorted my maxByDate array into ascending order:

_.sortBy(maxByDate, 'start_date');

This ordered array is now ready to be plotted on a time vs difficulty plot!

_.invert
This function flips an Object's keys and values. In my case, I used it to transform my maps for converting Yosemite Decimal System climbing grades to numeric grades that were easier to implement in my graphs.

const yds_conversion = {
 ...
    "5.7": 8,
    "5.8": 9,
    "5.9": 10,
    "5.10": 13,
    "5.10-": 11,
    "5.10+": 14,
    "5.10a": 11,
    "5.10b": 12,
    "5.10c": 13,
    "5.10d": 14,
...

But I often had to map both ways, and invert allowed me to easily build the reverse mapping hash. Note that when keys are repeated, later values override earlier values. So when yds_conversion is inverted, the key 14 will have the value "5.10d".

That's just the beginning...

Lodash has a rich library of functions that go way beyond Javascript's built in libraries. Again, their documentation is great, so don't be afraid to dive in and try some out!

That brings us to the end of my series about RockOn. Hopefully there have been some useful bits along the way, and thanks for reading!

RockOn pt 5: Filtering Data

dianakw8591 — Fri, 24 Jul 2020 18:15:47 +0000

This is the fifth post in my series about building RockOn. Get the full background starting here.

We've made it to the point in RockOn where the user has entered some of their ascents and has a couple data points saved. What now? Well, a bunch of graphs and filter options of course!

In broad strokes, a user's entries are fetched from the database and passed through a filtering function that is controlled by the user. That filtered array is then passed to the graphs and logbook so that only ascents that meet the selected criteria are displayed. Here's a better view of all those filter options:

There's a lot of climbing terminology in there but don't let that dissuade you. You can think of these options just like filters for a house search on Zillow: are you looking to rent or buy? What square footage and number of bathrooms do you want? Is in-unit laundry a must have? Yes, rock climbing is just like searching for your next apartment.

Let's break this down and start from the beginning. When a user logs in, all of their entries are fetched from the back end and saved in state to be passed to other components as needed. The entries come as an array of objects - here's an example of an entry object:

{
 climb: {
  area_array: ["International", "Europe", "Spain", 
   "Catalonia", "…],
  climb_id: 110372,
  full_type: "Sport",
  key_type: "Sport",
  name: "La Discórdia",
  numeric_rating: 13,
  rating: "5.10"
 }
 beta: "",
 notes: "very cold and raining...",
 outcome: "Onsight",
 partners: "",
 pitches: 1,
 rack: "",
 start_date: "2019-11-23",
 style: "Lead",
}

This object has all the information needed for the graphs and logbooks, and most of the keys are filterable. We'll walk through the process of filtering by outcome - the many ways that climbers describe whether they fell off the climb at some point, or whether they held on until the top. Again, don't worry about the terminology too much - just know that only one outcome can be applied to a given entry.

In the filter options, everything begins as selected. In the case of outcomes, that means that entries with any of the nine outcome options attached will be displayed.

All of the filter options are just part of a controlled form!

<Form.Group >
  <Form.Label>Select outcomes:</Form.Label>
  <div key={`inline-checkbox`} className="mb-3">
  {Object.keys(outcome).map(key => (
    <span className={mappingRopeOutcomes[key]} key={key}>
      <Form.Check inline
       type="checkbox"
       onChange={handleOutcomeToggle}
       label={key}
       name={key}
       checked={outcome[key]}
      />
    </span>
  ))}
  </div>
</Form.Group>

The span surrounding each check box is simply for styling purposes, but the functionality of the form follows the same pattern as discussed in last week's post. Any change to the form is handled by the handleOutcomeToggle function:

const handleOutcomeToggle = ({ target }) => setOutcome(s => ({ ...s, [target.name]: !s[target.name] }));

This function in turn updates state using setOutcome and simply flips the boolean from what it was before. The Stats component where these functions live is functional, so I am using the useState hook to save and set my outcomes:

  const [outcome, setOutcome] = useState({
    'Onsight': true,
    'Flash': true,
    'Redpoint': true,
    'Pinkpoint': true,
    'Tronsight': true,
    'No Falls': true,
    'TR Attempt': true,
    'Repeat': true,
    'Attempt': true
  })

Rather than having a useState hook for every outcome possibility like this:

const [onsight, setOnisght] = useState(true)
...

I can use one hook that handles the entire object, and update each key of the object appropriately by looking at the target.name that comes from my form. Nifty!

So following this flow, if I don't want to see any of my climbs with an outcome of 'Onsight', I unselect that checkbox, which changes the value of outcome.Onsight to false.

Next I need a way to use state to filter out any climbs from the entry array that have an outcome of Onsight. I'm sure there are lots of ways to solve this filtering problem (and quite a few different helper function to use, both built into Javascript or from outside libraries like Lodash) but I'll share my original solution here. In the first step I built an array of outcomes that only included the ones selected, where the value is true.

  const outcomeArray = Object.keys(outcome).filter(key => outcome[key])

Here Object.keys(outcome) is an array of the outcome keys. The filter removes any keys that have false values in the original outcome object.

Using outcomeArray, I then filtered my entries array such that only entries with outcomes included in the outcomeArray are kept:

entries.filter(e => outcomeArray.includes(e.outcome))

The filtered array is then passed to the graphs and logbook components, so that as a user select filters the displays are updated in real time.

This is the same flow I followed for all of the filter options - dates, grades, style, etc. Some of those data types took a bit more manipulation or a slightly different method to achieve the filter but the concept is the same. Finally, by stringing the filter functions together, I was able to apply all of the filters at once. Here's that final function:

  const filtered = entries
    .filter(e => moment(e.start_date) >= moment(start))
    .filter(e => moment(e.start_date) <= moment(end))
    .filter(e => typeArray.includes(e.climb.key_type))
    .filter(e => e.climb.key_type === "Boulder" || styleArray.includes(e.style))
    .filter(e => outcomeArray.includes(e.outcome))
    .filter(e => e.climb.numeric_rating >= grade.low && e.climb.numeric_rating <= grade.high)

To plot the filtered array even more manipulation is needed - I'll dive into that next week in part 6. Have a great weekend and thanks for reading!

RockOn pt 4: Controlled Forms in React

dianakw8591 — Fri, 17 Jul 2020 18:23:13 +0000

This is the fourth post in my series about building RockOn. Get the full background starting here.

In my previous posts I discussed all the work that went into seeding my database and building a search interface - now we've arrived at the point where a user is finally entering information about a particular ascent. Let's say our user has just climbed the iconic Exum Ridge in Grand Teton National Park. Here's the form they'd see after selecting that climb:

Let's walk through this. The first thing the user selects is the date, which can be selected from a dropdown calendar. I used the react-date-picker component for this which was easy to set up and integrate, once I got the date formatting correct (I highly recommend using moment for handling dates in Javascript).

The next field, pitches, or how many rope lengths long a climb is, is autofilled from the route data. This field is modifiable by the user in the event that they have combined pitches and want to record the actual number that they climbed, or if the data from Mountain Project is incorrect. The 'Style' and 'Outcome' fields have dropdown menus to choose from, and the last four fields are just text fields for the user to type their notes into.

So for my eight fields, how many handleChange functions did I need for handling user input? On first glance, it might seem like each field requires its own function. But in my case, I just needed two. All the fields have the same structure, except for the date picker component which was easiest to handle with its own dedicated function. Before getting into the code, a quick review of controlled forms.

From the official React documentation:

In a controlled component, form data is handled by a React component. The alternative is uncontrolled components, where form data is handled by the DOM itself.

What this means in practice is that when the user enters input in a controlled form, React state is updated. That state then controls the value of the form. In this way a single source of truth is retained, managed by state.

To actually code this, there are three parts to consider: state, the handleChange function, and the form field itself. To begin, I set the state of all the fields. In my class based component, that looks like this:

  state = {
    error: false,
    fields: {
      pitches: this.props.climb.pitches || 0,
      start_date: new Date(),
      style: '',
      outcome: '',
      partners: '',
      beta: '',
      rack: '',
      notes: '',
    }
  };

where the error state is used to display error messages on a failed form submittal.

My form fields all look essentially the same, where name denotes what the field is for and corresponds to the correct key in state, value is controlled by the corresponding state, and all of the onChange functions are the same and pass event as the argument. Here's the form field for partners (using Bootstrap React components):

<Form.Control
    type="text"
    name="partners"
    onChange={event => this.handleChange(event)}
    value={this.state.fields.partners}
/>

onChange is written as a callback here, but onChange={this.handleChange} would do the same thing.

By formatting all of my fields with the same structure, I was able to use one handleChange function for (almost all) of my fields. The event itself contained all the information I needed to update the appropriate state!

  handleChange = e => {
    const newFields = { ...this.state.fields, [e.target.name]: e.target.value };
    this.setState({ fields: newFields });
  };

So in the case of updating the partners field, the spread operator will first populate my newFields object with all of the existing key/value pairs in state.fields. Because of the order, whatever [e.target.name] evaluates to will override any key that comes before it in the object. In the case of partners, [e.target.field] evaluates to just that, partners, with whatever the user has typed (e.target.value) as the new value, and resets whatever was previously the value of partners.

It's important to remember that in Javascript, object keys are always strings. To save some typing, Javascript automatically converts keys to strings, like in my original state object. I haven't bothered to put quotes around the keys, (fields: rather than "fields":) but Javascript is reading the keys as strings anyways. In the case of e.target.value, I want the key to be whatever that evaluates to, not the string "e.target.value". The brackets tell Javascript to do just that.

The only field that didn't follow this format was the date. That component supplied the new date as the argument to its onChange function rather than the event, so I chose to write a separate handleDateChange function and handle that case.

By having all of my form fields follow the same structure, I saved myself a lot of repeat code. Another place where I implemented the same tactic was building my dropdown menus for the 'Style' and 'Outcome' fields. All my options needed to be wrapped in <option> tags, and I also had multiple 'Outcome' lists depending on the type of climb that was being recorded. To save some typing, I simply created arrays of 'Style' and 'Outcome' choices, and then mapped those values into a new array of <option> tags that I used in the form itself:

  createOptions = (array) => {
    return array.map(e => <option value={e} key={e}>{e}</option>)
  }

By setting the value of each option this way, I was able to use the same handleChange function described above.

On form submittal, all of the information I need to send to my back end is already saved in state and formatted correctly. Once I post successfully, I clear most of my form values using state, except for the date to allow easy entry of another climb on the same day!

Now that a user has some data entered, what actually happens with that data? Next week I'll dive into the graphs and logbook entries I use to give users an easy way to view and manipulate their own data.

Thanks for reading!

RockOn pt 3: Handling Hierarchical Areas

dianakw8591 — Sat, 11 Jul 2020 18:56:23 +0000

This is the third post in my series about building RockOn. Previously I discussed the implementation of route name search, and further background is here.

Last week I discussed my process for implementing a search by route name in RockOn and why I felt that it was a key component of the user experience. Another common scenario I wanted to account for was the case when multiple routes are completed at the same crag or area. Imagine going to your local rock outcropping and climbing five routes there. Would you rather have to type in each route name to make your entries, or search for "local rock outcropping" and then quickly select the routes you did from the list that was returned?

The User Experience

The most immediate challenge when thinking about areas is that all of them are different sizes! An area like Yosemite has 2,000+ routes nested under it, too many for a dropdown. I considered a series of nested searches, where a search for a high-up parent area would then provide a dropdown of all its children areas, until eventually reaching the specific crag containing only routes. This would have been complicated to build and likely a poor user experience if many levels of areas had to be navigated. Beyond that, the lowest levels of Mountain Project area designations are often extremely vague, such as "west face" or "southeast group", and don't correspond to common crag names that climbers know. I could have stopped one level up and never returned the lowest level "leaf" areas, but that algorithm isn't one size fits all. Many leaf areas are common crag designations and a level up is too general and expansive.

With all of this in mind, I ultimately chose to implement an area search that leads to an autocomplete-style search of all the nested routes under that area. The first step from a user perspective is to search by area name. This search is accomplished in exactly the same way as the route name search is, by using Ransack and returning a list of areas to choose from. But while selecting a route name opens a form to complete about the ascent, selecting an area results in another fetch to the back end for all the subroutes.

Creating a Self Join

Before I dive into that code, it's useful to understand the structure of the area table in the database. I created it with a parent/child hierarchy structure, and ActiveRecord provides some useful associations for this self join. My case was nearly identical to the manager/subordinate example given in the Ruby on Rails docs where a parent area (manager) can have many children (subordinates) but any child can only have one parent. The relationships defined in my area model simply reference the same model with the class_name key, and parent_id is the foreign key such that each child keeps track of its parent. Here's my code:

class Area < ApplicationRecord
  has_many :children, class_name: "Area", foreign_key: :parent_id
  belongs_to :parent, class_name: "Area", optional: true
  has_many :climbs

By defining my relationships like this, I now had access to parent and children methods for my Area class. Thanks Ruby! Also note that there is nothing in my models to restrict an area from having both subareas and associated routes. Mountain Project enforces this either/or on their end, so I got to seed my database knowing this was the case.

All of the Subroutes

Armed with these methods, I was then able to write a function that would return all the routes nested below an area regardless of the area 'level'. Conceptually, I wanted a method that did something like this: if an area has children areas, check all children areas. If an area has climbs, return the climbs. If this sounds like a perfect place for recursion to you, that was my thought as well, and Ruby makes the code deceptively simple:

  def all_child_routes
    routes = children.map { |area| area.all_child_routes }
    routes << climbs
    routes.flatten
  end

Let's walk through this. all_child_routes is an instance method of the Area class, so children and climbs are both methods called on the specific area. In the first line, routes is defined as an array, simply because map always returns an array. This also takes advantage of the fact that when children is called on an area that has no children an empty array will be returned (rather than nil or undefined). As the call stack resolves, climbs are pushed onto the routes array, which creates an array of arrays. (Similarly to children, climbs called on area that has no climbs returns an empty array so we don't have to worry about nil or undefined ending up in the routes array). The final line returns a flattened array, which is ultimately what we want. This code actually handles the situation where areas have both subareas and routes, although that should never be the case.

Here's another way to write this method that's a little wordier and does depend on areas never having both subareas and climbs:

  def all_child_routes
    if children
     children.map { |area| area.all_child_routes }.flatten
    else
      climbs
    end
  end

They key is to keep the arrays from becoming deeply nested, which flatten takes care of.

With these few lines of code, I was then able to return all the climbs of all the subareas of any given area!

Selecting the Climb

Back on the front end, I implemented a React component that handled autosuggestion with simple text matching. I imported react-autosuggest and customized the Autosuggest component for my particular case. The meat of the autosuggest is in the getSuggestions function:

  const getSuggestions = value => {
    const inputValue = value.trim().toLowerCase();
    const inputLength = inputValue.length;
    return inputLength === 0 ? [] : autoList.filter(climb =>
      climb.name.toLowerCase().slice(0, inputLength) === inputValue
    );
  };

where value is the user input in the text field, and autoList is the list of climbs that was returned from my previous code. The returned array of climb names is displayed in a dropdown, and when a user selects their climb of choice, the ascent details form pops up the same as if the search had begun with the climb name in the first place.

This text matching leaves a lot of room for greater sophistication, such as ignoring special characters and matching substrings that don't start from the beginning of the climb name. In some cases it would also be useful to see the full dropdown of climbs without typing any characters, but as discussed above this list would have to curated to avoid including thousands of entries. Improving this portion of the user experience is high on my list of upgrades to make to RockOn!

All together now:

More Fun with Areas

While we're on the subject of areas, I also ran into a case where I wanted to find the lowest common ancestor of a set of climbs. To be exact, I wanted to list the most specific area possible for a given day of climbing. Remember, given the extreme specificity of leaf areas on Mountain Project, routes that are a five minute stroll apart can actually be classified in different areas, never mind the case of climbing routes that are truly at separate crags. In one of my log views, climbs are grouped by date, and I wanted to list the area that was visited that day as specifically as possible.
These three climbs are found at two distinct crags but are most closely connected by Tuolumne Meadows.

I accomplished the search for most specific common ancestor by looping through the set of entries' area arrays until I found an ancestor that diverged. Helpfully, Mountain Project's API returns an array of parent areas with the climb object, ordered from least specific to most specific, so that data was already available to me. Here's my code:

  const commonArea = () => {
    let i = 0;
    while (i <= minLength) {
      let first = null;
      // found is looking for the first area that is not the same as areas get more specific
      let found = areaArrays.find(areas => {
        let area = areas[i];
        if (!first) {
          first = area;
          return false;
        } else {
          return first !== area;
        }
      })
      if (found) {
        break
      } else {
        i++
      }
    }
    return areaArrays[0].slice(0, i).join(' > ')
  }

Here minLength is the length of the shortest area array in question, and areaArrays is an array of all the area arrays that are being searched for common ancestry. The while loop breaks when an area doesn't match the first area on that 'level' or when the shortest area array has been fully traversed (i > minLength).

The area structure provided some opportunities for writing interesting and challenging code and presents plenty of further opportunities for refining the user search experience.

Next week I'll dive into what happens when a climb has finally been chosen: the ascent logging form!

RockOn pt 2: Searching with Ransack

dianakw8591 — Fri, 03 Jul 2020 17:48:33 +0000

This is the second post in my series about building RockOn. For more background and to read about how I seeded my database head here.

A key part of RockOn's user experience (and why I went through the effort of seeding my own database) is the ability for a user to easily find a rock climb. Ideally, this means that a user can type in part of a route name, forgetting the articles and misspelling the main content, and still be returned the route they were looking for. I also wanted a user to be able to search by route name or area name. The area search presented a lot more challenges from a UX perspective, so I began by just building the search by route name.

Building the full text search myself was outside the scope of this project, but luckily other people have solved this problem already and made their solutions freely available on the internet! After a bit of research, I chose to use the gem Ransack for its popularity and ease of implementation.

Using Ransack

As usual it's easy to get started with the Ransack gem. In your gemfile, add gem 'ransack' and run bundle install. The search I wanted to implement was very straightforward: search the 'name' column in the 'climbs' table with the query parameter and return the results. This is very similar to the first example in the Ransack documentation:

def index
  @q = Person.ransack(params[:q])
  @people = @q.result(distinct: true)
end

where :q is the search term. To search just the 'name' column, I used one of Ransack's search matcher predicates (also outlined in the docs):

I called another method on the returned search object to limit the total returned climbs, and then returned a JSON object as usual. Here's the whole five lines of code:

  def index
    @q = Climb.ransack({name_i_cont: params[:q]})
    climbs = @q.result(distinct: true).limit(8)
    render json: {climbs: climbs}
  end

Overall very easy to implement, and Ransack provides great documentation for more complex searching as well.

Ransack Behind the Scenes

What is Ransack actually doing when I call it on my model? More specifically, what are the SQL statements that are executed?

By enabling the ActiveRecord logger in the Rails console, I can see the SQL statements that are run by Ransack. In this case, it's pretty simple. Running these Ransack methods

@q = Climb.ransack({name_i_cont: "nose"})
@q.result

generates this SQL:

SELECT "climbs".* FROM "climbs" WHERE "climbs"."name" ILIKE '%nose%' LIMIT $1

The key to Ransack's search here is using SQL's ILIKE operator which matches on similar values rather than exact ones. ILIKE versus LIKE is just case insensitive. The % surrounding my search query "nose" is a wildcard and represents any character or set of characters.

The Query Parameter

Now that my back end search functionality was taken care of, I needed to write the front end API call that passed along my search query. In this case I was making a GET request, so my query parameter would be in the url. For this method it was useful to use Javascript's URL object that gave me access to methods that help build and validate urls. Here's the code I used to build my url, where route is the name of route entered by the user:

const url = new URL(`${API_ROOT}/climbs`);
url.searchParams.append("q", route);

This is equivalent to writing

const url = `${API_ROOT}/climbs?q=${route}`;

but using the URL methods helps avoid syntax errors and validates the url. With that, I just made a simple fetch request.

Putting it All Together

With one gem and a couple of functions, I was able to give my users a pretty easy search experience.

There are certainly improvements that can be made, such as handling misspelled words and providing a 'See More' option if the climb of choice isn't one of the first eight results. But so far I've found that armed with the general idea of the route name, my search will usually return exactly what I want.

Next week I'll go through the challenges of searching by area and some of the methods I built for handling my hierarchical area structure.

Thanks for reading!

RockOn pt. 1: Using Nokogiri to Seed my Database

dianakw8591 — Fri, 26 Jun 2020 21:11:03 +0000

As my final project for Flatiron School's software development program I chose a topic near and dear to my heart: rock climbing. My previous job had been as a climbing ranger in Yosemite, and I've invested years in the sport and traveled all over the world for it. I was actually in Spain climbing (where this cover photo was taken) while I was applying to software engineering programs. On rest days I'd practice programming fundamentals and work through pre-coursework for bootcamps. I would also take careful notes about all the climbing I was doing, something I've done for years. It's not uncommon for climbers to keep a logbook or journal, whether in paper or spreadsheet format, and it's a nice way to mark accomplishments, keep notes and track progress. Here's my entry from the cover photo day, the last climb of the trip on Pa Ella y Pa los Guiris:
Not super legible is it?
But here's the problem with my current logbook: I can hardly read my handwriting! Never mind if I'm curious about how many days I've climbed in a year, or how many routes I've climbed of a certain type or grade. That's a lot of time spent going through and adding up all of my entries by hand!

Thus the concept for my final project: a digital climbing logbook that allows climbers to easily enter new climbs and visualize their climbing history. I'll talk about the data visualization in a later post, but in this post I'll discuss the first major hurdle I encountered: how to give a user easy access to information about a specific rock climb.

For any given ascent, there are some 'subjective' features and some 'objective' features. Subjective features include information like did you fall or not, and any notes about your experience on the climb. Objective features are things like grade (how hard the route is) and length. That's the type of information that can be found in a guidebook, and while there can be intense debate in the community about a some of these objective features, particularly grade, it's information that is inherent to a given climb. Therefore, I did not want my users to have to manually enter names, grades, and lengths for every ascent. Rather, they should be able to select that information from a database and only enter information specific to their experience on the climb.

Thankfully, this information is freely available on the internet in the form of Mountain Project. For North American rock climbing particularly, Mountain Project's database is quite thorough, and they offer an API to access route and area information. However, their API only has endpoints for route IDs or latitude, longitude coordinates, and I wanted users to be able to search for routes by name. I couldn't use the route ID endpoint from my front end because a user has no idea what a given climb's ID is! I considered using a map where the user could select a point near their climbing location, and using that coordinate I could return a list of climbs from Mountain Project within a certain radius. That might have worked well in some scenarios, but in areas with thousands of climbs, a coordinate is not specific enough for an easy search experience through the returned list. Plus, locating a climbing area on a map is just not as easy as typing in a route name! Ultimately, I decided that in order to provide the best user experience, I needed to seed my own database and allow a user to search that by route name or area name.

My end goal was to make the entirety of Mountain Project searchable in my own database, which meant first getting every route ID. Enter Nokogiri, an HTML (as well as XML, SAX, and Reader) parser. If I could figure out where the route IDs existed in the HTML structure of Mountain Project's pages, I could open each page with Open-URI (another module that ships with Ruby) and use Nokogiri's CSS and HTML selectors to access the IDs.

Nokogiri is a dependency in every Rails project, so it's extremely easy to get started. I simply required Open-URI at the top of my file, and then used Open-URI and Nokogiri together like this:

require 'open-uri'
...
doc = Nokogiri::HTML(URI.open(url))

where url is the url of the page I wanted to parse. Now that I had access to the HTML, I just needed to use the right selectors to get the information I was interested in - mainly area name and ID and route ID.

Mountain Project's information is structured hierarchically with areas containing sub-areas or routes but never both. Therefore, my general strategy was to start at a high-level area page. If that page contained sub-areas, I would recursively go through each of those. If an area contained routes, I would grab the route IDs.

Let's walk through my code for an area page: Yosemite National Park. The name of the area is a big header at the top, and it's easy to find the <h1> I'm looking for in the HTML with Chrome's developer tools:

To select the inner text of that particular header I consulted Nokogiri's documentation for available methods and used a fair amount of trial and error. My final code looks like this:

name = doc.css('h1')[0].children[0].text.strip

where .css means I'm using CSS selectors, in this case selecting <h1> tags. That query returns a node set, similar to an array, from which I want 0th item. From there I want the first child text and to remove any leading or trailing whitespace characters. With the name string successfully selected, I create a new Area entry in my own database.

At this point I need to check if the area contains sub-areas or routes. Sub-areas are identified by a class of left-nav-row as seen here:

To select that with CSS selectors, I selected all the <a> tags within divs of that class:

areas = doc.css('div.lef-nav-row a')

If that node set was not empty, I access the href attribute and use Regex matching to pull out the area ID:

area_ids = areas.map { |u| u.attr('href').match(/[0-9]+/).to_s }

If the areas node set was empty, I look for route information instead. On an area page that contains routes, route IDs are found in a table with an ID of left-nav-route-table:

and the code to access the routes:

routes = doc.css('table#left-nav-route-table a')

Accessing the route ID is similar to accessing area ID:

route_ids = routes.map { |a| a.attr('href').match(/[0-9]+/).to_s }

and with route IDs in hand I create Climb entries and use the IDs later to hit Mountain Project's API and flesh out the route information.

Here's the full code for my scraping method:

def getIds(areaId, parentId)
  base_url = 'https://www.mountainproject.com/area/'
  url = base_url + areaId
  doc = Nokogiri::HTML(URI.open(url))
  #get area name and save a new area
  name = doc.css('h1')[0].children[0].text.strip
  puts('in area:', name)
  current_area = Area.create(name: name, parent_id: 
    parentId, mtnproj_id: areaId)
  #check for subareas
  areas = doc.css('div.lef-nav-row a')
  if areas.empty?
    #get routes from this area
    routes = doc.css('table#left-nav-route-table a')
    route_ids = routes.map { |a| 
       a.attr('href').match(/[0-9]+/).to_s }
    route_ids.each { |route_id| Climb.create(mtnproj_id: 
       route_id, area_id: current_area.id) }
  else
    area_ids = areas.map { |u| u.attr('href').match(/[0- 
       9]+/).to_s }
    area_ids.each { |id| getIds(id, current_area.id)}
  end
end

The puts statement is a visual indicator that my code is progressing through areas as expected, and lets me know which area to start from if my code gets hung up, which did happen a couple times. I tested my method on small areas first with few subareas and routes, and after verifying that it worked as expected, ran it on larger parent areas, ultimately scraping all 222,195 route IDs from Mountain Project. After that it was simple to access Mountain Project's API for the rest of the route information I wanted.

Going forward I would like to create a background process that updates my route information on a weekly basis so that climbs added to Mountain Project are updated in my database as well. However, the scraping code took days to run through all of Mountain Project's pages, so I'd like to write a more efficient solution for updates.

Next week I'll walk through how I made my database searchable from the front end and the challenges I encountered in making a user-friendly entry form. For now you can check out RockOn or watch my demo video.

Thanks for reading!

React Context

dianakw8591 — Fri, 10 Apr 2020 01:03:53 +0000

I'm almost two weeks into learning React, and while working on a lab that models Westworld's command center I realized that I was passing props down five levels deep! This process of prop drilling (vocab word of the day) struck me as a lot of extra typing, and therefore not terribly React-like. For example, information about my hosts was stored in state the top level in App, and passed down into my next components:

//In App
render(){
    return (
      <Segment id='app'>
        ...
        <Headquarters hosts={this.state.hosts} ... />
      </Segment>
    )
  }

where it was passed deeper...

// in Headquarters
<ColdStorage hosts={this.hostsInStorage()} ... />

and deeper...

// in ColdStorage
<HostList hosts={props.hosts} ... />

still deeper...

// in HostList
{props.hosts.map(host => {
        return <Host key={host.id} host={host} ... />
        })}

and finally down in the Host component the information is actually used.

That's a lot of repetitive typing for every prop I might need to send from App down to a Host. While there are multiple solutions to this problem, React Context offers one. Straight from the React docs:

Context provides a way to pass data through the component tree without having to pass props down manually at every level.

Stated this way, Context offers a solution to the exact problem I encountered. So, onto adding Context.

In my Westworld lab, I want to create a Context that contains my Host data and makes it available to all of the children. The easiest way for me to do this with my current code is to create a new Context in App;

const hostContext = React.createContext({host: []});

I'm initially creating a Context with a default value of {host: []} because my host data is fetched asynchronously in componentDidMount in App. To make this Context available to all of App's children, I'll use React's Provider component, a property of the Context. I'll wrap all of App's children in <hostContext.Provider value={importantDataHere}> tags.
The value prop is what contains the information that I want passed down to all of my children components. In this case, I can assign value={hosts: this.state.hosts} where this.state.hosts now contains all of my fetched data. To recap, my App component will look like this:

...
const hostContext = React.createContext({host: []});
...

class App extends Component {

  state = {
    hosts: [],
    ...
  }

  componentDidMount() {
    fetch(HOSTS_URL)
    .then(resp => resp.json())
    .then(data => this.setState({
      hosts: data
    }))

  render(){
    return (
     <hostContext.Provider value={{hosts: this.state.host}}>
      <Segment id='app'>
        ...
        <Headquarters />
      </Segment>
     </hostContext.Provider>
    )
  }
}

This is great! But how do the children of App (and my new hostContext) access the value passed by the Provider? For class based components, the contextType property can be assigned to the given Context, and the value accessed using this.context:

class Headquarters extends Component {
...
const hosts = this.context.hosts;
...
}
Headquarters.contextType = hostContext;

Note that only one Context can be assigned to a class based component in this way.

For functional components, the hook useContext gives access in the same way that this.context does for class components, and no need to include any assignment of contextType:

const hosts = useContext(hostContext).hosts

There are plenty of pros and cons to Context and it's not the right choice for every situation, but it seems like a great tool to have in the toolbox!

Asynchronous Javascript: Callbacks and Promises

dianakw8591 — Tue, 24 Mar 2020 22:38:30 +0000

As the Javascript module of Flatiron's Software Engineering immersive wraps up, one thing has become quite clear: I really need to understand callbacks and asynchronous functions to understand how to effectively use Javascript. Below, I've laid out my understanding of callbacks and how promises make asynchronous Javascript easier to user and understand.

First, we have to understand that Javascript is a synchronous, blocked language where functions only execute after the previous function has finished. But there are also functions available that are asynchronous, fetch and event handlers for example. Other code will continue to execute while the asynchronous function is waiting to complete, perhaps waiting for response from a server.

Callbacks can be used in both synchronous and asynchronous Javascript, but often are used in asynchronous ways. Callbacks are functions passed to another function that are called after that function completes. An example of a synchronous callback could be this simple:

function funcA(num) {
    return num * 2
}

function funcB(cb) {
    return cb(5)
}

funcB(funcA)
//10

It's just passing a function to another function, in this case, funcA to funcB. But that's not very interesting.

Callbacks used in asynchronous code result in something called "callback hell" which I recommend googling. Basically, something like this:

asyncAction1((res1, err) => {
  if (err) { handle() }
  asyncAction2((res2, err) => {
      if (err) { handle() }
    asyncAction3((res3, err) => {
      if (err) { handle() }
      // do something
    });
  });
});

It's messy to look at unpleasant to deal with. Promises help to fix this mess by returning a Promise object that is a proxy for an actual value. It's the promise to return that value, and is either pending, fulfilled, or rejected. .then can be called on promise and whatever work is done in the .then block will only be run after the promise has been resolved. Similarly, .catch will handle errors if the promise is rejected.

So to rewrite the code above with promises:

asyncAction1
.then((res1) => asyncAction2(res1))
.then((res2) => asyncAction3(res2))
.then((res3) => functionThatDoesSomething(res3))
.catch(err)

I hear async/await is even cleaner and nicer to use for a variety of reasons, but that part is for another post! Thanks for reading!

form_with without JS

dianakw8591 — Tue, 10 Mar 2020 20:15:33 +0000

Last week I was working on a web app to link condition reports and photos with snowpack data from the date and location of the report. The app was built entirely with Ruby on Rails, and I ran into a bug when I tried to use a search form built with form_with. The generic search form solution from RailsGuides seemed like it should work great. Working from the generic form, I got to this point:

<%= form_with(url: "/search", method: "get") do %>
    <%= label_tag("Choose locations:") %>
    <%= collection_select(:location, :id, Location.all, :id, :name) %><br>
    <%= label_tag(:min, "Minimum Snow Depth (in):") %>
    <%= number_field_tag(:min) %><br>
    <%= label_tag(:max, "Maximum Snow Depth (in):") %>
    <%= number_field_tag(:max) %><br>
    <%= submit_tag("Search Posts") %>
<% end %>

Having used form_for and form_tag in the past, the syntax looked familiar, but when I submitted a search, nothing happened! I knew I was hitting the right route and my log even said that it was rendering the results page. But no new page was rendered.

Enter the :local option. By default, form_with submits are XMLHttpRequest (XHR) objects - put another way, they are AJAX requests. The main benefit of AJAX (Asynchronous JavaScript And XML) is that it communicates with the server and renders new data without a full page refresh. The first line of html generated from my original form_with with default options looks like this:

<form accept-charset="UTF-8" action="/search" data-remote="true" method="get">

The data-remote="true" bit tells Rails to submit the data as an AJAX request. But without Javascript in the mix, this default option was causing problems.

In order to disable the default remote submits, add local: true as an option to the form, like so:

<%= form_with(url: "/search", method: "get", local: true) do %>

After that, my results page rendered as expected.