Create Tag endpoints

[kaydengrant]

I agree with refe that we should make tag endpoints for a much cleaner build.

• [x] Create POST endpoint at /api/tags/ that creates a tag with x body
• [x] Create GET endpoint at /api/tags/:tagId to get a specific tag
• [x] Create PUT endpoint at /api/tags/:tagId to update a specific tag
• [x] Create DELETE endpoint at /api/tags/:tagId to delete a specific tag

These should be pretty easy routes to test and make since there are only a few requirements to a tag (being id, name, and color)

[reevesabbas]

I'm assuming we want users to be able to create a tag while creating a task, like a small + next to list of existing tags to create new tag. Do we create 2 POST routes? One that takes in userId and just creates a tag. One that takes in taskId and adds tag to task. But whilst creating a task the taskId won't exist to link a tag to it.

I am confusion.

[kaydengrant]

Good question, I didn't even think about this for some reason. Since they will both do the same thing (minus appending the tag to a task), I think the best approach would be to add the taskId as a query param and just do one post route. That way the taskId field would be optional and we could use it for specific cases like if a user wanted to create a tag when they were creating a task. What do you think about that.

[reevesabbas]

Ya sounds good to me, but would we be able to call the route w/out a taskId?

[kaydengrant]

Yeah, since its a query param, the data is optional. So if we know the taskId then we will link the tag with the task, if not then we assume that they are creating a tag just to create a tag. We can always use the put route to link tags and tasks whenever.

[kaydengrant]

Last time I installed a package for color for our tags. I realized that we don't need that and we can just use a widget in the front-end for users to select what color they want. All we need is a string or number variable in the back-end since we are just holding the value.

[kaydengrant]

Okay so I've been working on stuff the past few days working out some kinks and I got some stuff to work and the rest I'm so confused about. Also, I think I figured out some stuff but I cant figure out how to implement it.

DB Locking: I have tried working on this for a while and I kind of have given up. The main issue now is that close() is not being read as a method for type Connection which is odd. I've looked over many resources and the best answer I could find (that dealt with typeorm) was to npm install package-lock.json but it didn't really do anything and neither did any other solution. Also I am reverting npm install since it did nothing.

Error message --> "TypeError: Cannot read property 'close' of undefined"

User.ts entity: When we made the Task entity, we decided that there could be no tags which is why we added the ? instead of the ! which makes sense to me.

tags?: Tag[]; 

I was looking in the User.ts entity for reference and I noticed that tasks were a required field (using a !). Wouldn't it make more sense to make this a non-required field since it's possible a user could not have a task going on? I also left a comment in the entity in case yall want to find it specifically.

//a task is required to have a user, but does a user need to have a task?
  @OneToMany(() => Task, task => task.user) 
  tasks!: Task[];

task.tags array: In our tags.ts route, I wrote it so if there is a taskId in the query parameters, then find the task with that taskId and push the tag into the task.tags array.

if (req.query && req.query.taskId) { 

          const task = await Task.findOne({ where: {id: req.query.taskId}, relations: [taskRelations[0], taskRelations[1]] });

          if (task) {
            task.tags?.push(tag);
            await task.save();
          } else {
            res.status(404).json({ message: 'Task Not Found' });
          }

      }   

As this does push the tag into the array (testing using console.log in tags.ts lmao), when I run the test in Jest, the array comes out empty. I believe this has to do with task.save() not working properly but at the same time I'm very confused bc thought that it should update the task entity. Here's the test case for this specifically.

const res = await request.post(`/api/tags/${dbUser.id}?taskId=${dbTask.id}`)
      .send(tagExample);
      const task = await Task.findOneOrFail({ where: {id: dbTask.id}, relations: [taskRelations[0], taskRelations[1]]});

      expect(res.status).toBe(201);
      expect(task.tags).toContainEqual(tagExample);

One last thing, I tried searching for the task without using relations and it didn't work. I referenced all the other times we used relations to type that and idk how it works really so a little refresher would be nice as to why it works with the relations and why it doesn't without. I'm gonna go cry and eat frozen pizza now goodbye.

[reevesabbas]

Got no clue what to do abt the db locking.

I'm not too sure about the task being required in the user entities. From my understanding tasks are something that needs to exist in a user entity and tags is not something that needs to exist within a task entity.

tag POST route: This route looks wildin. I think we have one too many conditionals. My guess would be that the issue has to do with saving, either task or tag aren't being saved to the database properly but it could also be 57 other things.

Reference this for the relations question you had.

We definitely need to re-visit that one Db relations website that Kieran had us do. Idk about you but I need to re-make that thing and get a better understanding of how task, tag and user are related.

[kaydengrant]

I fixed all of the current tests for both tags and tasks. There are a lot of commented-out tests for tasks and we need to finish writing all of the tests for the other routes for tags. I remember that we paused the work on task tests because we needed tags for a lot of the tests so I say we start writing the tests for tags and make sure all is good and then we can return to task tests.

At the current moment, all tests are running green but still having that issue with db locking which is really annoying. I keep on getting the message that connection.close() is not being read. that's all for now laters.