refactor(ui): flatten directory structures

[agilgur5]

Motivation

Remove lots of unnecessary nesting

• a folder for a single file or two tends to make things harder to read
  • lots of these were just a single file, where having a directory is redundant
  • some were a TSX file plus an SCSS file, which will be right next to each other in editors as files are sorted alphabetically, so this is not necessary for just two files. some editors will also have icons for different filetypes that make these easy to distinguish as well
  • some were a single file plus a single directory
    • usually an index.ts plus a components/ directory, which sometimes itself only had 1 file or 1 directory in it, so lots of redundant folders
    • some of the nesting was also inconsistent, with non-component util files under components/ and some directories not having a components/ dir etc
• it required a lot of clicks or cds to get anywhere in the UI as there's so much directory nesting without any need for it
  • for instance, the plugin-list component took 3 clicks to get to, even though it's the only real component under plugins/ (plus a routing wrapper)

Have wanted to do this for a while, but it took a solid amount of time and has a sizeable diff. This finally tackles a big chunk of it while there aren't too many other UI changes out to merge conflict

Modifications

Flatten several nested directories

These had several directories under them, now all the files are just under the directory listed without redundant nesting

• api-docs/
• cron-workflows/
• cluster-workflow-templates/
• event-flow/
• event-sources/
• help/
• login/
• modals/
• plugins/
• reports/
• sensors/
• shared/components/
• userinfo/
• workflow-event-bindings/
• workflow-templates/

Move shared hooks into one directory in shared/ dir

• most were in shared/, but one was in shared/components/ (despite not being a component), and another was created in a separate shared/hooks/ dir
  • put them all in shared/ for consistency right now
    • might be good to put them into shared/hooks/, but for now make it consistent at least
      • also might not be necessary since they do all start with use- by convention
  • fix naming of use-local-storage which previously did not use any casing, but should use kebab-case for consistency with the rest of the UI codebase
    • follow-up to feat: allow switching timezone for date rendering. Fixes #3474 #10120

Other misc changes along the way

• rename a few index.tsx to index.ts

  • as they have no JSX, same as the other index.ts files in the codebase
  • plus a few other files like version.tsx -> version.ts etc
    • rewrite this file to a readable function instead of a large one-liner as well
    • plus remove deprecated / non-spec substr function and replace with substring

• rename to api-docs from apiDocs for consistency with the rest of UI codebase

  • i.e. kebab-case file and directory names, not camelCase
  • this isn't a strict JS convention, but is the most commonly used one
    • (whereas there are conventions for classnames, module names, etc)

• use named functions instead of consts assigned to anonymous functions for better debug tracing

  • Follow-up to refactor(ui): use named functions for better tracing #12062, this pretty much covers all the other cases that don't require larger diffs (largely due to indentation changes that would be required)

Verification

yarn build passes

Future Work

1. workflows/ and shared/ still need some more organizing

   • both of these are quite large with many files, so flattening wouldn't be the primary approach here. we probably want directories in a logical way
     • for workflows/, maybe split by pages, the WorkflowDetails page and the WorkflowsList page
     • for shared/, it is currently internally inconsistent as it has a components/ dir and then also components outside of that dir. I made it more consistent, but there's still more to do there.

2. src/app/ also has some unnecessary nesting

   • models/ being outside of app/ is the odd one out; I'd probably move that into shared/ adjacent to shared/services
   • then can flatten a good bit
   • EDIT: Completed in refactor(ui): flatten ui/src/app dir  #13815

3. Add a linter plugin to sort import statements (similar to isort like Python) so I don't keep editing these manually whenever I see them not meeting conventions

   • this is now possible now that we're off deprecated / archived tslint and have up-to-date prettier (i.e. after refactor(deps): migrate from deprecated tslint to eslint #12163 and chore(deps): upgrade prettier from v1.x to v3+  #12290)
   • e.g. https://github.com/trivago/prettier-plugin-sort-imports, https://github.com/import-js/eslint-plugin-import
   • EDIT: Completed in build(ui): automatically sort imports #13813

[agilgur5]

this file got automatically "modified" because it had inconsistent line endings (i.e. LF vs CRLF). otherwise there are no content changes

[isubasinghe]

Tested and works as expected, I don't have any strong opinions but can confirm it is easier to navigate now.

[terrytangyuan]

One concern is that it would be hard to cherry pick UI changes into patch releases.

[agilgur5]

One concern is that it would be hard to cherry pick UI changes into patch releases.

Git picks up on renames, so a change made to a renamed file will be properly cherry-picked into its earlier location.

So the only real difficulties could be when there is a merge conflict with the code changes here -- mostly the import paths -- but a cherry-picked bugfix is unlikely to change an import path, so there's a pretty low chance of conflict as well. If a new file were added, that could make things confusing, but similarly, that is unlikely to happen in a cherry-picked bugfix.
And if all else fails, we could cherry-pick this in as well if we wanted to. So I think that concern has low probability and is relatively straightforward to overcome as well.

Also in general, I don't think we should limit improving tech debt based on what can be cherry-picked, although that is a good consideration to keep in mind.
Notably, linter upgrades such as #12163 / #12290 have significantly higher chances of causing issues with cherry-picking, but we do still make those upgrades. And any actual semantic refactor, style change, or feature also has significantly higher chance of causing issues with cherry-picking too, since the contents actually change -- this change / renames in general are actually one of the lowest chance of causing issues in comparison.

[agilgur5]

but a cherry-picked bugfix is unlikely to change an import path

Fixed a few conflicts, and notably this still stands over a month later, the conflicts were all with features (#12616, #12674) that won't be backported.

I'd like to get this in as it does help with navigating through all the directories quite a bit (it literally makes me more productive). Since that has been approved and I think the one comment has been addressed here -- this doesn't really impact backports as per above -- and on Slack via the release rotation #12592, I'm going to merge this