Front end cleanup

[BCerki]

Description of the Tech Debt

Will have lots of conflicts with #1385 and @joshgamache 's file-moving PR

The Next App router creates makes files routable when they're called route.tsx or page.tsx (https://nextjs.org/docs/app/building-your-application/routing/pages-and-layouts).

Our app has a folder called routes and files called Page.tsx (note the capital) which are not routable, but because the names are so similar to what Next uses, there can be confusion. (Also, older versions of Next used a folder called pages to create routes, so there's a lot of opportunity for naming confusion.)

Suggestions to improve front-end clarity:

For the industry_user roles (files in app/(authenticated)/bceidbusiness):

• [x] Routing is self-documenting (you can look at the file structure to see how to write a URL, things in () are skipped, things in [] are dynamic). We have withAuthorization middleware that cuts off the (authenticated/bceidbudiness/industry_user) bit, so add a section in the developer-guide.md about routing that explains why the frontend URLs look different from the file structure
• [ ] most of the time the [operation] parameter is the operation's UUID, but when a operation is first being created and doesn't have an UUID yet, the url shows the word "create". I find this a little confusing (especially in the frontend files if we use operationId to refer to this parameter), but that would be a huge refactor, so maybe the solution is just to mention this in the routing section of the developer_guide.md
• [x] in the components/routes folder, rename anything called Page.tsx to the name of the React component within it (if component names could be improved, feel free to edit)
• [x] in components/routes, move any form-related components to components/form folder. Note: this change will affect import paths throughout the app, but not any routes, since components were never used for routing
• [ ] rename the routes folder to something else that doesn't imply routing (NOT pages, will interfere with Next's routing/cause confusion). Maybe screens or body or something?
• [ ] move user-operator/[id]/[formSection] (this is the user-operator form) outside of select-operator into the dashboard folder. (Once the user reaches the form, they've already selected their operator; they're now adding or editing it.) Note: this will require updating routes within the app, and a possible way to handle this could be to make a pageRoutes folder like CIF has: https://github.com/bcgov/cas-cif/blob/develop/app/routes/pageRoutes.ts. This change may also require a tweak to the breadcrumbs (could potentially rename user-operator to my-operator)

For the cas roles (files in app/(authenticated)/idir):

• [x] documentation about the URL being cut off by the middleware

Tech Debt Triage

The purpose of our technical debt triage process is to analyze technical debt to determine risk level of the technical debt and the value in tackling that technical debt.

Risk Value Scoring:

Level	Value
High	3
Medium	2
Low	1

Technical Debt - Risk Types	Level	Value
Business Area Risk - Risk of business area visibility / damage to user experience
Developer Fault Risk - How likely will this tech debt cause a future error related to coding on top of it
System Fault Risk - Risk of system errors or application downtime
Time Scale Risk - Compound risk effect if left alone. How much more difficult to fix or dangerous will this become over time?
Time Sink Risk - How much will this tech debt slow the development process down
TOTAL SCORE:

[marcellmueller]

One minor thing I noticed we could clean up is rename OperationsForm to OperationForm to keep consistent with the rest of our application ie: Operations for a dashboard with a list of operations, Operation for a singular operation.

[BCerki]

This is blocked until after Thursday when Josh and Dylan's work goes in

[BCerki]

Much of the frontend will be refactored as part of part 2, so we probably don't need this anymore as discussed in sprint planning