Issue Tracker - Missing _id - Why does this work?


Wrapping up Issue Tracker here. Um, I was struggling for a long time on passing all the PUT tests, and for the longest time this test would not pass:

When the PUT request sent to /api/issues/{projectname} does not include an _id , the return value is { error: 'missing _id' } .

To make this test pass, my code had to be:

The api.js Route:

 .put(async (req, res) => {

//some code stuff

 if(_id === '' || !_id){
        console.log('missing id')
        return res.json({error: 'missing _id'});

//more code stuff


<input type="text" name="_id" placeholder="*_id" style="width: 100px" required=''><br>

I don’t understand…why would I need an or statement to prove that the “_id” input on the HTML form does not exist?? If the item on the form does not exist, is it a ‘’ or a null object? Wouldn’t the falsy test (!_id) make it pass already?? Maybe I’ve been looking at it too long.

Never mind, it works with just if(!_id) …I noticed that sometimes the FCC node testing can be glitchy, and you have to run it a couple times to work.

But can someone explain this regardless?

can you share a link to your full code please

I dont think it means if an id input on the form does not exist. I am thinking what its saying is that the server is expecting a certain parameter to be an id…

like you can send an request using postman to that route for example. and maybe what I send is missing an Id parameter. so I believe what its asking for is if that parameter does not exist it wants you to handle it that way. It makes sense?

P.S. Ive not done that challenge, so maybe someone with more experience will comment, however what I dont understand about it… I mean what exactly are you doing with on that route, you said put request, are you updating an existing item or are you creating a new one? If you are updating an exisitng resource whats the necessity of that check in the first place?

see here:

Hello there,

I am not sure what you are wanting explanation for, but I assume it is this:

In JS, unless an object is told to be null, then it is not null. That is, if _id is not given, then when you try to reference _id, it is undefined (not null).

Regardless, the check if (!_id) will catch the following cases:

  • null
  • undefined
  • ''
  • []
  • '0'

I do not understand the required='' bit. I was unaware required could take a value. :man_shrugging:

Hope this helps

1 Like

Hey folks,

Sorry for the vague explanation, it was really late last night. But yes, @Sky020 I was asking for what (!_id) catches for, so you hit it on the head. Thanks for that explanation.

For issue tracker, the one of the challenges asks for updating the database using the HTML form:

As part of updating issue on apitest, the form provides an input for “_id” of the issue in the database. If the user input “_id” is left blank, the return value should be {error: ‘missing _id’}.

Therefore, to make the test pass, as part of the “.put” api route, (before calling model.findIdAndUpdate) I had to write this:

        return res.json({error: 'missing _id'});

Sometimes is glitchy? And the FCC doesn’t pass, but eventually this did.

@Sky020 , your question about the required='' ~ This was written by the FCC team, as part of the built-in HTML on the boilerplate. Basically, it seems that when you put required='' as part of the input, it becomes an in-built “checker” that makes sure the user has to fill out the field. If you don’t fill out this part, and you hit submit, you get this popup:

Honestly, this feels redundant, because that means that both the HTML and the JS are checking whether the user has input this value. This was confusing for me until I started looking at the HTML boilerplate.

Thanks, for showing the change in functionality with required='' and required.

Just to clarify the main idea behind the project: You are supposed to be focusing on the backend, during this project. This is why the backend projects have you write APIs (the different endpoints of your server) to achieve otherwise common frontend functionality.

Essentially, you will find many programs have APIs targetable by both an integrated frontend, as well as miscellaneous other services. Take GitHub as an example:

  • There is a UI-based webapp users can use to submit PRs to repos
  • There is also an available API with no UI, users can use to submit PRs to repos

So, there needs to be both a clear communication to those who use your UI-based app, and those who use the API directly (checking for _id or not should be done on both ends).

1 Like

Ahhh. Great, thanks for the explanation, really helpful.