Open xNS5 opened 1 month ago
I'm thinking that using the shadcn for the table will be a good idea: https://ui.shadcn.com/docs/components/data-table
I like the headless-ness(?) concept.
The reviews grid will have the following features:
onClick(...)
event to display the summary for the currently selected elementEdit: Will add grid filtering in a different ticket
Pushed the initial implementation for pagination, want to tweak the UI to be more in line with existing UI.
Also implemented the experimental cache feature from next (see #17)
Also added search functionality, it's surprising how easy that was.
For the "filter", I'm imagining something for each other data-related column. Adjusted review rating, rating, review count, etc. Maybe some sort of checkbox type system, maybe radio button group.
Added some logic for the cell elements. Wrapped the element text in buttons, but I don't know if it's 100% necessary for elements other than the "name". I want to allow the user to copy numbers without triggering what was previously the row's onClick(...)
action. I don't think that really needs a custom function to copy. The ideal end result for this is to have the row element similar to Notion in style, specifically something like <name of location> <Button/>
that's visible on hover/enter.
Now that I have the data presenting to the end user (with some basic styling), now I need to create some sort of article-header type component to essentially re-display the data in the data grid component. Additionally, I'd like to add a button that displays the raw JSON data. Probably will do a similar approach to the review data, but might add an additional check in the event the user is navigating directly to the URL instead of from the previous page.
Note to self: increase cache value
I'm going to be changing up how data is requested from Firestore. Instead of calling the database functions directly, I want to call them via some API routes. The benefit of this would be that I could utilize next.js' fetch(...)
caching along with the experimental cache I added to the firebase functions. Upon cursory check, it seems like the caching is working, but I'm going to have to do a bit more investigating before I'm satisfied that it's working as expected.
On an unrelated note, Next.js' documentation is way out of date. While this was a good learning experience, because of that I think that I'll avoid next going forward.
I'm curious about my current caching implementation. Apparently there is a 2mb limit, and I'm not sure how to better balance performance with caching size. I think I just need to do some research on caching best practices. The data I'm requesting is more or less going to be static so I don't need to be constantly re-validating from firebase.
It might be a good idea to separate out the data being requested. One document collection for the actual articles, one for the company information, and another for the reviews. This would technically be possible and wouldn't require data duplication.
So ideally, something like:
{
"articles": [...],
"companies": [...],
"reviews": [...]
}
All collections will have documents where the ID is the company slug. This will technically reduce the overall load on the front-end application, however will increase the number of db calls to 2-3 per action.
For example:
reviews
, which uses the companies
getter. articles
getter.articles
, companies
, and reviews
. As both articles
and companies
should be cached it won't be a problem, so that's an additional database call with the reviews
. Implemented Mongodb functionality that switches between it and firestore depending on an environment variable. Now that's done, I think I might change up the functionality to where the grids are client components and use the new API routes I created.