Need a way to reset values of form fields

[hwillson]

Migrating over from meteor/meteor#2431 (has a pretty large number of upvotes).

---

(originally reported by @avital)

Say an app has an input field whose value is computed reactively:

<input value={{foo}} />

A user changes the value in the field directly in the browser (so the underlying value computed by {{foo}} hasn't changed). How does one implement a 'cancel' button that reverts the input fields back to their original value?

Since Deps and Blaze treat setting a reactive variable to the same value as a no-op, something like Session.set("foo", Session.get("foo")); won't do anything.

A (pretty bad) workaround for now is something like:

var original = Session.get("foo");
Session.set("foo", original + "--change-it-to-anything-but-the-original-value");
Deps.flush();
Session.set("foo", original);

Maybe we should have an explicit function for "reset form fields under a given DOM element"?

[sbrichardson]

This is better to store on the template instance, we had a small function such as Template.previous = //current/default or null Whenever the input changes, we store the value on template.previous. You can also store it as an array and push into it, then you get multiple levels of undo. This can be written to a generic function so you just enable a key such as saveHistory=true on the component to activate that function or not. This worked well for us. We also can save that array/previous with the document or in a draft version. This worked well when building things like invoices where you may need advanced/history/state

…

On Mon, Dec 12, 2016 at 1:00 PM Hugh Willson ***@***.***> wrote: Migrating over from meteor/meteor#2431 <meteor/meteor#2431> (has a pretty large number of upvotes). ------------------------------ (originally reported by @avital <https://github.com/avital>) Say an app has an input field whose value is computed reactively: <input value={{foo}} /> A user changes the value in the field directly in the browser (so the underlying value computed by {{foo}} hasn't changed). How does one implement a 'cancel' button that reverts the input fields back to their original value? Since Deps and Blaze treat setting a reactive variable to the same value as a no-op, something like Session.set("foo", Session.get("foo")); won't do anything. A (pretty bad) workaround for now is something like: var original = Session.get("foo");Session.set("foo", original + "--change-it-to-anything-but-the-original-value");Deps.flush();Session.set("foo", original); Maybe we should have an explicit function for "reset form fields under a given DOM element"? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#208>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIM6l_WDKYW9WFIUIyY2Ervzr7gfdlUBks5rHaf1gaJpZM4LK9kI> .

[nosizejosh]

I am having a similar issue, lucky to have followed the trail here. please does anyone have a workaround or solution to this?

[nosizejosh]

adding {{#autoForm collection="Activities" id="insertActivityForm" type="insert" doc=defaultValues}} in my case for a form {{> afFieldInput name='orderPrice' readonly=true value=defaultValues}} as suggested by aldeed from this here seems to have solved my problem.

[mitar]

The solution was already mentioned above. You can also check some similar examples in Blaze Components guide. You can implement something similar in pure Blaze as well.

[msavin]

Bump for this 👍

I notice it only happens when you are trying to empty an input and/or set a false-y value on it. Maybe that is causing a re-run to fail somewhere?

[msavin]

I managed to get this working by adding Tracker to the data source underneath the form. It checks over each form element 50ms after the data sources changes, which has generally been enough for the templates to re-render. Just in case the elements are not ready, it would try again after 500ms.

// Sample from Meteor Candy

Tracker.autorun(function () {
	var formInputs = form.inputs.get();

	window.setTimeout(function () {
		formInputs.forEach(function (formInput) {
			var input = "MeteorCandy_form_" + formInput.id;
			var element = document.getElementById(input);

			var runPatch = function () {
				if (formInput.type === "boolean") {
					if (formInput.value === true) {
						element.checked = true;	
					} else {
						element.checked = false;
					}
				} else {
					element.value = formInput.value;
				}
			}
			
			if (element) {
				runPatch()
			} else {
				window.setTimeout(function () {
					console.log("Meteor Candy: ooh, this took unusually long to patch");
					if (element) {
						runPatch()
					}
				}, 500)
			}
		})	
	}, 50)
})

[laddi]

I have to say, this is one of the many reasons people are moving away from Blaze. This handling is plain stupid, why on earth would the rendering engine remove the value attribute from the element and not simply find another way to handle this? Form reset is a fundamental action in HTML, having to create a hack workaround to get that to work correctly in Blaze is a dealbreaker...

[msavin]

Meh, a hack here and there is worth the ease the Blaze provides - but I get you 100%

[laddi]

Blaze has many excellent qualities, I agree. But sorry for the harshness of words, I'm just a bit miffed because I'm running into this very problem with complex forms and I don't find it particularly appealing to create workarounds... 😛

[filipenevola]

I'm closing this issue because it's too old.

If you think this issue is still relevant please open a new one.

Why? We need to pay attention to all the open items so we should keep opened only items where people are involved.