Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Rewrite crrri based on EventEmitter - a puppeeter like #28

Closed
2 of 3 tasks
cderv opened this issue Jan 1, 2019 · 6 comments 路 Fixed by #40
Closed
2 of 3 tasks

WIP: Rewrite crrri based on EventEmitter - a puppeeter like #28

cderv opened this issue Jan 1, 2019 · 6 comments 路 Fixed by #40
Assignees
Labels
enhancement New feature or request

Comments

@cderv
Copy link
Collaborator

cderv commented Jan 1, 2019

This issue is there to follow work based on rewriting crrri to change API toward a more puppeeter-like 馃摝 .

This follows and relates to #8, #15, #27 .

The first idea is to have a 馃摝 that do not use promises at all.

The steps are in order :

There is still a choice to make on what features from puppeeter we like included in crri. The puppeeter code is rather complex with a mix between EventEmitter inherited class and use of promises.
This is something to discuss.

@cderv cderv self-assigned this Jan 1, 2019
@cderv cderv added the enhancement New feature or request label Jan 1, 2019
@cderv
Copy link
Collaborator Author

cderv commented Jan 1, 2019

After 1 and 2, we have something that look like this:

  1. Create the connexion to the page directly. CDPSession class will create a websocket connection that will listen to chrome message and
    • emits an error events in case of a message received with an error
    • emits the name of the command sent when it received a message that correspond to the good reception of a command (a message with no error and an id)
    • emits the name of the method received for a message that contains a method.
      These are the three types of message that we can receive from chrome.
  2. Defines every action in chaining using events, based on the previous emission explained above.
  3. send the first command to start the all flow.
devtools::load_all()

work_dir <- chr_new_data_dir()
chrome <- chr_launch(work_dir = work_dir, headless = TRUE)
ws_endpoint <- chr_get_ws_addr(debug_port = 9222, type = 'page')

# connexion to the session using page endpoint
page_session <- CDPSession$new(ws_endpoint)

page_session$once("Runtime.executionContextCreated", function(...) cat("First command passed!"))

page_session$once("Runtime.enable",
                ~ page_session$sendCommand('Page.enable'))
page_session$once("Page.enable",
                ~ page_session$sendCommand('Runtime.addBinding', params = list(name = "pagedownListener")))
page_session$once("Runtime.addBinding",
                ~ page_session$sendCommand('Page.navigate',
                                         params = list(url = "file:///C:/Users/chris/Documents/test.nb.html")))
page_session$once('Page.domContentEventFired',
                ~ page_session$sendCommand('Runtime.evaluate',
                                           params = list(expression = "!!window.PagedPolyfill")
                ))
page_session$once("Runtime.evaluate",
                function(data) if (!isTRUE(data$result$result$value)) {
                    page_session$sendCommand("Page.printToPDF",
                                    params = list(printBackground = TRUE, preferCSSPageSize = TRUE))
})
page_session$once('Runtime.bindingCalled',
                ~ page_session$sendCommand("Page.printToPDF",
                                    params = list(printBackground = TRUE, preferCSSPageSize = TRUE)
                ))
page_session$once("Page.printToPDF",
               function(data) writeBin(jsonlite::base64_dec(data$result$data), "test.pdf"))

# will launch all the registered events in sequence
page_session$sendCommand('Runtime.enable')

@cderv
Copy link
Collaborator Author

cderv commented Mar 1, 2019

Idea: with event emitter API, it would be possible to register some callback for event known as error, like Network.loadingFailed. This way, if this message is received from chrome, we know that something went wrong and we could throw an error or a warning.

@cderv
Copy link
Collaborator Author

cderv commented Mar 4, 2019

Following a discussion on slack, it seems possible to offer several working APIs if we organize things correctly by stage:

  • eventEmitter
  • callbacks
  • promises (modifi茅)

This seems like a very good idea.

@cderv
Copy link
Collaborator Author

cderv commented Apr 14, 2019

This has been going well with #38 and #35. This issue needs to be split in several ideas that we still want to implement and be closed.

@cderv
Copy link
Collaborator Author

cderv commented Apr 21, 2019

This is now handle in #40 and will be closed by the merge I think. Are we ok on this ?

@cderv cderv added this to To Do in New API in CRRRI - toward v0.1.0 via automation Apr 21, 2019
@RLesur
Copy link
Owner

RLesur commented Apr 22, 2019

Sounds good to me

New API in CRRRI - toward v0.1.0 automation moved this from To Do to Done Apr 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

Successfully merging a pull request may close this issue.

2 participants