Custom Task

[chromedp]

Custom Task

[kenshaw]

Could you provide more information / context on what you're trying to do? Considering that most of the node based actions are built similarly to that, you're probably just missing a small step in how you're executing the action.

[clanstyles]

I'm trying to add the new Action to the tasks to be executed.

tasks := chromedp.Tasks{
    Newaction(),
}

[kenshaw]

Ok. You need to execute those tasks against a running Chrome instance. If you could provide a more complete code sample, I'd be better able to help you figure out whatever the problem(s) is(are).

[clanstyles]

I actually got it working after toying with it a little more. I had an option set for ByID which was bugging it out! The above code should work and did.

This is what I was going to submit, which did end up working and found my bug.

package main

import (
	"context"
	"fmt"
	"log"

	"github.com/knq/chromedp"
	cdp "github.com/knq/chromedp/cdp"
)

func main() {
	c, err := chromedp.New(context.Background())
	if err != nil {
		log.Fatal(err)
	}

	if err := c.Run(context.Background(), Tasks()); err != nil {
		log.Fatal(err)
	}
}

func Tasks() chromedp.Tasks {
	return chromedp.Tasks{
		chromedp.Navigate(`https://www.google.com`),
		chromedp.WaitVisible("#idb", chromedp.ByID),

		NewAction(),
	}
}

func NewAction(opts ...chromedp.QueryOption) chromedp.Action {
	return chromedp.QueryAfter("head", func(ctxt context.Context, h cdp.Handler, nodes ...*cdp.Node) error {
		log.Println("something after happeed")

		if len(nodes) == 0 {
			return fmt.Errorf("not found...")
		}

		return fmt.Errorf("found")
	}, opts...)
}

[clanstyles]

I'm not sure if I should ope another ticket. I want to make this action daisy chain and do other actions based on it being successful. If page has ... then click ... else ignore.

[kenshaw]

Please take a look in sel.go to see the various By* implementations. To use them properly, you need to have a good handle on how their implementations map to the low-level Chrome Debugging Protocol, and in turn how the browser is executing those selector queries. ByID is just a short hand for ByQuery("#"+id), which may / may not be what you actually want to use.

In terms of providing more complex "logic" actions, I've purposely decided not to, because I don't want to end up recreating something like a "DSL" as it seems redundant to me to do so, when you have the flexibility and power of Go at your disposal.

If you need to execute complex logic chains, then the way we are using chromedp on our end looks something like this:

res, err := doChain1(c)
if err != nil { /* ... */  }
 if res == expected {
    err := doChain1SubA(c)
    if err != nil { /* ... */ }   
} else {
    err := doChain1SubB(c)
    if err != nill { /* ... */ }   
}

I realize this may seem strange, but if you wanted to write your own "If/Then" action, you could easily implement it by satisfying the Action interface:

// If executes a, and if a succeeded without error, executes b, otherwise
// executes c.
func If(a, b, c chromedp.Action) chromedp.Action {
    return chromedp.ActionFunc(func(ctxt context.Context, h cdp.Handler) error {
        err := a.Do(ctxt, h)
        if err == nil {
            return b.Do(ctxt, h)
        }
        return c.Do(ctxt, h)
    })
}

I think defining your own simple action helpers like the above is fine, however I do not think actions like these belong in the high level chromedp package. Possibly in the future we might create a separate chromedp/chain that provides "something" like a bunch of helper func's to wrap complex logic into a single action.

However, I'd like to discourage use of the above, because you don't know what failed! Was it the logic chain A, B, or C that failed? If so, which "sub" chain failed? The Action interface can't really change, because it needs to be composable.

Please note the obvious logic problems in the example If above. Please don't use this! It's a horrible way to handle flow control, and if you want to write logic like that, you just end up with gulp style logic chains. This is not the "Go way".

The "right" way is to wrap all your logic into a single "action" which in turn calls sub actions, and propagates a single failure to the top, and having the action itself modify / store results as the chain progresses.