4 ms·
I love this way of thinking about web application development, and we take a similar approach on my team at work. There are problems though. > When a form is
by yakshaving_jgt 3y ago
I love this way of thinking about web application development, and we take a similar approach on my team at work.
There are problems though.
> When a form is "editable" … I just have that plus button add a query param and use HTTP GET to get a new version of the form with that field added.
I've done this kind of thing before, but the sticking point for me was how this interacted with the history API. If a user visits a form, adds a new field with a GET request, and then uses the browser's back button, where do they end up? Where would they expect to be?
Instead of taking this approach, in some places we've generated a template on the server which matches the inputs that should exist in the form and then used a DOMParser to parse the template from a string.
Here's an example.
;(function() {
var parser = new DOMParser();
var ol = document.getElementById(#{theId});
function addRow() {
var doc = parser.parseFromString(#{blankDateInput}, 'text/html');
var li = document.createElement('li');
var dateInput = doc.querySelector('.date-input');
li.appendChild(dateInput);
ol.appendChild(li);
dateInput.querySelector('input').focus();
}
document.getElementById(#{addRow}).addEventListener('click', addRow);
})();
---
An alternative approach is to just generate more inputs than the user will actually need, and only show the first one. The "button" to add a new field is actually a label connected to a hidden checkbox, and you use a combination of sibling selectors and the :checked pseudo-selector in CSS to show the next input.
You can use the state of each field's adjacent checkbox to decide whether or not the value in the field should be parsed on the server.
- zepolen 3y ago> If a user visits a form, adds a new field with a GET request, and then uses the browser's back button, where do they end up? Where would they expect to be? They end up at the page that they were before, with the state that was there before, as a back button should do. Bonus, they can share the url with anyone and exactly the same form will be displayed. Put that in your javascript pipe and smoke it!
- chrisco255 3y agoI don't know if you know this or not, but you can access the full query parameters from JavaScript and use it to populate form fields just fine.
- yakshaving_jgt 3y agoI don't understand your comment. I thought it was clear from my comment that I'm mindful specifically of not creating unexpected navigation behaviour, as is so common with SPA implementations. Yes, developers should not mess with the history API, and the back button should work as expected. And, a user navigating back and arriving at the same form they were previously viewing minus one input is probably surprising behaviour.
- masswerk 3y agoIs it, though? Adding another sibling to an existing form element is pretty much like hitting RETURN in a text document for a new line or paragraph or list element. What would users expect, when they had opened a new line/paragraph/list element and hit CTRL/Command+Z for "Undo"? I guess, most would expect the state just before opening that new element. (I'd even go as far as to call any alternatives confusing, like reverting the last edit in the previous paragraph, but having the empty new element still hanging around, or progressing multiple state changes back, at once, which should be pretty unexpected. Personally, I'd deem it highly annoying, if an application wouldn't allow me to revert this expansion step, without implicitly changing any previous edits, as well. Mind that adding an element is pretty much a modal barrier in the editing process and not only crucially different from editing text, but also separates editing tasks into "natural" groups. Which is also why we use such grouped actions and elements in form-centric workflows, in the first place.)
- yakshaving_jgt 3y agoAre you suggesting that most internet users expect their browser's back button to behave as an undo button? Because that's not what I think most people think.
- masswerk 3y agoAs in, "back to the state before the last interaction", which is pretty well defined. (If there are clearly grouped interaction with transitions, this may be "back to the state, the last grouped interaction was finished and the current one opened.")