To output a list of data objects of any sort in a table, using Next.js 14 with App routes, and, by my own volition, AGGrid and Tailwind.

The table should allow some cells to have in-cell multiple choice options that are mutually exclusive and guide the user onto the next cell where there is choice after a choice has been made in the current cell.

I had to learn Next.js inc. server-side rendering, AGGrid and TailWind to a certain degree having never looked at them. I felt it better to challenge myself in the problem domain as defined.

And I have had to learn to complete this challenge.

This was pretty simple. It's a bit like Create React App and like what I've tried to do, it tries to organize things in a consistent, usable way for the developer. This is great and I would happily use this over my own pattern.

I appreciated TailWind's atomic solution to styling. Reading the thought processes that led the lead developer on that project to their idea felt very much like a continuation of what I started with a lot of the re-usable stuff I wrote at EY.

Here I had unexpected struggles. Even using button tags inside cells there was no focus on the buttons. No outline, nothing keyboard accessible, not even ghost focus I could activate with the space-bar. Absolutely dead to the keyboard.

Further to this, AGGrid seemed to completely block state update in React. The default state created in a parent loading AGGrid component would persist even after update in the children using the correct state functions. Note, the effect of server-side Next.js components was understood and mitigated.

I decided to use pure JS as a work-around to fix the fields so the first must be selected before the second can be.

• git clone git@github.com:toni-sharpe/learn-next-js.git
• cd learn-next-js
• npm install
• npm run dev
• go to localhost:3000

I chose a simple online array of objects from www.healthit.gov. Then I wrote a bit of code to restrict this set to a few rows and format it to provide "in-cell" choice options as per the task requirements.

HealthIT has been removed so the work now uses a stubbed object

It seems the AGGrid, Tailwind and possibly also Next.js don't come out of the box with easy accessibility. For example, the outline on headers is unusual. Also, focusing on elements within cells was not as simple as expected.

Keyboard accessibility has not been fully implemented in the shared example.

I note that Next.js provides options allowing cache on request or cache on build. This could be combined with preparing data for a specific visualisation (or visualisation type) and with many data sources updating infrequently (for example, WHO, Our World In Data and World Bank sources all update once a year in many cases) such caching can be a big performance boost. Even more so when private caching is considered.

There are various ways the information could be drilled into or aggregated. Making a selection could display more detailed data about that selection, either by introducing new metrics, providing more detail for the current ones and/or presenting deeper statistical analysis. Allowing multiple selections could aggregate the selections before presenting that extra detail and even be toggleable for comparison or summary.

The current solution is built using just a few rows client side. It is acknowledged that there could be many 1000s or more and recognised that Next.js server-side rendering and AGGrid server-side row options would enable the code to be toggled to a more performant position if the data grew in such a way.

Continuing from large data problems, in the same space:

I used the out of the box solutions based on the client stack and didn't touch anything or try to performance optimize. Together the tools used totaled 15mb, 3.3mb transfered and 20s on 3G. This compares to 6.75mb, 850kb and 6.5s for my own site (both run locally, uncached but with data on a separate URL) where my site pages are a lot more complex.

The task wasn't to make it performant and I'm sure there's easy things to change to make it so; and, it would be interesting to see it deployed to see the proper production build sizes.

Performance is a problem I can tackle from SQL to CSS, so I bring real value there.