Should we re-export or wrap fantoccini types?

[stevepryde]

Currently we re-export a lot of types from fantoccini, mainly for convenience. This creates coupling, and this issue is about whether we just accept this going forward, or how we go about removing this coupling in future releases.

1. The current situation means a major version bump of fantoccini will require a major version bump of thirtyfour. I'm optimistic that fantoccini will eventually stabilize, at least for version 1.0 of the WebDriver spec, but for the short term I'd expect a bit more churn still to come. And with at least 2 new WebDriver specs/versions coming (2.0 and Bidi), not to mention possible support for Chrome Devtools Protocol (CDP) it's likely we'll see more experimental changes introduced then.

2. Alternatively, we could wrap all fantoccini types in order to guard against such breaking changes, similar to the way fantoccini also wraps types from the webdriver crate, for the same reason. This creates a lot of duplication, to the point of rewriting large chunks of code from fantoccini.

3. There is a hypothetical middle ground, which is to define clear types as API boundaries between fantoccini and thirtyfour (and others, should they exist) and put those in a separate crate, which both fantoccini and thirtyfour can depend on. That crate would then aim to stabilise very early, and avoid breaking changes if at all possible.

4. The only other potential solution I can think of is to proceed with (1) for now, iterating faster in the short term with the goal of reaching (3).

Hoping to get feedback from anyone who uses thirtyfour and wants to use it more in the future

[bcpeinhardt]

Hey there!
Since the collaboration with fantoccini, fantoccini was limited to the W3C webdriver spec if I'm not mistaken. In other words, fantoccini is Rust's unofficial webdriver client. I think with that in mind, it comes down to what you want thirtyfour to be. If thirtyfour is an ergonomic wrapper around WebDriver/Selenium, or aims to transform into officially supported selenium bindings, then I think tight coupling comes with the territory. You would know better than me, but the solution may be to actually have the user import fantoccini and thirtyfour, and sort of openly acknowledge the nature of thirtyfour as an extension of fantoccini, and save the headache of re-exporting anything at all. If however thirtyfour represents a unique approach to web automation, and fantoccini/webdriver isn't the main show so much as a convenient backend for executing commands against, then I think introducing an adapter pattern (likely involving custom types and traits) makes sense, in order to maintain control over decisions about thirtyfour's api and to create the idea of a sort of swap-able backend for thirtyfour. It would indeed be a lot of work.

[stevepryde]

Thanks. That's a pretty good summary of the two options I've been considering. I had wondered whether thirtyfour could simply offer extensions to the fantoccini types via traits etc.

But I ended up leaning more towards the latter option. Whether it's thirtyfour or some other crate, I see a lot more potential for a batteries-included web automation suite and that's more the direction I'd like to go in.

The Component feature I added recently is a glimpse of the kind of things I'd like to add to thirtyfour. So this does suggest that wrapping fantoccini types might be the better path to take. More like option 2 from my original post. It's more work but also more future proof I think.

[bcpeinhardt]

I'd be interested to hear other opinions on this, but it sounds like you've got a plan :)

[stevepryde]

I've decided to remove the dependency on fantoccini and push the project more towards my initial goal, which was to be a batteries-included framework primarily aimed at automated testing of websites.

As of v0.32, thirtyfour will handle all webdriver communications internally.