-
Notifications
You must be signed in to change notification settings - Fork 27.5k
support nested forms isolated from parent #10193
Conversation
CLAs look good, thanks! |
|
It is true that is inconsistent in the sense that no descendant inherits the behavior. In the use cases I've found, I only had on level of child forms, and I needed some of them to be isolated (I did it with a custom directive). Should we choose a different attribute name because of this inconsistency or complement the behavior to affect the descendant forms? I think it is not important whether
I'm not sure how to interpret these words. This how it's done most of the times, and even most of the AngularJS tests of |
Sorry, I just meant "doesn't have to", not "mustn't". In my opinion, it's better to choose a different name for the attribute. |
form.$options = $scope.$eval(attrs.ngFormOptions) || {}; | ||
|
||
var parentForm = form.$$parentForm = | ||
(!form.$options.isolated && element.parent().controller('form')) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that isolated
is a bad name, it already has a meaning regarding scopes and would like not to cause any confusion
Hi, thanks for the PR! I can see that this is solving a problem, would it be possible to have the following changes
|
75c719a
to
cca3f39
Compare
@lgalfaso I've added a few more tests to illustrate the complete behavior. |
This looks interesting but the |
Maybe one of these?
Maybe with a 'Form' suffix is more clear, like in rootScope. |
Missing a test for submit event's, which would fail because HTML nested structure would eventually fire a submit event on topmost form (structurally speaking), even from a control inside isolated form. |
RE naming: root and isolate already have other meanings in angular, and this case doesn't not map accurately to those meanings. I would be happy with |
Also drop the So something like: <ng-form ng-form-top-level="true"> |
@awerlang good catch! |
582c576
to
ede8135
Compare
Let's see if we can get this in 1.5 |
Fancy moving this one forward @gkalpak ? |
@petebacondarwin, sure thing ! |
b588a32
to
35d08c8
Compare
@gonzaloruizdevilla I have landed your first two commits to close off their related issues. |
sure, I'll try to find some time tonight |
Child forms propagate always their state to its parent form. A new optional attribute ngFormTopLevel is defined for forms that will allow to define now if the form should be considered as 'top level', therefore preventing the propagation of its state to its parent. I It maybe used like this: <ng:form name="parent"> <ng:form name="child" ng-form-top-level="true"> <input ng:model="modelA" name="inputA"> <input ng:model="modelB" name="inputB"> </ng:form> </ng:form> Closes: angular#5858
35d08c8
to
52535c3
Compare
@@ -497,18 +507,27 @@ var formDirectiveFactory = function(isNgForm) { | |||
event.preventDefault(); | |||
}; | |||
|
|||
var handleKeypress = function(event) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's too simple, see https://docs.angularjs.org/api/ng/directive/form#submitting-a-form-and-preventing-the-default-action
Maybe we should instead listen on the submit event and see if the first parent form of explicitOriginalTarget is 1) not the current submit target and 2) has the do-not-propagate attribute set
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(a) Actually, the whole submit handling seems problematic. In ngForm
, we don't emulate the submit behavior of regular forms. So in order to be able to "submit" a detached form, we would need to emulate the submit behavior (as requested in #2513). The current patch doesn't achieve this, and without it, I am not sure how useful the detached form is.
(b) What's more if you have form (with one input) -> ngForm (with x other inputs), and the ngForm is detached, you could expect that pressing "Enter" on the regular form input submits the form (see above rules), but obviously the browser doesn't know that we have "detached" the ngForm. So either we emulate the behavior for this case (horrible idea), or we advise that if you want to have nested forms with independent submission, you should only use ngForm.
(c) If you don't use form at all however, then you are missing out on other HTML features, such as autocomplete=off.
(d) Mixing ngForm with form gets worse when you have ngForm -> form -> ngForm. Then the event handling gets super complex, because the parent ngForm has no default submission behavior, but the grandchild form does because of its form parent.
(e) There's also the issue with handling the events - if we detect "submission" by listening on Enter, for detached forms, we then have to stop the event propagation to the next form that might also have a submit handler. This doesn't sit well with me, as there might be other code that does stuff with the event. We could try to create a synthetic submit event (that is propagation stopped etc) for this case.
If we have a parent form, then ngForm could theoretically try to listen on the submit even instead, but we'd need to register ours before the one in the form which is currently not possible because that's registered in preLink fn.
Overall, we would need:
- basic requirement: a way to detach a form from its parent form. (Easiest way: simply call $removeControl on the parent), that stops validation, dirtiness, explicit submitted setting etc. from propagating
- a way for ngForm to behave the same way as a form wrt to submission. See https://github.com/MarkPieszak/Angular1-ngForm-ngSubmit-fixes for an incomplete approach. Without this, it's impossible to have child forms that can be submitted individually with ng-submit on ngForm and a submit button, because ngForm does not have a raise a submit event (they could however be submitted with click handlers)
I think that theoretically both of these can be implemnted in user-land. Based on the original thread, it also seems that individual submission is not very important. #5858
form submission tests plnkr:
http://plnkr.co/edit/JARrreaOAg3LWvlVEQ2R?p=preview
I would like to get this in, but I'm not a fan of the ngFormTopLevel attribute. It really doesn't convey what it does very well. I'd prefer something like ng-form-no-parent, or ng-form-no-child, ng-form-detached. |
This is not gonna happen in core due to the reasons outlined in #10193 (comment) |
No description provided.