Issue Tracker question about "issue.html"

Hi there - I’m just starting this Quality Assurance project and noticed there is a file called issue.html. Is this file needed in the project? Should I be thinking about using it?

These projects can be a little confusing at first but it’s useful to know that the HTML and other frontend stuff is already completed for you, so you need not edit those files (unless you particularly want to). You’ll note in the server code that issue.html is loaded when you visit a specific project url.

The only code which you are required to implement yourself is for routing and QA tests mostly (i.e. the backend stuff).

Having said that, I found it useful to understand exactly how the frontend works, so I went line-by-line through all of the provided code, as it then gave me a much clearer idea of how it all worked together.

Thank you for replying. I’m still a bit confused:

The instructions state:
a) Complete the necessary routes in /routes/api.js and
b) You can send a POST request to /api/issues/{projectname} with form data containing the required fields issue_title, issue_text, created_by, and optionally assigned_to and status_text.

  • in server.js index.html is loaded when the url is \
    ** in index.html the post is going to url /api/issues/apitest which suggests that {projectname} is apitest
  • in server.js issue.html is loaded when the url is /:project
    ** in issue.html the post appears to be for /api/issues/:project
  • in api.js the code already there is for /api/issues/:project

Do I have to complete the routes for /api/issues/apitest also? Wouldn’t that be duplicated work?

Have I understood the assignment correctly?

I found this quite confusing at first too.
Here are my notes on the boilerplate code which is provided (no spoilers about solution).
Essentially, you have a sample frontend with a sample project (apitest) built-in.

Your task is to provide full routing code for ‘/api/issues/:project’, which will take the data sent by the AJAX requests and update your database accordingly. Going via the sample frontend (index.html), these AJAX requests deal (almost) solely with the ‘/api/issues/apitest’ route. The only exception is when you update an issue by its ID, the routing code for which will effectively ignore the project name parameter as it searches the database by id and updates the issue directly (regardless of which project it’s attached to).

However, when you visit ‘/:project/’, issue.html is loaded, which contains rather more convoluted AJAX requests, which populate the page with the data retrieved from the database, and allow you to submit new issues to that specific project and also close/delete any displayed issues.

Your routing code for ‘/api/issues/:project’ will handle ALL database requests, whether for apitest or any other project.

I don’t feel I’ve explained this particularly brilliantly but I hope that makes some sense to you!

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.