Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use template #58

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 17 additions & 13 deletions ampersand-form-view.js
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,12 @@ module.exports = View.extend({
}
},

template: [
'<form>',
'<fieldset data-hook="field-container"></fieldset>',
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used a fieldset, which from what I understand is the most appropriate field container element. Technically you could do without this line and put the data-hook in the <form> (or even leave the hook out because it defaults to the <form> element if no hook is found). And of course this can be overridden when extending the form view or instantiating it (with an option).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm not opposed to a fieldset. i would consider this a breaking change however, as any DOM node type or hierarchy manipulations will impact folks' CSS rules. it may also be a nice addition for some people to have more immediate structure. the counter to this is that it's not strictly necessary/bare-minimum, and is easily overridden with a template

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, particularly the last one. In that case, I can update it to remove the <fieldset> tag and put data-hook="field-container" in the <form> tag.

'</form>'
].join('\n'),

initialize: function(opts) {
opts = opts || {};
this.el = opts.el;
Expand All @@ -50,13 +56,9 @@ module.exports = View.extend({
// add all our fields
(result(opts, 'fields') || result(this, 'fields') || []).forEach(this.addField, this);

if (opts.autoRender) {
this.autoRender = opts.autoRender;
// &-view requires this.template && this.autoRender to be truthy in
// order to autoRender. template doesn't apply to &-form-view, but
// we manually flip the bit to honor autoRender
this.template = opts.template || this.template || true;
}
if (opts.autoRender) this.autoRender = opts.autoRender;

this.template = opts.template || this.template;

if (opts.values) this._startingValues = opts.values;

Expand Down Expand Up @@ -124,7 +126,7 @@ module.exports = View.extend({
},

remove: function () {
this.el.removeEventListener('submit', this.handleSubmit, false);
this.formEl.removeEventListener('submit', this.handleSubmit, false);
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would throw an error if there's ever a case that remove is called before render is called. I'm not sure that would ever occur, but if it's a possibility, this line should be prefixed with this.formEl && ....

this._fieldViewsArray.forEach(function (field) {
field.remove();
});
Expand Down Expand Up @@ -164,11 +166,13 @@ module.exports = View.extend({

render: function () {
if (this.rendered) return;
if (!this.el) {
this.el = document.createElement('form');
}

this.renderWithTemplate(this);

this.formEl = this.query('form') || this.el;

if (this.autoAppend) {
this.fieldContainerEl = this.el.querySelector('[data-hook~=field-container]') || this.el;
this.fieldContainerEl = this.queryByHook('field-container') || this.formEl;
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took the liberty of using this ampersand view convenience method (queryByHook), but I apologize if there was a reason it wasn't used before.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

}
this._fieldViewsArray.forEach(function renderEachField(fV) {
this.renderField(fV, true);
Expand All @@ -183,7 +187,7 @@ module.exports = View.extend({
delete this._startingValues;
}
this.handleSubmit = this.handleSubmit.bind(this);
this.el.addEventListener('submit', this.handleSubmit, false);
this.formEl.addEventListener('submit', this.handleSubmit, false);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i have bias to retaining el vs formEl. programmatically when i reference my form in my app it reads kind of funny to me to do myForm.formEl vs myForm.el. pedantic, surely, but also a major API change that I'm not sure is warranted

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only reason this is necessary is in cases where the root el is not the <form> tag (ie. it's inside a <div>) because the submit event does not get bubbled up beyond the <form>.

When you use your form view in your app, you shouldn't ever need to access .formEl because ampersand-form-view triggers the submit event on the view itself, so you'd listen to formView.on('submit'). If you need to do something with the DOM elements in the form view (say, append them to a container) you can still use formView.el as you normally would. .formEl is just for the HTML submit event.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

understood.

is in cases where the root el is not the

tag

is this case a reality, however? FormView is essentially a wrapper around <form> itself to offer a programatic I/O of FieldValues, despite FieldView instances need not needing to actually be nested inside the <form> heirarchy.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, in my personal case it is: I want to wrap this view in a <div> like I do all my other views, rather than having to have a parent view just to wrap it in a <div>.

But rather than pushing for my personal use-case, I'd suggest that it's more so about allowing the view's template to be customized like other ampersand views (including InputView). By listening to submit events on el, you'd be creating a requirement that the root element of a FormView be a <form>, a philosophy that seems to run counter to what was envisioned for the form view:

the nice thing about that is now we've decoupled <input>s from values. So if you wanted a password from the user, you would have a single "password-view" that actually rendered two s, for password and validation of that password, but ultimately just produced a single value.

So rather than thinking of a "field view" as a single form control, we think of it as a view that's responsible for a certain form value, whatever widget that might be.

Another way of thinking of it would be to use:

this.query('form').addEventListener('submit', this.handleSubmit, false);
this.query('form').removeEventListener('submit', this.handleSubmit, false);

Using this.formEl just caches that DOM query. But again, it's a private variable that would never need to be accessed publicly.

// force `change:valid` to be triggered when `valid === false` post-render,
// despite `valid` not having changed from its default pre-render value of `false`
this.set('valid', null, {silent: true});
Expand Down