Thanks for finding my blog! I will be using this blog to share examples of everyday issues that I encounter in my position as a remote frontend developer. Hopefully this will give you some insight to my skillset and how I tackle tickets I am given at work. I hope you enjoy reading and feel free to reach out to me if you have any questions or comments!
Recently at work I was assigned a ticket that required me to implement a real time data synchronization feature. This feature would allow users of the Know My Menu app to see the publishing status of a menu in real time. The user story goes something like this: User opens a menu, the MenuPreview component FAB is orange for status 'active'. The user makes an edit to the menu, SWR mutate updates the backend with the edits. Now the user has made changes to the state in the database, but does not know if the live menu is in synch with the backend. The only way they can tell is by clicking the preview menu icon and visually inspecting the menu as changes do not go live until the 'Publish Menu' button has been clicked. The user should know the publishing status of the newly edited menu without having to open and preview the menu. I decided to leverage a combination of React Recoil, SWR, and a simple polling mechanism to keep the UI in sync with the backend. First I instantiated a menuStatus recoil atom to store the publishing status of the menu. I added functionality to the initial SWR fetch of the menu which set the menuStatus Recoil atom after a successful fetch. I subscribed the MenuPreview component to the menuStatus recoil atom. Next I created a color map in the MenuPreview component, mapping the status of the menu to the relevant color...for exaple, if the status was 'publish_failed', the color of the MenuPreview component FAB would change to red. This MenuPreview component was rendered floating over the menu so users can see the menu publishing status at a glance while they are making menu edits. The next step was to add functionality to the publish menu button. I added an onClick attribute to the Publish Menu button that set the recoil atom to the status 'publishing' and the color map changes the color of the MenuPreview component to yellow. The status change set off a polling mechanism in the menu component that polls the back end for menu status as long as the menu status is 'publishing'. As soon as the menu status changes from publishing, the polling stops and the menuStatus recoil atom is updated with the new status. Tthe status has now updated to 'active' and the PreviewIcon changes back to orange. A tooltip was instantiated to show the status on hover in addition to the visual color indication (accessibiity for color impaired...) This was a fun ticket to work on and I learned a lot about Recoil and polling in the process. It would have been much simpler to use swr revalidate onFocus but the requirement was to have the status update in real time and I was instructed by my senior dev to minimize unecessary calls to the backend (i.e no revalidate on focus). I am happy with the solution I came up with and I think it will be a great addition to the app.
My last ticket was to implement Analytics for Know My Menu! The decision to use Matomo was made for its emphasis on user data privacy. The Matomo set up docs were quite comprehensive for React apps. Know My Menu uses Next.js for a framework and most of our content is on the Next.js pages router, so this made the initial set up fairly easy. I added the Matomo script to the _document.js file in the head tag. After setting up the appropriate tag manager triggers we were tracking hits! Pretty straightforward, right? Well, yeah, but we also host some content on the Next.js app router. Unfortunately, Matomo doesn't have documentation for how to integrate with the Next.js app router. Every good developer knows that sometimes documentation comes up short, or doesn't quite fit perfectly. And every good developer also knows that there are a few places online where one can dig into discussions within then developer community, stack overflow is probably the biggest one. I was able to find a github issue that had been opened for this specific issue and leverage the conversation happening in the comments section to find the solution I needed. The solution worked, and I was able to set up analytics on both the app router and pages router sides of Know My Menu. Using site ids for staging and production we are able to track both sites and get all the data we need to make well thought out improvements to the Know My Menu web app!
The essence of the Know My Menu product is that dining out should be easy for everybody regardless of diet preferences or restrictions. At a base level this means that Know My Menu focuses on accessibility for all diners. Thus, making sure the Know My Menu product is accessible to all users is paramount. I was assigned a ticket to make the Know My Menu app more accessible. I started by running an accessibility audit on the app using the Chrome Lighthouse tool and the axe dev tools extension. The audit showed that the app was scoring high, but not accessible to all users. I started by fixing the most critical issues first. I added alt text to all images, aria labels to all interactive elements, focus states to all interactive elements, and made sure everything had a tab index. I added a skip to content link at the top of the page, I added a focus trap to the modal and focus state to the modal. I leaned heavily on a11yproject.com, WCAG, ARIA guidelines, and ADA Section 508 for guidance on how to make the app more accessible. I was able to fix all the critical issues and the app is now more accessible to all users. I am proud of the work I did on this ticket and I am happy to have made the Know My Menu app more accessible.