opensource-joe opened a new issue, #355: URL: https://github.com/apache/fineract-backoffice-ui/issues/355
## What is wrong 285 routes across 21 feature route files still inherit their tab title from the section above them, so whole areas of the app share one title. This is the follow-up I offered in [#339](https://github.com/apache/fineract-backoffice-ui/pull/339), which closed #250. That PR added `TranslatedTitleStrategy`, titled the 25 sections in `app.routes.ts`, and refined `groups.routes.ts` as the worked example. Angular's `buildTitle` walks up to the nearest titled ancestor, so every page already has a reasonable title and nothing is broken. But inheritance means every page under a section reads the same: ``` Products · Fineract <- product list Products · Fineract <- create loan product Products · Fineract <- edit charge Products · Fineract <- fixed deposit product detail ``` 65 routes under `products` resolve to that one title. 46 under `system`, 25 under `accounting`, 24 under `loans`. ## Business value The same two reasons #250 gave, neither of which inheritance solves. Back-office work is multi-tab work. Someone comparing two loan products, or checking an accounting rule while editing a charge, has a tab strip that says "Products, Products, Accounting, Products". The title is what makes a tab findable, and at section granularity it is not doing that. Browser history and bookmarks have the same problem: a bookmarked charge screen and a bookmarked product list are indistinguishable in the bookmark list. And the non-visual case from #250 still stands. The document title is announced on navigation and is the main signal that the page changed in a single-page app. Announcing "Products" on every navigation within products is close to announcing nothing: the user learns that they are still where they were, which they knew. ## Finding them Measured against `main` at 98770c4: ``` route files: 23 refined (any title:) 2 app.routes.ts, groups.routes.ts UNREFINED 21 route entries total: 324 route entries in unrefined: 285 ``` ```bash python3 - <<'PY' import pathlib, re PATH, TITLE = re.compile(r"\bpath\s*:"), re.compile(r"\btitle\s*:") for p in sorted(pathlib.Path('src').rglob('*.routes.ts')): s = p.read_text(errors='ignore') n, t = len(PATH.findall(s)), len(TITLE.findall(s)) if n and not t: print('%3d routes %s' % (n, p)) PY ``` Largest first: `products` (65), `system` (46), `accounting` (25), `loans` (24), `clients` (21), `organization` (19), `working-capital` (15), then `campaigns`, `security`, `spm`, `tellers` (7 each), `admin`, `centers`, `transfers` (6), `interop`, `settings` (5), `calendars`, `meetings` (4), `fintech`, `reporting`, `tasks` (2). One correction to my own note in #339: I said 22 route files there. It is 21 against current `main`. ## Scope Add `title:` to the routes in each file, as translation keys, the way `groups.routes.ts` does. `check-translations.mjs` already understands the route-title form, so a wrong key is a build failure rather than a silent fallback. This is deliberately 21 independent pieces of work. No file depends on another, each is small, and each is reviewable on its own, which is what #250 asked for. That also makes it good first-issue material: anyone can take one file without coordinating. So rather than assume it: **would you prefer one PR per feature area, a few grouped PRs, or one PR for all 21?** One PR touching 21 files is a large diff of very repetitive changes, and 21 PRs is a lot of review overhead in the other direction. My guess is that grouping by size, with the four big ones (`products`, `system`, `accounting`, `loans`) separate and the rest together, is the least review burden, but this is your call and I will follow whatever you prefer. I am happy to leave some of these unclaimed for other contributors if you would rather use them that way. Say the word and I will take only the four large ones, or none. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
