feat(dashboard-frontend): only use Lit

[xandervedder]

Removes Angular.

ToDo list:

• Add routing.
• Make authentication work.
• Use Typed Inject for dependency injection. This is not going to work since browsers require a constructor without parameters.
• Migrate home page to Lit.
• Migrate repositories page to Lit.
• Migrate report page to Lit.
• Remove all references to Angular (including old code).
• Add UX fixes in repositories page.
• Add tests (similar to how the report does it).
  • Vitest-browser + playwright.
• Clean up.
• [ ]

Closes #483

[hugo-vrijswijk]

Wow! This is a lot of work 👏. I'm wondering if it makes sense to introduce some sort of static rendering. For instance, the homepage is just static content (except for the user icon if you are logged in). But it still requires loading the entire SPA. If Angular is already being removed, maybe it makes sense to look at something like Astro to statically build as much as possible, and keep Lit for any interactive elements/pages? Astro is build on Vite, so the setup should be similar. It will also pre-render Lit components to speed up page load for users, where possible. It's a different setup, because Astro is not a SPA. Components are dynamic, rather than the entire page

I have experience with this, so if you want to have a call to discuss options or a demo, let me know. Or tell me if you vehemently disagree 😅

[xandervedder]

I like the idea, but I am not sure how much effort it would take to port it to Astro. I see that they have a Lit guide: https://docs.astro.build/en/guides/integrations-guide/lit/. It might be wise to finish up this up first, what do you think?

I'm also going to improve the repositories pages so we can finally release it 😅.

I'm available next friday - for the entire day 😃.

[xandervedder]

Not really ready, but I wanted to see the result on acceptance first 🙂.

It appears I need to fix the conflicts first.

[xandervedder]

@hugo-vrijswijk It's on acceptance now: https://stryker-dashboard-acceptance.azurewebsites.net

It might get overwritten soon though (and yes, I will fix the e2e tests and add the other tests when I figure out how.. :))

[xandervedder]

Noticed a bug when fetching with relative URLs:

[hugo-vrijswijk]

Noticed a bug when fetching with relative URLs:

URL's don't accept relative URL's. You can just use a string instead of URL constructor, or create one with the origin of the current page:

new URL('/api/reports/github/bla/bla/bla', window.location.origin)

Looking at where the error comes from, you could either change packages/common/src/Uri.ts to not use the URL object, or use window.location.origin in packages/website-frontend/src/contract/constants.ts

[hugo-vrijswijk]

Really awesome work! I have some minor code comments. I think we should probably add this extension to the recommended extensions as it caught some bugs (and remove the angular one).

Ive gone through most of the changes. Just not the tests. I think those could use somve love :)

[xandervedder]

Things left to do:

1. Remove defineElement stuff.
2. Add tests (in the same way as the report).
3. Fix the typing output from dts (not sure why it broke in this branch).
4. Fix E2E tests.

---

After that, I'd say we'll be in a pretty good place 😄

[xandervedder]

Still a bit puzzled why expect(true).to.equal(false); is not failing...

[xandervedder]

@hugo-vrijswijk I'm having trouble controlling (or mocking) window.location, do you have any idea how to go about that?

I see that it might be related to how the tests are run in Playwright..

[hugo-vrijswijk]

@hugo-vrijswijk I'm having trouble controlling (or mocking) window.location, do you have any idea how to go about that?

vi.stubGlobal doesn't work? It might be because the tests are actually running in a browser, where window.location is a "special" global (changing it navigates away from the page). But what is it still used for? I thought all API calls could be done with relative url's?

[xandervedder]

For example: to get the current report, the slug is extracted from the URL (report.page.ts). I suppose we could ignore it or make a wrapper around it so I can mock it.

fetch-ing is mockable, so that's not an issue 🙂

[xandervedder]

I'm pretty much done here, but the E2E tests are a bit flaky it seems...

[hugo-vrijswijk]

LGTM! Other than some minor comments. Congratulations on this massive rework 🙏

[xandervedder]

One issue with real-time reporting, I will fix that and after that it will be merged 😄