Open korroktheslavemaster opened 6 years ago
Oh, yes. The dates are directly from the noticeboard itself. The reason I didn't add a time
field to the database was that:
We could add timestamps based on the time at which the new notice was found by the scraper, but then we'd have to handle all the older notices separately. And using the one included in the notice would mean we'd have to handle the 'no timestamp' noticeboards separately. Both of which, in my opinion, aren't high priority problems.
Besides, the API currently returns the notices in latest-first fashion (latest as defined by higher position in the original noticeboard), which seems consistent enough to me.
Is there any case that I might be missing which would be worth going through all this trouble to get the order right?
Also, I think this issue would make more sense in the API repository: https://github.com/metakgp/veritas (As a side note, the scraper code lives here: https://github.com/metakgp/hermes. The reason for this separation is explained in the README.)
So right now the notices are persisted in redux, and new notices are fetched when tabs are switched (so that we always have fresh notices) and merged with existing list of notices. After merging, it would be good to sort the notices again so that new ones are at the top. We can probably do this with _id field (mongodb _id is just a timestamp of document creation) but maybe you can figure out something better
Oh, I see. Yep. That makes sense! Good suggestion.
I am indeed using the _id
fields to fetch the latest notices. I'll return that as well in the GET request.
Actually, the API is indeed already returning this. My bad!
There seems to be inconsistency between UG/PG time formats (maybe this is from noticeboard only?) In any case there should probably be a field, either time or _id, with which we can sort notices by so the newest ones are shown first