Add form APIs about puppeteer HOT 14 CLOSED

"type" is done as

page.focus(selector)
page.type(text)

How does fill differ from setValue? Fill would work on contenteditable?

from puppeteer.

@JoelEinbinder How would you feel about the

page.type(selector, text)

This looks reasonable to me because it's unlikely one would ever use page.type without page.focus in your scenario.

It would also align with api of other similar libraries, e.g. nightmare.js's type

from puppeteer.

As per discussion with @JoelEinbinder and @paulirish:

// We need this FOR SURE:
page.click('#selector');
page.type('#selector', 'heyo')
page.type(Page.FOCUSED_ELEMENT, 'heyo') // type into focused element

// This looks promising:
page.mouse.move(x, y);
page.mouse.press({
  clickCount: 1 // NOONE UNDERSTANDS EXCEPT JOEL
  button: 'right'
});
page.mouse.move(x2, y2);
page.mouse.release('left')

// Some thoughts on touch API which is not ready:
var touch = page.touch.create(x, y);
// var touch2 = page.touch.create(x2, y2);
touch.down();
touch.move();
touch.up();

from puppeteer.

We could do page.submit('name') to submit a form of the given name. This would be a shortcut to executing document.forms[name].submit() in the browser. It would mean the form needs to be named for the quick access, but super useful still. Or if we wanted to be verbose with it due to the limitation on naming page.submitFormByName(<String>).

from puppeteer.

@Garbee the current approach for form submitting would be

page.$('form.thisone', e => e.submit());

I kinda prefer sticking to selectors for grabbing things. (If names were first-class then we'd probably have page.type(inputelementName, 'text'))

I think right now we should skip adding a submit() method just to clarify that there's ZERO magic behind it.

from puppeteer.

Yea, names aren't first-class all the time. Only within the scope of document.forms and then FormNode.elements. Beyond that most of the time they're just another attribute. That's where the more verbose submitFormByName comes in handy, it is clear that the form is named what is provided. No magic and only taking advantage of what the document already provides (even though it admittedly is lesser-used by developers.)

Best avoid introducing names in non-specific methods though, as the name could easily be a custom registered element name with Custom Elements. Then things get murky for people if the method were as simple as submit.

from puppeteer.

I'm unclear if or how this would be different from

page.$('form[name="hello"]', f => f.submit());

Is there magic behavior with names I'm not taking into account?

from puppeteer.

It's not different execution in the end, it's just a cleaner way to handle submitting a form when it is named. It saves developers from constantly needing to write out the lookup and submit execution when writing tests to their web applications primarily. Which can add up to a good chunk of re-use in apps with a lot of forms.

from puppeteer.

I think I'd rather someone write their own helper

function submitForm(name) { page.$('form[name="' + name + '"]', f => f.submit()) }

I see the value in things like nightmare's .check and .uncheck, where it sets the value and dispatches an event quickly. Right now I expect a puppeteer method to send all the proper events and trigger every side effect of a user performing the action. The existence of javascript-only methods would cause me to not trust the api as much, and I'd end up looking at the source code to see if I should be doing a better job. I am probably more paranoid than your average developer though.

Maybe we can have a form helper object that has these methods, and states that it's mission is to work as quickly as possible. Or a separate project that implements the nightmare api.

from puppeteer.

In all of the scenarios we've tried, we didn't have a need for either page.fill or page.setValue. No one is also especially enthusiastic about this api, closing for now.

from puppeteer.

@aslushnikov I agree that page.fill is not really necessary, specially considering that's pretty much what page.type does nowadays. However a different API could make existing code much more concise.

CasperJS for instance, implements these helper methods quite conveniently:

• fill(String selector, Object values, Boolean submit) locates by input name
• fillSelectors(String selector, Object values, Boolean submit) locates by CSS selectors
• fillLabels(String selector, Object values, Boolean submit) locates by input labels
• fillXPath(String selector, Object values, Boolean submit) locates by XPath selector

It abstracts the API interaction needed depending on the element type:

this.fill('form#contact-form', {
  'subject':    'I am watching you',                // Text
  'content':    'So be careful.',                   // Text
  'civility':   'Mr',                               // Radio / Select
  'name':       'Chuck Norris',                     // Text
  'email':      '[email protected]',                 // Text
  'cc':         true,                               // Checkbox
  'attachment': '/Users/chuck/roundhousekick.doc',  // File
}, true);

I'm tempted to overload Page with a custom implementation of these methods, but I was thinking that it could also be beneficial to others if they were part of PPTR core. Is there any interest in this?

from puppeteer.

I'm tempted to overload Page with a custom implementation of these methods, but I was thinking that it could also be beneficial to others if they were part of PPTR core. Is there any interest in this?

@alixaxel thanks for reaching out. I'd rather have these methods as a third-party.

from puppeteer.

@aslushnikov Cool, thanks.

Do you happen to know of any third-party project that demonstrates how to extend PPTR in a good way?

I'm currently doing something like the following, but somehow it feels hackish...

let Super = 'lib/Page';

try {
  new Function('async () => {}')();
} catch (error) {
  Super = `node6/${Super}';
}

Super = require(`puppeteer/${Super}`);

Super.prototype.fill = function (...) {
};

from puppeteer.

I'm currently doing something like the following, but somehow it feels hackish...

@alixaxel indeed, a little hackish. Unfortunately, I can't suggest any nicer approach.

from puppeteer.