Open auphofBSF opened 4 years ago
Hey @auphofBSF, that sounds like a great idea! It makes more sense to publish your library in a new repo, because (a) I want to keep this repo focused on one task and (b) I may not have much time to maintain this repo this year, so getting it stable is a pressing goal for me.
If you name your new library after Puppeteer, I think users will expect you to implement the entire Puppeteer API. That's a lot of work to replicate, plus you'll be on the hook to follow all of the changes that Google's team makes upstream. Best of luck!
@mehaase I have been extensively using the #6 api and will soon move to the #9. I have a number of functional classes providing and implementing more abstract functions, such as keyboard, mouse actions , and more utility functions for finding and focusing, reading or manipulating elements. This results that the end application is very clean and reasonably elegant
By enlarge I have been incorporating functionality from the likes of https://github.com/miyakogi/pyppeteer an unoffical https://github.com/puppeteer/puppeteer port.
Some key benefits are
I feel many of these classes I have created are worth putting up on Github but under what structure, Do we add on to
trio-chrome-devtools-protocol
or create another moduletrio-puppeteer
There are many pro's and con's but I have only implemented a small but to me very useful subset of puppeteerInterested in perspectives from @mehaase or other users or contributers who may have ideas and relevant comments to structure, naming