opensource-joe commented on issue #355: URL: https://github.com/apache/fineract-backoffice-ui/issues/355#issuecomment-5305365059
@Aman-Mittal thank you, that split is clearer than what I proposed and the reason for landing one file first makes sense: the cost here is the key naming, not the diff. One thing in your answer I cannot resolve on my own, and I would rather ask than pick. You listed `clients` (21 routes) as PR 1, on its own, **because** it settles the naming convention. Then under what to leave you said to take `products` and `system` and leave `accounting`, `loans`, **`clients`** and the 16 small files as newcomer work, "with the convention already settled by your first PR." If `clients` is left for a newcomer, then my first PR is `products`, and the convention gets settled by a 65-route file rather than the small one you picked for that purpose. If `clients` is mine, then it is not available to a newcomer. Both readings are defensible and they lead to different first PRs. My guess is the first: I take `clients`, `products` and `system`, and `accounting`, `loans` and the 16 small files stay open, since that keeps the convention-setting PR small and still leaves six of the eight pieces for other people. But it is your review time and your contributor queue, so I will do whichever you say, including dropping to just `products` and `system` and leaving `clients` open with the convention written into #355 instead. Either way I will write the two decisions you asked for back into #355 once the first one lands: whether these reuse existing `nav.*` / `FEATURE.TITLE` keys or get new ones, and what `view/:id` and `edit/:id` routes are titled, given Angular's static `title` cannot interpolate the record. And I will leave `products.routes.ts` flat as you asked; the nesting idea is not folded into this. No rush on this one, it is not blocking anything. #354 is up as #365 whenever you get to it. -- 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]
