danieloaks / codingtest-birdhouse-admin Goto Github PK

There are a few issues with the way the graph is displayed currently.

For reference, here is the design:

And here is the graph today:

Legend

It'd hard to understand what's the birds and what's the eggs. We should probably display a legend somewhere nearby the graph to help make this easier to understand, since the blue/purple colours aren't used for these values anywhere else on the dashboard.

Timescale

The design shows times from Monday through Sunday. We have a tough time replicating this sort of static scale because of the way that history entries are returned from the API (we need to grab them as pages and can't ensure that each page of states falls within a pretty range). Because pages can be grabbed and displayed arbitrarily, we also can't take that paginated info and force it into a nicer time-delimited structure unless we grab all occupancy history before the graph is displayed.

This is an issue that would be best resolved on the API side.

Ticks

Currently, the ticks on the graph aren't aligned with the very left/right of the edges. This makes our graphs look less clean than they do on the design. This would also mean we don't need to try to add an extra dashed border around the outside, as the ticks will do that for us.

I'll see if we can have these align more nicely, but it may involve some filling gaps of non-existent data or starting/ending the graph before the very start and end points.

If you go to the third page of birdhouses, then click on a birdhouse, then click Back, you're sent back to page 1 of birdhouses. This doesn't feel as nice as it could.

We should push a page query param into our history, then read that when loading the page for the first time.

All the basic features that this project needs to be functional.

• Switching between prod API and localhost API
• Sidebar (done in 422fe3e)
  • Changing icon colours on hover
• Landing page
  • Link to birdhouse list page
• Birdhouse list page
  • Fetching data from API
  • Pagination (done in 6c2bf04)
  • Show occupancy details (extra API calls) (done in 3571828)
• Birdhouse data page
  • Displaying existing birdhouse data (name and geocoords)
  • Fetching data from API
  • Showing new data on Overview page (done in f0a6e7f)
  • Showing new data on Graph page (done in 2762e77)
  • Paginating new data on both pages (done in 87da535)
• Dockerfile (done by 2a55649, multistage added by 8bb7217)
• Docker compose file

Design still needs to check this off, but I'd love a mode where we display all birdhouses on a map and show their location on the birdhouse pages as a map too. Consider this extra credit.

• Enable and disable with an env var, including on the Docker
• Map overview page
  • Grab all data to display on map
• Show small map with geocords plotted or the location as a name on birdhouse specifics page

Since we intentionally don't store state to localStorage, the API data will be refreshed whenever the user refreshes the page. However, it will continue to be stored so long as the user keeps clicking buttons on the site.

Given that registrations and occupancy info will change over time, we should periodically grab new data every e.g. 1-5 minutes. Whenever we time out existing data and grab new info we'll need to ensure that any other entries in the same page map are also scrubbed, so we don't end up in weird cases where we're mixing old paginated info and new paginated info.

Here's how to implement this for each type of data:

---

Paginated Registration info

1. When setting new pages from the API, store a 'first grabbed time' for the paginated registrations and store/update the 'grabbed time' for each item on the page.
2. On future requests:
   a. Check the overall 'first grabbed time', if it's passed then dump the existing store and re-grab pages from the API as needed.
   b. Check the 'grabbed time' for each item on the page, if any are passed then dump the existing store and re-grab pages from the API as needed. This has the upside of forcing new grabs for any existing items (since the reg info for each item is included on new page grabs).

---

Individual Registrations

1. Each time we grab a new registration from the API, we set a 'grabbed time' on it. This is likely already done above, but can also be done in getBaseRegInfo if visiting a single page directly.
2. On future getBaseRegInfo requests, check if the grabbed time is elapsed. If it is, make a new API call to grab registration info and update the grabbed time.

---

Paginated Occupancy info

1. When grabbing new pages from the API, store a 'first grabbed time' for the given bhid's occupancy info.
2. On future requests, check the 'first grabbed time' for the given bhid. If it's passed then dump the existing occupancy store for that bhid and re-grab pages from the API as needed.