[Code health] Simplify all the things

[gino-m]

Nested calls to subscribe() in ngOnInit, mixing signals + observables, and inconsistent and/or duplicate source-of-truth, and loose separation of concerns have made many of the components hard to grok and maintain. For example:

ground-platform/web/src/app/pages/create-survey/create-survey.component.ts

Lines 155 to 195 in a860c36

	ngOnInit(): void {
	this.subscription.add(
	this.navigationService.getSurveyId$().subscribe(async surveyId => {
	this.surveyId = surveyId ? surveyId : NavigationService.SURVEY_ID_NEW;
	this.surveyService.activateSurvey(this.surveyId);
	await this.draftSurveyService.init(this.surveyId);
	this.draftSurveyService
	.getSurvey$()
	.subscribe(survey => (this.survey = survey));
	})
	);
	this.subscription.add(
	combineLatest([
	this.surveyService.getActiveSurvey$(),
	this.loiService.getLocationsOfInterest$(),
	])
	.pipe(
	filter(
	([survey]) =>
	this.surveyId === NavigationService.SURVEY_ID_NEW ||
	survey.id === this.surveyId
	)
	)
	.subscribe(([survey, lois]) => {
	this.survey = survey;
	if (this.isSetupFinished(this.survey)) {
	this.navigationService.selectSurvey(this.survey.id);
	}
	this.lois = lois;
	if (this.createSurveyPhase === CreateSurveyPhase.LOADING) {
	this.createSurveyPhase = this.getSurveyPhase(survey, lois);
	}
	if (this.createSurveyPhase === CreateSurveyPhase.DEFINE_LOIS) {
	this.canContinue =
	!this.lois.isEmpty() ||
	this.job()?.strategy === DataCollectionStrategy.MIXED;
	}
	})
	);
	}

Assigning this task to myself to come up with a plan to improve maintainability across the codebase.

@rfontanarosa FYI

[gino-m]

@rfontanarosa Some initial thoughts:

• Services need to more fine grained - SurveyRepository, for examples, has too many responsibilities.
• In general, I think we want to split out logic which represents shared global state, perhaps groups by page, eg. SurveyWizardPageService, SurveyEditorPageService, SurveyListPageService, etc. These would also be responsible for loading states and for reloading data based on URL changes.
• The remaining services should basically be basically stateless data repositories, e.g. SurveyMetadataService, SurveyDataService, etc.
• In the process, Observables should be replaces with signals and duplicate states removed.

How we get there:

• Add PageServices with signals for key page states.
• Update components to use those instead of Observable states in SurveyService, etc.
• This will usually mean we don't need separate "container" components, which can be deleted in the process.
• Delete obsolete flows and logic in services.

In the process we would also resolve #1695.

Wdyt?

[gino-m]

After doing more research I'm deleting my previous comment.

Summary of my discussion with Gemini on the subject:

🚀 Angular Router & State Management: The Modern Approach (v16+)

This document summarizes the best practices for handling routing and asynchronous state in modern Angular (v16 and later), focusing on the shift toward decoupled components and the use of Signals.

The core architectural change is driven by the establishment of a clearer relationship between the Router, Components, and Services.

1. The Router-Component Relationship: Decoupled via Inputs

The primary modern pattern eliminates the need for components to manually inject and subscribe to the ActivatedRoute service for parameters.

Enabling Input Binding

In your application configuration, you must enable the feature that binds route data directly to component inputs:

// app.config.ts (or when setting up routing)
import { provideRouter, withComponentInputBinding } from '@angular/router';
// ...

providers: [

provideRouter(routes, withComponentInputBinding()),

]

Reading Parameters in the Component

Once enabled, route parameters (:id), query parameters (?sort), and resolved data are automatically mapped to @Input() properties, decoupling the component from the router's internal APIs.

// product-detail.component.ts - The Component is now Router-Agnostic

import { Component, Input, OnInit, inject } from '@angular/core';

@Component({ ... })

export class ProductDetailComponent implements OnInit {

// 1. The name 'id' automatically receives the value from the ':id' path segment.

@Input() id!: string;
// 2. Query parameters are bound the same way (e.g., /product/123?sort=price)

@Input() sort?: string;
ngOnInit(): void {

// We now have the ID immediately without subscribing to an Observable.

console.log(Product ID: ${this.id}, Sort: ${this.sort});

}

}

2. The Component-Service Relationship: A Clearer Boundary

This change enforces a separation of concerns: Components handle presentation and service initiation, while Services manage data and business logic.

Entity	Primary Responsibility	Data Source
Router	URL path matching and data binding.	Binds parameters to component @input().
Component	Read Inputs, render UI, and trigger service actions.	Gets route parameters via @input().
Service	Centralized business logic and shared state management.	Gets necessary IDs/filters as method arguments from the component.

Anti-Pattern Alert: Services should avoid injecting ActivatedRoute. Route data should be read by the Component and passed to the Service as a method parameter.

3. Asynchronous State Management: Services and Resources (v17+)

Services are the correct place to hold application state, including asynchronous data. The key is using reactive primitives to manage the state lifecycle (loading, error, data).

The resource() Utility

Angular 17+ introduces the experimental resource() utility, which simplifies reactive, signal-based data fetching. It combines the logic for making an async call with the state management boilerplate.

A resource takes an input signal (params) and runs an async loader function whenever that signal changes.

// product.service.ts
import { resource, signal } from '@angular/core';
export class ProductService {

// Use a signal that can be updated from a component method

private currentProductId = signal<string | null>(null);
// The resource automatically manages loading/data/error states

public productResource = resource({

// Reactively derive the loader's input parameter from the signal

params: this.currentProductId,

loader: async (id) => {

if (!id) return null;

const res = await fetch(/api/products/${id});

return res.json();

}

});
// Method called by the Component (which received the ID via @Input)

loadProduct(id: string): void {

this.currentProductId.set(id);

}

}

This pattern centralizes loading, error, and data handling in the service, allowing the component template to display the three possible states (loading(), error(), value()) directly without complex imperative logic.

[gino-m]

@rfontanarosa If you approve, here's how we might get there stepwise:

1. Inject surveyId from the router into MainPageContainerComponent.
2. Propagate the active survey (required) to all descendent components via @Input.
3. Delete the shared activeSurvey$ state in SurveyService.
4. Do the same for other shared states in existing services.

Thoughts?