feature/projects-index-state-migration

[Supun-VinodIT]

Description

This PR completes the migration of the Projects Index state from AngularJS to Angular.
The previous implementation relied on an AngularJS state, controller, and template.
As part of the migration effort, I created a new Angular component and moved all
relevant logic, routing, and view behavior into the Angular framework.

I also cleaned up the old AngularJS state by disabling it so that the new Angular
component is now the source of truth for the Projects Index page.

This PR contains only the intended migration files.

Fixes # (issue) N/A

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

1. Starting the frontend application.
2. Logging in with default credentials.
3. Navigating to /projects/<validProjectId> and confirming the page loads.
4. Confirming the Angular component renders correctly.
5. Verifying that the project and unit data appear as expected.
6. Checking the browser console for errors — none found.
7. Confirming that the old AngularJS controller is no longer triggered.

Testing Checklist:

• Tested in latest Chrome
• Tested in latest Safari
• Tested in latest Firefox

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have requested a review

##Screenshots (Evidence)

Screenshot 1 - Projects Index Page Rendering

Shows the page loading at /projects/ with correct layout and navigation. Confirms that the new Angular component is rendering successfully and the user interface is visible.

Screenshot 2 - Console Showing No Errors

Displays the browser’s DevTools Console tab after refreshing the page. Confirms that there are no red errors or warnings related to the migrated component. Only expected optimization warnings from legacy modules are present.

Screenshot 3 - Network Tab Showing Successful API Calls

Shows the DevTools Network tab after page load. Confirms that getProject and getUnit API calls return 200 OK, verifying that project and unit data are loading correctly.

Screenshot 4 - Angular Component Folder Structure

Displays the file explorer in VS Code showing the new Angular component files inside src/app/projects/states/index/. Includes:

• index.component.ts
• index.component.html
• index.component.scss
  Confirms that the migration was scoped and structured correctly.

Screenshot 5 - Routing Configuration

Shows the route definition in app-routing.module.ts for projects/:projectId. Confirms that the new Angular component is registered with Angular Router and replaces the legacy AngularJS state.

How the behaviour can be tested / replicated by others

Anyone reviewing this PR can follow the steps below to confirm the migrated Projects Index state works as expected:

1. Start the frontend application
   Launch the Angular development server using the project’s standard startup command.

2. Sign in using any valid development credentials
   Once the app loads, log in with the default test credentials provided in the project documentation.

3. Navigate to the Projects Index route
   In the browser, go to:

   http://localhost:4200/projects/<validProjectId>
   

   Replace <validProjectId> with a project ID that exists in your local database.

4. Confirm the page renders correctly
   The Projects Index page should load without errors.
   If the user isn’t enrolled in a unit, the “not enrolled” message will appear - this is expected behaviour.

5. Check the browser console
   Open DevTools → Console and refresh the page.
   There should be no red errors.
   Any AngularJS optimisation warnings are normal and unrelated to this migration.

6. Check the Network tab
   Open DevTools → Network and refresh the page.
   API calls such as getProject and getUnit should return successful responses (e.g., 200 OK).

7. Verify routing behaviour

   • A valid project ID should load the Angular component.
   • An invalid project ID should redirect the user to /home.

8. Confirm the old AngularJS controller is no longer used
   The legacy ProjectsIndexStateCtrl should not appear in logs or be triggered during navigation.

[31Husain31]

I've reviewed the code changes and have some feedback:

Amazing things I noticed:

• Really like the proper RxJS patterns with takeUntil for cleanup - good memory management
• Error handling with the isLoading and hasError states is solid
• The switchMap pattern for handling route params is the right approach
• Using OnDestroy to clean up subscriptions properly

Concerns/Questions:

1. Template Issue (High Priority):
   Looking at index.component.html, I see the <ng-template #loadingOrError> is defined twice (lines 37-41 and 42-45). That's going to cause issues. Should probably remove one of those duplicates.

2. UI/UX:
   The new component has a "Complete" button for tasks (completeTask(task)) but I don't see that method implemented in the .ts file. Is that missing or is the template from a different version?
   The new UI looks quite different from the old AngularJS version (which reused units/states/index/index.tpl.html). Was this intentional? Should we keep the same UI for consistency?

3. Service Injection:
   I see you're injecting ProjectService and ListenerService but the ListenerService doesn't seem to be used anywhere in the component. Is that needed?

4. Type Safety:
   project: any and unit: any - could we create proper interfaces for these? Would make the code more maintainable
   Same with the ViewType.PROJECT - good that you're using an enum, but worth checking if project type aligns with what setView expects

5. Empty Observable:
   When there's no valid projectId, you're returning new Subject() but never completing it. Would EMPTY from rxjs be cleaner here?

Minor Issues:

The .scss file is empty - do we need it at all?
The old CoffeeScript controller had roleWhitelist: ['Student', 'Tutor', 'Convenor', 'Admin', 'Auditor'] - how is this being handled in the new Angular routing? Route guards?

[Supun-VinodIT]

I've reviewed the code changes and have some feedback:

Amazing things I noticed:

* Really like the proper RxJS patterns with takeUntil for cleanup - good memory management

* Error handling with the isLoading and hasError states is solid

* The switchMap pattern for handling route params is the right approach

* Using OnDestroy to clean up subscriptions properly

Concerns/Questions:

1. Template Issue (High Priority):
   Looking at index.component.html, I see the <ng-template #loadingOrError> is defined twice (lines 37-41 and 42-45). That's going to cause issues. Should probably remove one of those duplicates.

2. UI/UX:
   The new component has a "Complete" button for tasks (completeTask(task)) but I don't see that method implemented in the .ts file. Is that missing or is the template from a different version?
   The new UI looks quite different from the old AngularJS version (which reused units/states/index/index.tpl.html). Was this intentional? Should we keep the same UI for consistency?

3. Service Injection:
   I see you're injecting ProjectService and ListenerService but the ListenerService doesn't seem to be used anywhere in the component. Is that needed?

4. Type Safety:
   project: any and unit: any - could we create proper interfaces for these? Would make the code more maintainable
   Same with the ViewType.PROJECT - good that you're using an enum, but worth checking if project type aligns with what setView expects

5. Empty Observable:
   When there's no valid projectId, you're returning new Subject() but never completing it. Would EMPTY from rxjs be cleaner here?

Minor Issues:

The .scss file is empty - do we need it at all? The old CoffeeScript controller had roleWhitelist: ['Student', 'Tutor', 'Convenor', 'Admin', 'Auditor'] - how is this being handled in the new Angular routing? Route guards?

Thanks for the detailed reviews I’ve addressed all high‑priority feedback across three commits-
Commit ac72ee0
Restored the original Projects Index migration files.
Commit 838c783

Removed duplicate <ng-template #loadingOrError>

Removed unused ListenerService injection

Added Project and Unit interfaces for type safety

Replaced new Subject() with EMPTY for cleaner observable handling

Removed the unused “Complete” button from the template

Verified ViewType.PROJECT usage aligns with setView() expectations

• Commit 53d99ec (github.com in Bing)

Deleted the empty .scss file since the component has no styles

About roleWhitelist
The legacy controller used roleWhitelist: ['Student', 'Tutor', 'Convenor', 'Admin', 'Auditor'].
In Angular, this is handled via route guards (canActivate).
This component doesn’t own its routing, so once I confirm where the route for ProjectsIndexComponent is registered, I’ll add the equivalent guard with the same roles.

[JeffySam]

PR Review Feedback
What’s looking good

Nice use of RxJS patterns overall — switchMap + takeUntil is the right combo for route-driven streams and cleanup.

Loading/error state handling is clean (isLoading, hasError) and makes the template logic easy to follow.

Good call using OnDestroy for subscription lifecycle management — avoids the “silent leak” issues we’ve seen before.

Generally readable flow: params → fetch → set state. Easy to reason about.

Concerns / Questions

1. Template Issue (High Priority)

Same concern as the other reviewer: in index.component.html the template reference <ng-template #loadingOrError> is declared twice (looks like lines ~37–41 and ~42–45).

That’ll cause confusion / unexpected behavior.

Suggest removing the duplicate and keeping a single source of truth for the loading/error block.

2. UI / UX Consistency

The template shows a “Complete” button calling completeTask(task), but I don’t see that method in the component TS.

Is it missing? Or did the template come from a different revision?

The new UI looks noticeably different than the old AngularJS screen (which reused units/states/index/index.tpl.html).

Was the redesign intentional?

If not, we may want to preserve the existing layout for consistency (especially if users are used to the legacy UI patterns).

3. Service Injection / Unused Dependencies

ProjectService and ListenerService are injected, but ListenerService doesn’t appear to be used.

If it’s not needed, I’d remove it to avoid confusion and keep DI clean.

If it is needed later, maybe add a comment or implement the intended usage so it doesn’t look accidental.

4. Type Safety / Maintainability

project: any and unit: any are a bit risky long-term.

Could we define interfaces (even minimal ones) for Project and Unit?

This would also help prevent template/runtime mismatches.

Also worth verifying ViewType.PROJECT aligns with what setView() expects.

Enum usage is great — just want to confirm the target type matches the service contract.

5. Empty Observable / No Project Id Case

When projectId is invalid/missing, the code returns new Subject().

That subject never completes and is a bit unusual as a “do nothing” return.

Using EMPTY from RxJS would be cleaner and communicates intent better.

Minor / Cleanup Items

.scss file is empty — do we actually need it?

If not, could remove it to reduce noise.

Legacy controller had:

roleWhitelist: ['Student', 'Tutor', 'Convenor', 'Admin', 'Auditor']

How is that enforced now?

Route guard?

Resolver permission check?

Backend enforcement only?

Would be good to document where this is handled so we don’t accidentally drop access control during migration.

[Supun-VinodIT]

PR Review Feedback What’s looking good

Nice use of RxJS patterns overall — switchMap + takeUntil is the right combo for route-driven streams and cleanup.

Loading/error state handling is clean (isLoading, hasError) and makes the template logic easy to follow.

Good call using OnDestroy for subscription lifecycle management — avoids the “silent leak” issues we’ve seen before.

Generally readable flow: params → fetch → set state. Easy to reason about.

Concerns / Questions

1. Template Issue (High Priority)

Same concern as the other reviewer: in index.component.html the template reference <ng-template #loadingOrError> is declared twice (looks like lines ~37–41 and ~42–45).

That’ll cause confusion / unexpected behavior.

Suggest removing the duplicate and keeping a single source of truth for the loading/error block.

2. UI / UX Consistency

The template shows a “Complete” button calling completeTask(task), but I don’t see that method in the component TS.

Is it missing? Or did the template come from a different revision?

The new UI looks noticeably different than the old AngularJS screen (which reused units/states/index/index.tpl.html).

Was the redesign intentional?

If not, we may want to preserve the existing layout for consistency (especially if users are used to the legacy UI patterns).

3. Service Injection / Unused Dependencies

ProjectService and ListenerService are injected, but ListenerService doesn’t appear to be used.

If it’s not needed, I’d remove it to avoid confusion and keep DI clean.

If it is needed later, maybe add a comment or implement the intended usage so it doesn’t look accidental.

4. Type Safety / Maintainability

project: any and unit: any are a bit risky long-term.

Could we define interfaces (even minimal ones) for Project and Unit?

This would also help prevent template/runtime mismatches.

Also worth verifying ViewType.PROJECT aligns with what setView() expects.

Enum usage is great — just want to confirm the target type matches the service contract.

5. Empty Observable / No Project Id Case

When projectId is invalid/missing, the code returns new Subject().

That subject never completes and is a bit unusual as a “do nothing” return.

Using EMPTY from RxJS would be cleaner and communicates intent better.

Minor / Cleanup Items

.scss file is empty — do we actually need it?

If not, could remove it to reduce noise.

Legacy controller had:

roleWhitelist: ['Student', 'Tutor', 'Convenor', 'Admin', 'Auditor']

How is that enforced now?

Route guard?

Resolver permission check?

Backend enforcement only?

Would be good to document where this is handled so we don’t accidentally drop access control during migration.

Thanks for the detailed review I’ve gone through each point and applied the required changes
Template Issue
The duplicate <ng-template #loadingOrError> block has been removed.
There is now a single, consistent loading/error template.
UI / UX Consistency
The “Complete” button was left over from an older revision and wasn’t part of the AngularJS version.
It has been removed to keep the UI consistent with the legacy screen.
Service Injection
ListenerService wasn’t being used, so I removed it to keep the DI clean and avoid confusion.
Type Safety
Added minimal Project and Unit interfaces to replace the previous any types.
Also confirmed that ViewType.PROJECT aligns correctly with what setView() expects.
Empty Observable Case
Replaced new Subject() with EMPTY for a cleaner and more intentional “no projectId” fallback.
Cleanup
The empty .scss file has been deleted since the component doesn’t use any styles.
Legacy roleWhitelist
The old CoffeeScript controller used: ['Student', 'Tutor', 'Convenor', 'Admin', 'Auditor']
In Angular, this is handled through route guards (canActivate).
This component doesn’t own its routing, so once I confirm where the route for ProjectsIndexComponent is registered, I’ll add the equivalent guard with the same role restrictions.