View the static site here.
For the Vital Health API.
Example React App for creating: "New Panels". Panels enable Clients to order groups of Biomarker-tests for Users, using the Vital API Dashboard.
npm installVite on startup will look for a .env.local file in the root directory containing the following environment variables:
# .env.local
VITE_VITAL_LABS_API_URL=https://api.sandbox.eu.tryvital.io/v3/lab_tests/markers
VITE_VITAL_LABS_API_KEY='<Your EU Sandbox Key>'To generate the .env.local file you can run the following:
# Generate .env.local
touch .env.local
echo "VITE_VITAL_LABS_API_URL=https://api.sandbox.eu.tryvital.io/v3/lab_tests/markers\nVITE_VITAL_LABS_API_KEY='<Your EU Sandbox Key>'" > .env.localPlease replace <Your EU Sandbox Key> with a valid key. You can generate required keys on the Vital API Dashboard.
# Start development server
npm run devUses Vite dev server
# Run unit tests
npm testUnit tests are set up with Vitest & React Testing Library.
I normally will aim to test using an outside-in approach following User behaviour. For example:
- User fills out form.
- User submits form.
- Validation is successfull.
- Submit success message is shown.
This ensures business logic is covered without closely tieing tests to implementation details.
This is beneficial if you want to refactor implementation logic later on and usually results fewer tests to maintain.
As I could have carried on working on this (I still have plenty of ideas for further improvements), I aimed to provide the most value in areas that don't currently exist.
I mainly chose to focus on how New Panel creation could work and didn't spend as much time remaking existing features like the 'Your Panels' list.
Due to the lack of a new panel creation endpoint I have done the bare basics & used a little-state-machine client side store to save panels with the following shape:
type Panel = {
panelName: string;
collectionMethod: string;
// Uses slug value at the moment
biomarkers: string[];
};I made the following assumptions:
- The biomarker slug would be adequate as an id for constructing the new panel.
- The back end would assign a unique ID + meta data etc.
- The enpoint would allow for duplicate panel names so didn't add validation for unique name.
Finally in order to view the saved panels list for the test I didn't use the /v3/lab_tests/ endpoint or copy its data structure. This was mainly because trying to mimic the behavior of this not yet existing endpoint didn't seem like a good use of time.
I could have done more rigorous testing & covered more of the App. I've done the bare basic unit tests to cover creating new panels which I feel offer the most value for the time taken.
Given more time I would add more tests around table filtering behaviours & network conditions.
JavaScript build tool (similar to Webpack) that leverages widely supported modern browser features like ES Modules to dramatically simplify and speed up the build & development processes.
Reasoning: Vite appears to be a lot faster and easier to use than Webpack with a lot less configuration required & much faster compilation speeds.
Async state management & data fetching.
Reasoning: Has easy to use handlers for most of the different scenarios during data fetching e.g. retries, caching, request cancellation, pagination & infinite scroll.
I believe for this app you would be able not use client side storage & just use this library.
React component library.
Reasoning: It is already used in the dashboard & made it easier to match my code with current design standards. It also saved a lot of time vs making the components + logic. Finally, it has built in accessibility features which also saved time.
Form Hooks: "Performant, flexible and extensible forms with easy-to-use validation".
Reasoning: Very easy to use and lightweight form hooks. It saved me time working out custom form state logic + validation. It also should be easy to extend in the future if required. Finally, the dev tools are really nice to work with allowing you to see form state with ease.
Table Hooks: "Headless UI for building powerful tables & datagrids".
Reasoning: Very easy to build quite advanced tables with column filters, row selection & pagination. This saved a significant amount of time over manually writing the logic.
Client Side Routing
Reasoning: I didn't spend much time on this but I mainly used it to toggle bettween the PanelsList & NewPanel components. I think the actualy dashboard uses NextJs which would handle routing.
I currently just use a popover:
However, I feel like a confirmation modal would provide a better user experience.
e.g. "Do you wish to Save New Panel <Panel Name>"
The modal would show: Name, Collection Type & Biomarkers.
As we are dealing with abstract concepts a lot e.g. a Panel I think there are a lot of situations where it would be nice to refer users to more information.
For example:
It might be nice UX to have panel as a link to more information or have a tooltip explaining what it is.