BREAKING: Improve UX and support multiple pages

[ebebbington]

Why? Sinco only really supported one page, and sometimes it made no sense.. Say you click a link and it opens a new tab, you still only have one 'page' and there's no way to get back to your original page. Some methods (such as click()) were using a hacky approach to get a solution. A lot of properties and methods on classes (internal methods) didnt make sense for them being on those classes

What?

• renamed Client#done to Client#close: await browser.close() > await browser.done()

• Moved a lot from the protocol class to be under the client, as it didnt belong, such as browser process, browser, firefox path

• The client's connection was actually the page's, which makes no sense, so i've made the client class use a separate connection which isn't connected to a page, but can be used for general browser things

• Client#create now returns { browser, page }, it's more semantic for it to be named "browser" instead of client or Sinco, and we know they want to make a page, so we make sure to do that for them here. Whilst a page did open originally, the change here is we create a page instance and attach to it:

  const { browser, page } = await buildFor("chrome")
  await page.cookie(...) // set our auth creds before going to the page, something we couldnt do before
  await page.location("https://my-app.com")
  
  // as opposed to
  const sinco = await ...
  const page = await sinco.goTo(...) // already here, so we have a 403, need to set cookies THEN goto here again

• Support for multiple pages. Whilst you can't directly create a page yourself, if a new tab/page is openedin the browser, a new item gets pushed to Client#pages, which can control that page:

  await page.location() // drash.land
  await page.querySelector(...).click()
  await page.location() // drash.land
  const page2 = await browser.page(2)
  await page2.location() // github.com/drashland

  If any action will open a new page, button: "middle" needs to be passed to click for us to properly handle these different pages

• Can now close a single page

• Can focus a page (but doesnt really do anything)

• Removed waitForPageChange(), instead use .click({}, true)

• Removed selector from takeScreenshot, instead moved this to Element class, so to take a screenshot of an element, you'd call it on the element instead of a page

• The tree is:

  
  --- = one-to-one
  --> or <-- = one to many
              Client
                  |
  Protocol---+--> Page
                             |
                        Protocol

So: client has a protocol, and a client has many pages, and each page has their own protocol

[ebebbington]

I dont want to make another major version, but the internal code and API needed to change

[ebebbington]

and a bunch of QOL stuff for us:

• able to pass in a class to client.close(), for which the error shoudl be thrown with
• a bunch of other stuff i cant remember rn lol

[crookse]

we mixing and matching camel case and snake case object keys 😬 . honestly, i don't know if we should continue to be uniform with these. reason being in the Open API service i'm working on in Drash, Open API Specification uses camel case for object keys, so the Open API service needs to build Open API Specification objects using camel case. kinda sucks, but it killed our uniformity. i know a solution would be to use snake case and then convert all snake case keys to camel case, but that seems unnecessary.

want your thoughts though on if we should continue to enforce snake case in our codebase OR do it based on requirements. like since Open API Specification requires camel case, then the Open API service should use camel case.

[ebebbington]

lets just do snake case all the way