# ANB SaaS FE/Repo Goals

| Goal | Progress | Ticket |
| -------------------------------------------- | ---------- | ------ |
| [Request For Comments](#rfcs) | Incomplete | |
| [Architecture Decision Records](#adrs) | Incomplete | |
| [File-Based "Routing"](#file-based) | Incomplete | |
| [NX Project Boundaries](#project-boundaries) | Incomplete | |
| [Living Documentation](#living-docs) | Incomplete | |
| [Backstage](#backstage) | Incomplete | |
| [Standalone Components](#standalone) | Incomplete | |

## <a name="rfcs"></a> RFCs

## <a name="adrs"></a> ADRs

## <a name="file-based"></a> File-Based Routing Architecture

File-based routing is used in various meta-frameworks like Svelte, NextJS, Astro, Remix, etc. In these meta-frameworks, your URL is reflective of how your files are saved in your repo, for example if you want your url to be `/foo/bar`, your repo would look like

src
  pages
    foo
      index.js
      bar
        index.js

This also extends to dynamic routes, called slugs. If your URL is dynamic based on some id, `/foo/[id]`, then the filesystem can reflect this

src
  - foo
    index.js
    - [id]
      index.js

While Angular doesn't force developers to do this, from a code structure point-of-view, it's very helpful to make a clear delineation between what a `page` and `component` are in the context of the application - `pages` act as that bridge between your reusable `components` and your service-based business logic, keeping your components more lean:

src
  pages
    foo
      fooHeader
      fooFooter
      bar
  components
    globalHeader
    globalFooter

In the context of ANB Saas, it may be more difficult to determine _where_ a component should live, however, I'd argue that in the long term it'll be more helpful due to the thought process it evokes:

- Unless there's a specific reason to pull the component out, all components can be coupled to the page (`fooHeader` in the example above)
- If we find that we can use that component throughout more of the application (all or some of it), bump it to the shared `components` folder
- Now the transition from client-specific component to SaaS component becomes clearer, as we would only ever pull from a client's shared `component` folder
- If a component _does_ move from client-component to SaaS-component, we could make the original component a passthrough to determine the impact, but still have the client-component (that we know works) as a fallback

As a further example - take the `application-form` page. Currently, we navigate by providing the `id` for the application as a query param: `/application-form?id=<id>`.

## <a name="project-boundaries"></a> NX Project Boundaries

https://nx.dev/core-features/enforce-project-boundaries

NX provides a useful mechanism for declaring what app or libs can consume any given lib. For instance, any app could import `core-frontend`, but we may not want `core-frontend` to have access to `core-api` (and vice versa). This can be handled via `tags`, and updates to our `.eslintrc`

// core-frontend project.json
{
  "tags": ["ui"],
}

// core-api project.json
{
  "tags": ["api"],
}

// gracekennedy/regilife project.json
{
  "tags": ["app"]
}

// eslintrc.json
{
  "sourceTag": "ui",
  "onlyDependOnLibsWithTags": []
},
{
  "sourceTag": "api",
  "onlyDependOnLibsWithTags": []
},
{
  "sourceTag": "app",
  "onlyDependOnLibsWithTags": ["ui", "api"]
},

Now eslint knows that, if a dev tries to import something from `api` into `ui`, it'll throw a linting error saying that's not allowed. But if you're in `gracekennedy` and try to import from either, then you're fine. As we increase clients, and eventually teams, this is a small DX item that could save some potential headaches, as well as showcasing potential dependency issues within our packages - ie, if `api` _is_ used by `ui` and we update these tags, now we have a clear point we need to refactor/discuss.

## <a name="living-docs"></a> READMEs as Living Documentation

## <a name="backstage"></a> Backstage

## <a name="standalone"></a> Standalone Components

Using `standalone: true` in components that can utilize it

## Translations

Could potentially use translation tokens to potentially make re-usable components more extensible.
Switch from functional parameterization to inline-pipe.

## NPM Package Cleanup

Why we got react in here???

## Angular Selector Prefixes

We have `agent` for gracekennedy, but if we plan to expand clients, we should look to make this more robust, ie `gk-agent-*`