Display JSON data for pages

[xNS5]

• [x] Home
• [x] About - [ ] Contact
• [x] Reviews

[xNS5]

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.

[xNS5]

The reviews grid will have the following features:

• [x] Pagination
• [x] Search
• [ ] Filtering
• [x] Sorting
• [x] onClick(...) event to display the summary for the currently selected element

Edit: Will add grid filtering in a different ticket

[xNS5]

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)

[xNS5]

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.

[xNS5]

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.

[xNS5]

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

[xNS5]

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.

[xNS5]

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:

1. User navigates to reviews, which uses the companies getter.
2. User opens the review, which calls the articles getter.
3. The user wants to see the raw data, so it calls 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.

[xNS5]

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.

[xNS5]

I'm trying out a way to cache requests server-side using Node Cache per these instructions: https://github.com/vercel/next.js/discussions/59509

I might end up nixing it in favor of something else, I just want to try this out.

[xNS5]

There are a few benefits to running an in-memory cache vs something like a Redis server. While it would increase overall memory utilization, I wouldn't have to rely on a third service like Vercel's KV or maybe even a self hosted server which would add more work.

Given the size and lack of complexity I think that's the safest approach.

[xNS5]

Trying out node-cache in https://github.com/xNS5/rentalreviews/tree/16-experimental

Need to add some console logs to check whether cache was actually getting hit or not.

I'm debating removing the API portion from the code, but it might be useful in the event I switch to a separate front-end application.

[xNS5]

At this point I think I'm going to keep the API portion on a separate branch after I'm done. It would be a good idea to keep it on hand should the need arise.

[xNS5]

The specific keys to update UI elements in the JSON viewer

[xNS5]

~On second thought, I'm going to simply rely on Monaco Editor for displaying the JSON data. It's a little over 2x the size of the other JSON viewer (62kb vs 150something kb), but it saves me from having to recreate the functionality I need/want in a different component.~

Hah well that ended quickly. Ended up finding a json viewer that actually works for what I need. The Monaco Editor component is useful, however it has more functionality that I would need to disable when this ends up in prod.

[xNS5]

I switched over from the Headlessui dropdown to the shadcn dropdown (which essentially is a radix-ui component). This wasn't absolutely necessary but it was bugging me.

Data wise, I moved the configuration files to the database. I think I'm going to rename the respective getDocument(...) and getCollection(...) functions in both firebase and mongo just so I don't accidentally import the wrong thing. I started working on the "About" page. The overall layout is crude, but it should be pretty quick to design.

On second thought, I might refrain from using shadcn's component. Per an issue with radix there's some challenge involved in showing focus rings on radix-ui component. I'm sure there are some workarounds, but I'm inclined to ditch it because of this. Note that I don't think it would be super beneficial at this point to switch from shadcn as a whole.

Todo:

• [x] Fix the icon component on the data grid read buttons.
• [x] Do some research on accessible design regarding focus rings. I was under the impression that having some kind of focus ring would be better, but I'd like to verify that my assumption was correct.

[xNS5]

Reverted the dropdown menu component back to the headless UI component. The devs for the radix-ui library are...surprisingly stubborn when it comes to focus rings on components and that breaks the UI consistency I was going for.

[xNS5]

I'm considering swapping the "Contact" navbar element for a mailto. Implementing my own contact form is something I can do, but for what benefit? It would feel like a more featured application, but ultimately would add more work for me. I could also make the current link a mailto, then create a contact form as a separate feature using something like Emailjs or MailChimp or something.

[xNS5]

Hm, what if I combine both the FAQ and contact pages into one?

[xNS5]

Adding a custom contact form would be a hassle, so I just added the "contact" button to the FAQ with a mailto href. Additionally, I created a redirect in /contact to the FAQ.