search

carlosvegap / capstone-kickoff

0 stars 0 forks source link

joined active/inactive endpoint for status in addventurer #61

Closed CarLosVegga closed 1 year ago

CarLosVegga commented 1 year ago

Hi everyone!

A bit of context for this PR. I basically had this two endpoints to get an array of IDs of inactive and active preferences. What I would do is that I would get that array for the user (making the request to the middleware to the db and back), so that I would later call another endpoint that given an array of IDs, returns the information of those keys (again, from UI through middleware to db and back)

ADVENTURE.JS

To improve it I decided to have this one endpoint that returns both keys in one call, so it gets you back an object with the format { active : ['feedbackID', ....], inactive: [...] }, and with the help of the endpoint found in the https://github.com/carlosvegap/capstone-kickoff/pull/60, I would just filter the data in the UI. In other words, with this PR I have the array of keys, with the previous I get all data and I apply a filter.

The preferences/update route still works, so I just need to refactor it the way I was doing it, with queries on its corresponding doc.

ADVENTURER.JSX

Sorry, I just realized that Prettier and ESlint are in disagreement on the rules that made most of the changes on this file. The only thing is that I added a Provider to my Feedback context so that I can do the filtering that I mentioned in the first part of Adventure.js

PREFERENCE.JSX

I consume the context and I added the filtering that I mentioned. For active preferences I had to do a map of the keys and then find that key within the feedbackInfo, so that the order in which my activeFeedback array is structured is preserved (that is the order that the user has setted)

USESETTINGS.JSX

Finally in my custom hook I changed the structured so that it matched what was required and would be generated from my endpoint in Adventure.js

Thanks for the help!!

CarLosVegga commented 1 year ago

That solution sounds interesting!

One of the reasonsI followed my format was because I was concerned about how it would react if I added more entries to my feedback db. With what I implemented, the integration would not require any further action: since that objectId is not store in the user preferences, it would be catch as inactive by my algorithm when comparing the activeIDs and all possible preferences.

Thinking about adding this format, I am not seeing what would the proper way to update the feedbackIDs. The process I can only think of is to add to every UserPreference the key of the new preference and setting it's isActive to false, as well as the rest of the otherFeedbackData, however that sounds a bit of expensive in temporal complexity. I would love to hear your thoughts about this!