icefoganalytics / travel-authorization

0 stars 0 forks source link

Simplify and Centralize Travel Authorization Tab (Wizard) Logic #189

Closed klondikemarlen closed 3 months ago

klondikemarlen commented 5 months ago

Relates to:

Context

Is your feature request related to a problem? Please describe.

I have a tab page component that submits a "travel desk travel request", and once submission occurs, it redirects the user the the "read" view of the page. However, this doesn't naturally update the "tab" path, so clicking on the tab would send you back to the "edit" page. One example of a solution is https://github.com/icefoganalytics/travel-authorization/commit/630dcd273997b7509c18d403741cc1bb7d731288.

Note that the https://github.com/icefoganalytics/internal-data-portal/blob/main/web/src/layouts/DatasetLayout.vue in the Internal Data Portal suffers from the same problem.

Describe the solution you'd like

After some consideration, and consulting outside sources, I've determined that I need a better pattern to handle reactive tab logic.

Conclusions:

  1. The tab state is effectively a variation on the "wizard" pattern.
  2. The logic needs to be centralized, so that only one fetch is needed to update the available steps.
  3. The display and business logic should be separated, instead of merged the way the current tab components operate.

Proposed solution:

  1. create a new component location to store wizard type information?
  2. compute all tab content in one location
  3. Use serialized policy logic to determine tab wherever possible
  4. Either use a refresh option for tab state, or watch the route.name and refresh on every route change.