Make GUI Assignment Builder a plug-and-play component

[AnsonH]

Description

Kris prefers that our GUI Assignment Builder code to behave like a "node module", so that when it is migrated to a new repo, he can simply use a single component (e.g. <GuiAssignmentBuilder />) and it works out of the box.

In other words, we should expose a single component such that all the states and contexts are internal within that component. We should investigate how to make our feature a more plug-and-play manner.

Notes

Currently all styling are performed using Tailwind. However, Kris is reluctant to use Tailwind and he prefers using component libraries (e.g. Mantine, Material UI). We should ask if it's OK for the component to use Tailwind internally, as the consumer of this component may require (not sure, need research) extra set-up.

[AnsonH]

Notes from 2023-01-12 meeting:

Refactoring this system into a plug-and-play package is NOT a must. We should consider the following factors:

• Complexity
  • e.g. If it's strongly coupled with Next.js (e.g. Next.js router params)
• Assumption of project structure
  • e.g. If we're turning console repo into a monorepo using Lerna, then we're making a strong assumption that the future console repo will be also using this tool

[AnsonH]

Marking this as "wontfix" because the GUI Assignment Builder will have a certain level of coupling with the existing console website:

• To make GUI Assignment Builder's design blends in well with the rest of the app, it will share some components with other parts of the app (e.g. input components).
• The GUI Assignment Builder shares the same GraphQL queries/mutations/subscriptions with the existing website

Therefore, the marginal benefit of making this subsystem a plug-and-play component is low. Instead, we can write documentation on how this system is coupled with the existing system and explain its file structure.