fix: moved routing components to own high-level folder

[ckbedwell]

Part 1 of addressing: #848

I plan on breaking the above ticket into separate PRs. Because of the nature of the work it is difficult to address up front how many there will be but because each PR will touch many files doing mundane things I intend to silo the work as much as possible to make review and discussion more relevant.

Problem

Addressing how the 'Routing' files are used and referenced as the current place they live is confusing, unintuitive and inconsistent.

Solution

• Move 'Routing' files to their own high-level folder rather than being put in with 'components'
• Add the 'routing' folder to the eslint auto-sorting folder structure
• De-duplicate the utils files related to routing (we had routing/utils and routing/Routing.utils) - create a consistency of <FOLDER_AREA>/utils.ts
• Move TestRouteInfo testing component to the tests folder (all test-related components should be easily discoverable in a single location rather than scattered around)

General

• Change routing imports across files to absolute paths (at the end of the work I intend to add an eslint rule so everything has to be absolute paths)

[w1kman]

IMO it's a bit confusing that SMDatasourceContext will return UninitialisedRouter.
Could we have one AppRouter that controls whether or not the uninitialized/initialized router should be used?

Thought
How about an index.ts file in src/routing to "package" and clean up imports.

src/routing/index.ts

export * from './InitialisedRouter';
export * from './UninitialisedRouter';
export * from './constants';
export * from './LegacyEditRedirect';
export * from './utils';

Example
After

import { InitialisedRouter, generateRoutePath, PLUGIN_URL_PATH } from 'routing`;

Before

import { InitialisedRouter } from 'routing/InitialisedRouter';
import { generateRoutePath } from 'routing/utils';
import { PLUGIN_URL_PATH } from 'routing/constants';

[ckbedwell]

export * from './InitialisedRouter';
export * from './UninitialisedRouter';
export * from './constants';
export * from './LegacyEditRedirect';
export * from './utils';

The issue with this is jest and circular dependencies.

I was in the process of implementing this feedback and then I realised we have enum ROUTES in the global types file and I figured that was a good candidate for creating routing/types.ts file and placing there instead.

But if I export the types through the index too, Jest gets confused and errors out. If the files are imported individually this doesn't happen. We can revisit this in the future. I've had another issue with jest like this and had to make some awful 'temporary' shim.

IMO it's a bit confusing that SMDatasourceContext will return UninitialisedRouter.
Could we have one AppRouter that controls whether or not the uninitialized/initialized router should be used?

The problem with removing this responsibility from SMDatasourceProvider is you end up with the possibility that useSMDatasourceContext would return null or undefined which becomes really annoying. You might have a clearer picture in mind to handle this so we can explore it in another PR.

[VikaCep]

Nice! It makes much more sense to organize the routing files their own folder 👌

[VikaCep]

❤️

[w1kman]

When are we going to address the naming of enums 😁
This enum at least uses PascalCase for keys.

// Bad 
enum AM_I_A_CONST_OR_A_ENUM {
  FOO,
  BAR,
}

// Bad 🤨
enum AM_I_A_CONST_OR_A_ENUM {
  Foo,
  Bar,
}

// Bad 🤨
enum AlmostAnEnum {
  FOO,
  BAR,
}

// Good 💖
enum ClearlyAnEnum {
  Foo,
  Bar,
}

[ckbedwell]

#1008 -- soon, made a ticket so we don't forget :)

[VikaCep]

I like that you moved the routing types away from the huge types.ts file. Is the idea to do this for most components in upcoming PRs?

[ckbedwell]

Yes :D

[w1kman]

🥇 LGTM