Give Record Collection challenge more context

I have been thinking about this challenge and I think the description/instructions could use a little more instruction. I know the instructions were recently updated and even though the challenge is better, I think it could still use a few minor tweaks.

Why don’t we make it a little clearer that id represents a property name in the records object and prop represents a property that may or may not be present in a specific album? Experienced developers would assume this to be the case, but obviously this is not the case with aspiring students.

What about some small adjustments like:

You are given an object literal representing a part of your musical album collection. The collection has multiple albums which are also objects. Each album is represented in the collection with a unique id as the property name. Within each album, there are various properties with facts about each album. Not all albums have complete information.

You start with an updateRecords function that takes 4 arguments represented by the following function parameters:

  • records - an object literal (records) which is the record collection being analyzed
  • id - a number representing a specific album in the records object
  • prop - a string representing a property of the album that may or may not exist
  • value - a string value that will be used update an album’s information`. Complete the function using the rules below to modify the object passed to the function.

I know the above adds more text, but in lieu of adding a new challenge before this one (which does not make sense due to the new curriculum coming out in the not so far future), I think it improves it a bit.

You will notice I use arguments and parameters in the instructions. These concepts have been introduced already, but seeing this is the first big function written, repeating them again with context could improve the learning here.

The exact wording I used above could be improved more but the main idea is to explain in more detail what the parameters represent and explain more about the record collection’s data structure.

I like making the arguments list into a bullet point list.

I would ditch the word “literal” - it isn’t adding useful information to the reader, and the function does not only accept an object literal.

Minor wording suggestions:


The updateRecords function that takes 4 arguments represented by the following function parameters:

  • records - an object containing several individual albums
  • id - a number representing a specific album in the records object
  • prop - a string containing the name of the album’s property to update
  • value - a string containing the information used to update the album’s property

Complete the function by using the rules below to modify the records object passed to the function.

@JeremyLT Great suggestions!

How about this:

You are responsible for creating a function that aids in the maintenance of a musical album collection. The collection is organized in an object that contains multiple albums which are also objects. Each album is represented in the collection with a unique id as the property name. Within each album, there are various properties with facts about each album. Not all albums have complete information.

The updateRecords function takes 4 arguments represented by the following function parameters:

  • records - an object containing several individual albums
  • id - a number representing a specific album in the records object
  • prop - a string representing the name of the album’s property to update
  • value - a string containing the information used to update the album’s property

Complete the function using the rules below to modify the object passed to the function.

1 Like

I want to push against this. Yes, because this is silly JavaScript, “the function does not only accept an object literal”. However, we only test for calls where the record parameter is an object literal, and the example given for input/testing is an object literal.

I might be overly pinickity with this, but JavaScript has this annoying (to me) property of terminology where:

const a = [];
const b = {};

typeof a === 'object' && typeof b === 'object';

So, it is correct to say “object”. However, it is more informative/precise to say “object literal”.


I am happy with other text changes to this challenge. Anything other than a change to the description, I think we better leave as is, and focus on the updated/new JS content.

The fact that there is an object literal is not a user requirement - it is an artifact of how we wrote the provided code. The ‘object literal’ is one of many possible ways to initialize an object. The user cannot and will not be writing the function to only accept only object literals because they have no way of knowing how what syntax was used to initalize the object. Their logic does not in any way mandate that the records are created with an object literal instead of with a constructor function, for example.

Heck, the test cases technically do not use an object literal as the function argument

updateRecords(recordCollection, 5439, "artist", "ABBA")

Here a variable that was initalized with an object literal expression is used as the argument, but an object literal expression is not written in the space for that first argument.

Right. Keeping this in mind:

How would you write the prompt to differentiate between an array and an Object? Such that Campers do not think they need to perform checks like: Array.isArray(record)

What project/projects in the new curriculum cover the topic of object literals or the fact that using typeof on an object literal or typeof an array both show "object".

Yes, object literals are really singletons vs. objects which are created via a constructor function, but at this point in the Basic JavaScript curriculum, that is just extra noise preventing the student from learning how to properly update the object in the challenge.

I think object literal without the discussion of objects created by a constructor function is useless at this point. There is another part in the curriculum that covers objects created via constructor functions. Even then, there is no contrasting between the two. Using the word literal here at this point in the Basic JavaScript section is trivial with out any context given of what that means.

This sentence was referring to making it clearer to new students that id and prop are properties of objects.

I would just say object when we mean object and array when we mean array. Do most of the learners know that an array is a special case of an object in the internal implementation?

Do any of our challenges other than Arguments Optional use input validation?

That is valid. I will not push back on this any more.

I do not know; I would not be surprised if over 50% of JavaScripters did not know that.

What do you mean by this? Having Campers write a function that is unit tested?

This challenge requires the user to write code to validate the function arguments:

I was wondering if any other challenges did argument validation

Ah… I cannot think of any, and am far too lazy to read through most of the lessons to find out :upside_down_face:

1 Like

Thanks. I think this whole discussion would be useful for those working on the new JS curriculum, to make sure it covers these topics regarding object literals vs objects created via a constructor function.

Honestly, the only reason I wanted to see something like my suggested change was to hopefully reduce the sheer number of questions we get about Record Collection every day.