Concurrent charm generation for 42 charms #1041
Conversation
support flash-lite
* Only re-render CharmList when connection status actually changes * Update types
| headless: HEADLESS, | ||
| }); | ||
|
|
||
| const scenarioPage = await scenarioBrowser.newPage(); |
There was a problem hiding this comment.
I'm a bit concerned about using multiple tabs for this step - as folks like @ellyxir has already seen timeouts for login / browser flows - due to slowness of access / machine
concurrent generations (happening in deno) seems great - my concern is only browser chonkyness (techinical term)
There was a problem hiding this comment.
The less a browser is used here, the better; maybe can get away with only using a browser for the final rendering/screenshots
| @@ -220,7 +279,11 @@ async function processCommand( | |||
| } | |||
|
|
|||
| function addErrorListeners() { | |||
There was a problem hiding this comment.
I think this can be deleted - as we now use the function that sends the target page
| // FIXME(ja): can we navigate without causing a page reload? | ||
| await page.goto(new URL(`/${name}/${id}`, toolshedUrl).toString()); | ||
| addErrorListeners(); | ||
| await targetPage.goto(new URL(`/${name}/${id}`, toolshedUrl).toString()); |
There was a problem hiding this comment.
perhaps we can fix this? clicking on the space name, then clicking on the charm id - rather than refreshing every single time
we could probably reduce the timeout below
perhaps also we could have iframe emit "loaded" event ? something like "common-iframe-ready" when the inner iframe is done loading (perhaps you and @jsantell can chat about this?)
with both of these the 5 second sleep can go away!
(although we would probably need to rework the error listener work - to not re-add but empty it out after fininshed loading /space)
There was a problem hiding this comment.
<common-iframe-sandbox> emits a "load" event, but does not bubble outside of shadow DOM, though could change. Loading of the iframe document may not necessarily be "loaded" from the perspective of all content in the iframe being initialized as well. May still have race conditions between "no visual representation" (listen to load event) and "load event fired"
Any exposed API here should be on common-iframe rather than common-iframe-sandbox, I think we repropagate some events already there e.g. error/fixit
Also fixed README.