René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"make it easier to access the submitted status of a form","articleBody":"### Which @angular/* package(s) are relevant/related to the feature request?\r\n\r\nforms\r\n\r\n### Description\r\n\r\nSeveral libraries (like ngx-valdemort or angular material) use the `submitted` property of the parent formGroupDirective in order to decide whether or not to display error messages. This works fine as long as the form group directive is only used on the top-level form, and not for nested form groups.\r\n\r\nSee [this working example](https://stackblitz.com/edit/angular-zgmq7p?file=src%2Fapp%2Fform-field-error-example.ts,src%2Fapp%2Fform-field-error-example.html), using formGroupName for the nested form group and [this non-working example](https://stackblitz.com/edit/angular-zgmq7p-2ygua5?file=src%2Fapp%2Fform-field-error-example.ts,src%2Fapp%2Fform-field-error-example.html), using formGroup for the nested form group.\r\n\r\nOne might say that using formGroupName is an easy-enough alternative but\r\n- with typed forms, it's less type-safe\r\n- it is possible, but more complex, to use it from a child component, because it requires a parent formGroupDirective in the same template, unless a view provider is specified for ControlContainer, but that's far from easy to find out, and has its limitations. AFAIK, most people pass the FormGroup as input to the child component, which then uses the formGroup directive.\r\n\r\n### Proposed solution\r\n\r\nThere are several solutions I can see\r\n\r\n1. being able, from the formGroupDirective, to navigate to its parent, recursively, until getting to the top-level one which contains the correct submitted value\r\n2. Add some additional topLevelFormGroup directive, which could use the new directive composition API, and which would get a reference to the formGroupDirective on the same host to give access to it. This TopLevelFormGroupDirective could then be injected in place of the FormGroupDirective to get direct access to the submitted flag\r\n3. Have the formGroupDirective store the submitted flag in its form group, just like it's done for similar flages such as touched, dirty. Since FormGroups do have a reference to their parent, libraries needing to access the submitted property could easily navigate to the top-level directive\r\n4. ???\r\n\r\nThe third solution seems like the most logical to me. It has the additional advantage that it could allow `FormGroup.reset()` to also reset the submitted flag, just as it resets the touched flags.\r\n\r\n\r\n### Alternatives considered\r\n\r\nClearly document that formGroupDirective is only ever supposed to be used for the top-level form (some parts of the doc suggest that, like the documentation of the `path` property of FormGroupDirective, but on the other hands, I've seen many usages of the formGroupDirective in the wild for nested form groups), and clearly document how to best delegate the display of a nested form group to a child component, using `formGroupName`. The best solution I've found is to use the following in the parent component:\r\n\r\n```html\r\n\u003cdiv formGroupName=\"address\"\u003e\r\n  \u003capp-address\u003e\u003c/app-address\u003e\r\n\u003c/div\u003e\r\n```\r\n\r\nand use this in the decorator of the child component to be able to access the parent form group name:\r\n\r\n```ts\r\n  viewProviders: [{ provide: ControlContainer, useExisting: FormGroupName }]\r\n```\r\n\r\nBut this solution isn't without problems. For example: it forces every usage of address to be inside a formGroupName. It can't be used directly under a formGroupDirective. It's also not obvious at all.","author":{"url":"https://github.com/jnizet","@type":"Person","name":"jnizet"},"datePublished":"2022-12-08T13:16:18.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":4},"url":"https://github.com/48402/angular/issues/48402"}