consider reducing the amount of kit.E usage. about rod

[ysmood]

Sorry, I don't understand your point. This is just an optional helper, you don't have to use it. If you want to handle error manually you can use something like page.ElementE other then page.Element.
Every function has an "E" suffixed version, which means it will return an error other than panic it.

All those kit.E helpers are inside the same file sugar.go, you don't have to use them.

[ysmood]

We use panic to trade the fluent style of coding:

defer func() {
    err = recover()
}()

page.Element("button").WaitStable().Click()

Versus

el, err := page.ElementE("button")
if err != nil {
    return err
}
err := el.WaitStableE()
if err != nil {
    return err
}
err = el.ClickE()
if err != nil {
    return err
}

You can do both way, but I think anyone call tell which should be the default option for this project 😂

[ysmood]

I think you can guess why it's called sugar.go 😂. I like to use them, but even we remove this file directly it won't affect main functions.

This lib gives you choices, you can choose to use high-level functions or low-level ones. I just think the default name of functions should be more friendly for default usage.

This lib by default drives chrome, panic won't be the performance bottleneck (chrome rpc is), so I think using panic by default is better.

If we let return error value by default, it will be too painful to code. It can double your code easily.

[ysmood]

For me, this is more like a limitation for Golang. I'd like to switch a better language if it comes. But for now, languages like vlang, or Rust is still not practical enough for me to use them in production. If I have time I even want to create my own language to resolve this pain (I already a draft for it 😂).

If you or anyone can find a better solution, I will be glad to upgrade the code. We can keep this ticket open.

[tmc]

I think the fluent style is great at the top level, I was referring to the internal implementation.

[ysmood]

I think I tried my best to avoid using it at all. Currently, the places I use it are here:

Most of them are decoding JSON from chrome, which will be 100% no error if chrome has no fatal bug. If there is an error during decoding it must be some fatal error, I think it's best to use panic.

If you look at the golang source code they also use panic a lot when it's highly possible there will be no error at all.

[ysmood]

I tried my best to remove some kit.E for deferred code here.

Another thing I want to mention is that I will never use panic inside an unattached goroutine. There will be panic, but you will always be able to use defer to recover the error. If there's a panic you can't recover that must be a bug, please report it and I will fix it.

[ysmood]

For now, let's close it. We can reopen it when necessary.