DEV Community: Anthony Chung

/^15 Things to Know About Regex$/

Anthony Chung — Fri, 13 Aug 2021 18:26:17 +0000

Be not afraid! You are about to learn one of the most feared subjects in computer science...

*dramatic pause*

Regex!

Regex (or regexp) is short for regular expressions and it is a syntax used to describe patterns that are to be matched in texts. For example, one can use regex to identify how many times and where a certain text pattern occurs in a document.
While at first glance regex may seem daunting, once you know the following 15 things, you will be able to show off to other folks that you know (the basics of) regex!

1. How to use Regex in JavaScript

Like many other programming languages, JavaScript has commands that allow the use of regex for pattern-matching such as match(), test(), and replace(). Before passing the regex as a parameter or calling a method on it, it must first be defined within two forward slashes (//) or through new RegExp():

const regex1 = /bananas/ // define regex 
const regex2 = new RegExp('12') // another way to define regex

const str = "John has 12 bananas" // the string to match the pattern to

// Calling match() returns an array of match(es)
str.match(regex1) // ["bananas"]
str.match(regex2) // ["12"]

// Calling replace() replaces the matched string with the string
// that is provided as the second parameter
str.replace(/12/, '24') // "John has 24 bananas"

// Calling test() returns a boolean based on whether the regex 
// matches the string at least once
/John/.test(str) // true

2. Literals

Literals are the simplest form of regex – it is basically the exact text that we want to match:

const str = "foo bar 123!"

str.match(/123!/) // ["123!"]

3. Alternation

Alternations are used to match the characters before OR after |, the pipe symbol:

const str = "foo bar 123!"

str.match(/hello|bar/) // ["bar"]

4. Character Sets

Character sets are used to provide a series of characters within a pair of brackets ([]) and allow a match as long as one of those characters are found. Inversely, negative character sets allow a match as long as one of those characters are NOT found, and they are denoted by the caret (^) symbol before the series of characters:

const str = "bat cat hat"

str.match(/[fgh]at/) // ["hat"]
str.match(/[^bdh]at/) // ["cat"]

5. Wildcards

Wildcards are denoted by the period (.) and can represent any character (letter, number, symbol, or whitespace). If we want to match an actual period itself, we can include the escape character (\) before the period.

const str = "John has 12 bananas."

str.match(/John has .. bananas\./) // ["John has 12 bananas."]

6. Ranges

Ranges are a shorthand for providing a sequential range of characters and can be used within character sets. They can be used for both letters and numbers, and they are denoted by the dash character (-). Multiple ranges, along with individual characters, can also be provided back-to-back within a character set:

const str = "John has 5 bananas"

str.match(/[0-9]/) // ["5"]
str.match(/[A-Za-z0-9_]/) // ["J"]

7. Shorthand Character Classes

Shorthand character classes represent common character ranges such as word characters and digit characters. Inversely, negated shorthand character classes match any character that is NOT represented in the character ranges.

const str = "foo bar 123!"

// \w represents any word character AKA [A-Za-z0-9_]
// \W is the negated version
str.match(/\w\w\w/) // ["foo"]
str.match(/\W\W\W/) // ["123"]


// \d represents any digit character AKA [0-9]
// \D is the negated version
str.match(/\d\d\d/) // ["123"]
str.match(/\D\D\D/) // ["foo"]

// \s represents any whitespace character such as spaces or tabs
// \S is the negated version
str.match(/...\s.../) // ["foo bar"]
str.match(/.\S./) // ["foo"]

8. Groupings

Groupings, denoted by a pair of parentheses (()), are used to group different parts of the regex and separate their logic from each other. These parts or groups are also called capture groups and calling match() not only returns the full match but also the captured groups

const str = "foo bar 123!"

str.match(/(foo|bar) .../) // ["foo bar", "foo"]

9. Fixed Quantifiers

Fixed quantifiers allow us to indicate the exact number of times a character needs to appear for a match to occur and they are denoted by a pair of curly braces ({}) after the character:

const str = "foo bar 123!"

str.match(/\w{3}/) // ["foo"]

// the range of repetitions can be specified by providing 
// a minimum and a maximum. If possible, it matches the 
// highest allowed number of repetitions
str.match(/\w{2,4}/) // ["foo "]

10. Optional Quantifiers

Optional quantifiers indicate that the character(s) preceding it can appear either 0 or 1 time, and they are denoted by the question mark (?):

const str = "John has 12 apples"

str.match(/John has 12 (red )?apples/) // ["John has 12 apples", undefined]

11. Kleene Star

Kleene stars, named after Stephen Cole Kleene who invented regular expressions, indicate that the character(s) preceding it can appear either 0 or more times, and they are denoted by the asterisk mark (*):

const str = "cat goes mew"

str.match(/meo*w/) // ["mew"]

12. Kleene Plus

Kleene plus, slightly different from Kleene stars, indicate that the character(s) preceding it can appear either ONE or more times, and they are denoted by the plus sign (+):

const str = "cow goes moooooooo"

str.match(/mo+/) // ["moooooooo"]

13. Anchors

Anchors signify the start and the end of a string, and they are indicated by the hat (^) and dollar ($) sign, respectively. If anchors are used, patterns won't be matched for texts that are in the middle of a string. New lines (\n) can be used to signify a new "start" of a string:

const str = "Unhappy cat\nHappy dog"

str.match(/^happy cat$/) // [null]
str.match(/^Happy dog$/) // ["Happy dog"]

14. Lookaheads and Lookbehinds

This is more of an advanced regex concept, but lookaheads and lookbehinds are zero-length assertions, meaning that they don't actually match characters but they still play a role in deciding whether a match will or will not take place. Lookaheads and lookbehinds specifically look at whether a certain pattern exists before or after the character in question, respectively, to make the decision:

const str = "foo bar 123!"

// Lookaheads can be positive or negative:
// Positive lookaheads are denoted by (?=) and then a pattern
// after the equal sign. If the previous character is followed by
// the pattern, then the previous character is allowed to match.
// The opposite is true for negative lookaheads, which are denoted
// by (?!):
str.match(/b(?=a)/) // ["b"]
str.match(/b(?!a)/) // [null]

// Lookbehinds can also be positive or negative, and they are
// denoted by (?<=) and (?<!), respectively. As the name implies,
// lookbehinds check whether a pattern appears before the
// character in question:
str.match(/a(?<=b)/) // ["a"]
str.match(/a(?<!b)/) // [null]

15. Flags

Lastly, flags are optional modifiers that are included AFTER the regex to describe how the matching will take place:

const str = "foo bar 123!"

// the "g" flag stands for "global matching", which tells the matcher to return all matches, not just one:
str.match(/\w{3}/g) // ["foo", "bar", "123"]

// the "i" flag stands for "case insensitive", which tells the matcher to ignore casing when finding matches:
str.match(/FOO BAR/i) // ["foo bar"]

// the "g" and "i" flags can also be combined:
str.match(/[A-Z]{3}/ig) // ["foo", "bar"]

Conclusion

Woohoo! Now that wasn't so bad, was it?

If you are still struggling to grasp some concepts, I have provided several resources below that definitely helped ME solidify my understanding of regex and get some good practice.

If you are feeling a bit confident, then take a look at the regex used to validate an email address and try to dissect it:

(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t] )+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?: \r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:( ?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()&lt;>@,;:\\".\[\] \000-\0 31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\ ](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()&lt;>@,;:\\".\[\] \000-\031]+ (?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?: (?:\r\n)?[ \t])*))*|(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z |(?=[\["()&lt;>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n) ?[ \t])*)*\&lt;(?:(?:\r\n)?[ \t])*(?:@(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\ r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n) ?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t] )*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])* )(?:\.(?:(?:\r\n)?[ \t])*(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t] )+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*) *:(?:(?:\r\n)?[ \t])*)?(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+ |\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r \n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?: \r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t ]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()&lt;>@,;:\\".\[\] \000-\031 ]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\]( ?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(? :(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(? :\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(? :(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)? [ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|"(?:[^\"\r\\]| \\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()&lt;> @,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|" (?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t] )*(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\ ".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(? :[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[ \]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()&lt;>@,;:\\".\[\] \000- \031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|( ?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\&lt;(?:(?:\r\n)?[ \t])*(?:@(?:[^()&lt;>@,; :\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|\[([ ^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()&lt;>@,;:\\" .\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|\[([^\[\ ]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()&lt;>@,;:\\".\ [\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|\[([^\[\]\ r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|\[([^\[\]\r\\] |\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()&lt;>@,;:\\".\[\] \0 00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\ .|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()&lt;>@, ;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|"(? :[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])* (?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\". \[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[ ^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\] ]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*( ?:(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\ ".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:( ?:\r\n)?[ \t])*(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[ \["()&lt;>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t ])*))*@(?:(?:\r\n)?[ \t])*(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t ])+|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(? :\.(?:(?:\r\n)?[ \t])*(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+| \Z|(?=[\["()&lt;>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?: [^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\".\[\ ]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\&lt;(?:(?:\r\n) ?[ \t])*(?:@(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[" ()&lt;>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n) ?[ \t])*(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;> @,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@, ;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t] )*(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\ ".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)? (?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()&lt;>@,;:\\". \[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?: \r\n)?[ \t])*(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[ "()&lt;>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t]) *))*@(?:(?:\r\n)?[ \t])*(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]) +|\Z|(?=[\["()&lt;>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\ .(?:(?:\r\n)?[ \t])*(?:[^()&lt;>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z |(?=[\["()&lt;>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:( ?:\r\n)?[ \t])*))*)?;\s*)

...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...

JUST KIDDING!

There are obviously more things to learn about regex, and even if you know regex to the dot, it won't exactly be a walk in the park to design/decipher complicated regex patterns as shown above.

However, the good news is now you know enough regex to start parsing texts for a variety of useful purposes! That and you can show off to your friends 😎😎😎

Happy coding!

Resources

How does Params work in Sinatra?

Anthony Chung — Tue, 20 Jul 2021 16:19:29 +0000

When working with Sinatra or Rails, you will most likely encounter something called params. It is short for parameters and is often seen inside route (request handler) blocks of controllers that handle HTTP requests such as GET or POST:

# songs_controller.rb
patch "/songs:id" do 
    song = Song.find(params[:id])
    attrs_to_update = params.select{|k,v| ["name", "genre"].include?(k)}
    song.update(attrs_to_update)
    song.to_json
  end

At first, params may seem a bit magical as it somehow automatically contains the data included in requests:

params = {
   "name" => "some_name",
   "genre" => "some_genre",
   "id" => "some_id"
}

So what is this magic called params?

Params is a method inherited from ActionController::Base that accesses the parameters passed from a request and returns a hash that encapsulates the parameters. It can access those parameters in one of two main ways: through the request body or through the request path.

Accessing Parameters Through the Request Body

Oftentimes, a web application will have an HTML form that can be filled by the user. On submission, the form would typically generate a POST request that contains the values of the user's inputs along with the names of the inputs inside a body object:

// A POST request that contains a body object
const newSong = {
   name: "Fly Me to the Moon",
   genre: "Jazz"
}

const configObj = {
   method: "POST",
   headers: {
      "Content-Type": "applications/json",
      "Accept": "applications/json"
   },
   body: JSON.stringify(newSong)
};

fetch("http://example.com/songs", configObj);

When this request is received by the controller, it will look at the body object sent with the request and add parameters accordingly to the params hash:

params = {
   "name" => "Fly Me to the Moon",
   "genre" => "Jazz"
}

Note: The keys and values of a params hash will always be of the string type. However, the hash keys can be accessed indiscriminately as strings or symbols since params doesn't actually return a hash, but it returns something similar called Sinatra::IndifferentHash.

Accessing Parameters Through the Request Path

The other main way to access request parameters is through the request path, or simply the URL. When the controller receives the request, it will look at the attributes within the request URL and add parameters to the params hash based on those attributes. This allows us to design routes more dynamically instead of hard-coding each route individually. There are two types of parameters that can be accessed based on the URL attributes: query and route parameters.

Query Parameters

Query parameters are parameters included after the ? in the request URL as shown below:

// A GET request with query parameters in the URL
fetch(http://www.example.com/songs?name=foo&genre=pop)

Such parameters are often used when we want to filter our search results (AKA what a GET request returns) by some queries and restrictions. For this reason, query parameters are considered optional and not explicitly included in the route path:

# songs_controller.rb
get "/songs" do
   ... 
end

However, the params hash will still include the query parameters found in the request path:

params = {
   "name" => "foo",
   "genre" => "pop"
}

Route Parameters

Unlike query parameters, route parameters must be named within the route path for them to be accessible via the params hash:

# songs_controller.rb
get "/songs/:id" do
   ... 
end

The controller would then recognize the route parameter in the request path by the placement of the parameter value within the URL:

fetch("http://www.example.com/songs/3")

... and add it to the params hash:

params = { "id" => "3" }

Route parameters can also be combined with query parameters:

fetch("http://www.example.com/songs/3?name=foo&genre=pop")

... for an even more customizable params hash:

params = {
   "id" => "3",
   "name" => "foo",
   "genre" => "pop"
}

Conclusion

While the magic of params is often unquestioned and left to wonders, its behavior under-the-hood is actually straightforward to grasp. To summarize, params is an inherited method that returns a hash that contains parameters passed by a request through its body or through its URL. Overall, understanding this behavior will (hopefully) make your life easier by equipping you with the ability to control the structure of the params hash as well as build routes more effectively.

Params can also access other types of parameters such as splat (wildcard), regular expression (regex), and optional parameters. To learn more about them, you can refer to the first resource down below.

Happy coding!

Resources

When That's Not So Fetch: Error Handling With fetch()

Anthony Chung — Fri, 25 Jun 2021 18:01:40 +0000

The fetch() method in JavaScript is a global, asynchronous method that allows us to interface with API's for requests and responses. While this is a powerful and commonly-used tool, its error handling process may seem a bit elusive at start.

Why Error Handling?

When errors are encountered during a fetch() call, it is often necessary to halt the compiler from reading the next few lines of code. To do so, the method call should throw an error upon encountering one. The thrown error can be "caught" later on for an alternate behavior to take place. Although one might think that the fetch() call would automatically throw an error upon encountering one, that is not the case for JavaScript.

According to the fetch() MDN, the Promise object returned by the fetch() call is rejected (throws an error) only when "a network error is encountered." This means that fetch() Promises do resolve despite encountering client-side HTTP errors such as 404 and do not throw errors during the fetch. Therefore, the code shown below would log "Success" instead of "Error" when run, which may seem unexpected.

fetch(url) // encounters a 404 error
   .then(res => res.json()) // no error is thrown
   .then(() => console.log("Success")) // 
   .catch(() => console.log("Error")) // fails to catch error

Luckily, you can fix this quite simply by using proper error handling.

Handling fetch() Errors

fetch() calls can be made using either Promise chains or Async/Await. Fortunately, the error handling process is similar for both.

Using Promises

The fetch API provides an ok property to the Promise response which indicates whether the HTTP status is within the range 200-299 (inclusive). This can be used to check whether any error is encountered during fetch.

const handleError = response => {
   if (!response.ok) { 
      throw Error(response.statusText);
   } else {
      return response.json();
   }
}; //handler function that throws any encountered error

fetch(url)
   .then(handleError) // skips to .catch if error is thrown
   .then(data => console.log("Does something with data"))
   .catch(console.log); // catches the error and logs it

The error-handler function should be called before the Promise response is parsed by .json(). Otherwise, the .json() method would strip out the response properties necessary for error handling (such as ok, status, and statusText).

Using Async/Await

Error handling using Async/Await uses a slightly different syntax, but it also revolves around the idea of using the ok property to check whether any error is encountered or not.

const response = await fetch(url);
if (!response.ok) {
   console.log(response.status, response.statusText);
} else {
   const data = await response.json();
   console.log(data);
}

The status response property provides the status code (e.g. "404") while the statusText response property provides the status description (e.g. "Is Not Found").

Conclusion

Although the error handling for fetch() may not seem intuitive at first, it will later make more sense since it provides the user with more control over unique situations.

Overall, error-handling for fetch() calls is a simple and user-friendly tool that will definitely aid you in the long-term.

Resources

Comparing Apples to Oranges in JavaScript: Implicit Type Coercion

Anthony Chung — Fri, 04 Jun 2021 16:29:57 +0000

While it is unusual to compare apples to oranges in our everyday lives, it is quite common to do so in the world of programming where we often perform operations on numbers, strings, and other data types. This is especially true for JavaScript since it is a weakly-typed (or loosely-typed) language, where we are not required to declare the data type of a variable before operating on the variable. This is unlike a strongly-typed language, such as Java, where variables need to be bound to specific data types. You might now be thinking, "Why don't we just make everything loosely-typed since it seems more convenient?". Well, the thing is, loosely-typed languages can be more of a headache than it seems...

What is Implicit Type Coercion?

To expand on the headache, we first need to know about how JavaScript interprets and manages loosely-typed variables. When we perform an operation on two values, as shown below, JavaScript automatically converts the type of one value to match that of the other if they do not match initially.

const x = 1; // this is a number
const y = "thing"; // this is a string

x + y; // returns "1thing", which is a string

This automatic conversion is also called an implicit type coercion since a value's data type is forcefully converted.

Some strongly-typed languages like Java can also perform limited implicit type coercions. For example, the above expression of 1 + "thing" would similarly return "1thing" in Java. In addition, Java can implicitly convert smaller data types to larger data types under certain contexts.

So this seems convenient so far, right?

Well, let's now look at a different example:

1 + "2" + 1;

What do you think will be returned from this expression? You might think that the "2" would be converted to a number so that the overall expression would evaluate to 4. However, the expression actually returns something else:

1 + "2" + 1; // returns "121"

We get a string of "121"! This happens because of two important reasons:

Whenever there is a string operand during a + operation, JavaScript automatically assumes that the + is the concatenation operator and combines the two operands as if they are both strings.
JavaScript reads the expression from left to right (and follows the order of operations specified by PEMDAS) so that it is only performing one operation at a time. For the example above, 1 + "2" would first evaluate to the string, "12", before it encounters the + 1 on the right.

As you can see, the implicit type coercion behavior of JavaScript can become more and more perplexing as the expressions get more and more... funkier:

true ^ null; // returns 1
(NaN == NaN) + {}; // returns "false[object Object]
{} + !null + []; // returns "1"
((1001 - "1,001") == null) == "" // returns true;

You will probably never have to encounters the funky examples above (hopefully) so don't worry too much about not understanding them.

Should we ignore the elephant in the room?

Due to the seemingly unpredictable nature, implicit type coercion is generally considered a JavaScript feature that is best avoided when possible (which makes it *ehem* the elephant in the room). However, I would argue that it is resourceful to study up on since it will likely help you track down any type coercion-related bugs in your programming future.

In addition, implicit type coercion allows you to use nifty shortcuts such as:

!!value; // two !("bang") operators coercively returns the value's boolean value
+value // converts the value to a numeric value
"" + value // any value that comes after the "" is evaluated as a string

Although, it is discouraged to use too much shortcut in programming (since it makes code less readable), the above shortcuts are used widely among programmers and are universally deemed as syntactic sugar.

Conclusion

At first glance, JavaScript's implicit type coercion feature may seem unfamiliar and even too convoluted to effectively utilize. However, once you get a better handling of how weakly-typed languages work, you will soon be able to embrace implicit type coercion as a pro rather than a con as you progress through your programming career.

If you are curious to know more about how implicit type coercion works, feel free to check out the resources below. Alternatively, you can try your own cocktails of mixed data types to generate different (and oftentimes surprising) responses.

Have fun!