Intro to Developer Tools in Google Chrome

How to open Developer tools in Google Chrome

On Windows, you open it from the Chrome menu that is usually in the top right - under More Tools > Developer tools.

You can also use a keyboard shortcut - CTRL - SHIFT - I on Windows, CMD - OPT - I on Mac OS.

How to view API calls in Google Chrome

FOLIO API calls will appear in Google Chrome in the Network panel as actions in FOLIO occur. E.g., if you want to see the network calls for a particular record, you need to open Developer tools first, and then  open the record or refresh the page to reopen the record, in order to see the network activity.

Tip: use the network "clear" button frequently

The list of network calls will fill up VERY fast. You can use the clear button (the "no symbol" icon) to clear the list of calls and reset it whenever you need to.

Example: Viewing an Instance Record

Suppose we go to FOLIO Snapshot and we view the instance record for "Temeraire", one of the example instance records loaded when Snapshot is built.

When you first load the record, you'll see a long list of calls show in the network panel. This is what FOLIO is doing behind the scenes to make everything appear.

In the network panel, you'll see a few columns. The ones you'll probably see most often:

• Name: this is just the name of the script or call or whatever it is doing. 
• Status: This is the HTTP status code that is returned by the network activity. If you are not sure what a number is, it is best to google it to get an explanation - usually something like "HTTP status code 201" will immediately return an explanation of what it means. The status codes are generally most useful for errors - e.g., they can tell you information about where an error happened (in the browser or on the server) and what type of error that FOLIO thinks that it was.
• Type: This tells you the type of network activity that Google Chrome determines is happening. The most important one to pick out here is "fetch" - that generally tells you that what is listed involved an API call that posted or returned data.

To view a network call, you can click on it from the list, and Chrome will open a new panel to show you information about the call:

Things you can learn from this screen include:

• Request URL: Available from the Headers tab, this tells you the structure of the call that was used. E.g., in this case, a call was sent to the Okapi server (https://folio-snapshot-okapi.dev.folio.org) with a request method of GET and a path of /instance-note-types?limit=1000&query=cql.allRecords%3D1%20sortby%20name
  • This is an example of FOLIO downloading a lot more data than you see in the UI. instance-note-types is a setting - frequently FOLIO downloads the entire content of a setting and stores it in the browser so that when you edit a record, it doesn't have to fetch new copies of the setting value if you change it, it can get the data locally.
• Status code: In this case, the status code is 200 - this is a 200 OK status response, which means the transaction was successful. 
• Okapi token: If you scroll down the right pane further into the request headers section, you can also find the x-okapi-tenant and x-okapi-token values for your transaction, which can be very useful if you are trying to replicate an API call in a tool like Postman.
  

Retrieving data from a JSON call

A very common FOLIO task is using developer tools to quickly retrieve the JSON for an underlying FOLIO record.

Continuing with this example, let's suppose that you really needed to see the underlying JSON data for the instance record that you are viewing in the browser. You can do this with Postman or with another reporting tool, but it can often be quicker to get the data with Developer Tools.

To retrieve the JSON data for the instance record for "Temeraire", I reference the URL to see if I can determine the UUID for the instance. In this example, the UUID is the long string beginning with "cf23...."

I can then scroll through the list of network calls and find the one with that UUID. And I can tell from the request URL that this is the instance call - 

So now that I've found the right network call, I can go to the Response tab, and see the underlying data:

I can then select and copy/paste that data into another tool like Notepad for whatever I need to be able to do.

Stumbling block to be aware of: Using UUIDs in the record URL

The UUID trick to find the record that worked with an instance does not work with every type of record.

For example, some record FOLIO urls have multiple UUIDs because it is referencing hierarchical data, and the URL is built from that data. For example, an item record has three UUIDs in its URL - the first for the instance, the second for the holding, and the third for the item.

There is no concrete rule for which UUID is the record you are looking at - you just learn by experience.

There can also be records that you are interested in that are not referenced by a UUID in the URL at all. For example, in the Courses app, there is one UUID in the URL, that represents the course. But, there is also an underlying record type called a courselisting that does not have a UUID represented in the URL.

In these cases, you will probably have to page through the list of calls to find what you are looking for. However, with experience you will be able to recognize what matters and what doesn't (e.g., you don't need to look at all of the calls that are simply FOLIO retrieving icons for display) and get faster at figuring out which call is the right one.

Troubleshooting unexpected FOLIO behavior

When FOLIO encounters an error, the expected behavior is that the error message shows up in the FOLIO user interface so you can read it and decide what to do / report a bug.

However, it's not unheard for an error message to occur that is not properly displayed in the user interface. You might then see behavior where you click a Save button and nothing happens, and you're not sure what to do.

Developer tools can let you see if there might be an error message "hiding" under the user interface, that you can then report.

Example: Figuring out why an item record won't save

A real-world example was captured in Jira as part of UIIN-2284 - Getting issue details... STATUS .

In this case, the steps to create the bug were as follows:

1. Edit the item and click "Add Statistical Code", but don't assign a value.
2. Click Save and close. 

When you save the record, nothing happens, and no error message appears in the familiar red "toast" to tell you what the problem is.

But, if you repeat the same steps with developer tools open, then you get more information.

Here, developer tools shows you that an API call failed. You can tell it failed because it's highlighted in red, and in the status code field, you can see a response code of 422 - that is the HTTP error code for "unprocessable entity."

When you switch to the Response tab, you can see that the FOLIO API returned an error message:

"{"errors":[{"message":"elements in list must match pattern","type":"1","code":"elements in list must match pattern","parameters":[{"key":"statisticalCodeIds","value":"[null]"}]}]}"

In an ideal world, you don't need to go into developer tools to understand an error message, but because FOLIO is under active development, sometimes things like this can happen.

Knowing how to go into developer tools allowed the person reporting the bug to understand what was going on. They could read the error message, look and see that oh, the statistical code field had been accidentally clicked and there was no value, and FOLIO didn't know what to do. The person could remove the blank statistical code field and then be able to successfully save the record, and then report the bug.