-
Notifications
You must be signed in to change notification settings - Fork 2
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
request() & pagelessPipe()() #54
Comments
lowercase instead of uppercase? await pipe()(
api('get', 'url'),
map(transform to iterative collection),
// ....
)(page) |
Can the So you can run it by itself without an actual Puppeteer page instance |
What about running API calls from the Puppeteer page via For some web apps, it could be easier to crawl it by running API calls in page, but without request interception to hydrate request headers, it will be difficult, you'll have to scrape data related to the headers of the calls, and attach manually... but could still be easier than going through a complex UI to write an enriched document, when it could be programtically written and submitted in one API call. Note, you can use browser extensions with Puppeteer. Still don't see a concrete case, just abstract reasons |
in consideration of what if chain/pipe, by default, did not have instead there would be a then this framework can grow beyond composing web bots -- they can still be "bots" but they are no longer focused solely on automating browser user usage, you could compose async functionality with synchronous functions edit: edit2: edit3: edit4: edit5: edit6: |
the above would introduce a new BotAction interface with the original BotAction interface that sets page as the first param, maybe called Then the original BotAction interface and many others could drop |
Could do |
it could be a Or maybe pull in the #45 |
Consider having the pipe object set as the first inject, instead of the last, for more precise typing |
In line with #87 architecture discussion for v4, the spread injects array will probably be replaced with a map of some sort that uses 1:1 keys for lookup. The spread array of injects, with the possibility of a pipe value, while supporting both cases (chain vs pipe); it prevents safe typing throughout. Also, there is an implicit dependency on BotAction's that rely on injects: the order for which the injects are declared in the function's parameters. This creates complications for dev's who want to mix and match BotAction's with various injects in a single assembly line of BotAction's, ultimately leading to a bunch of unnecessary wrapper functions that remap injects' order. That said, a final decision has yet to be made. edit: |
api()() is going to be #109 for bot communication therefore, this has to be renamed, perhaps |
Make an API request and return the response
Could potentially make a bot that never interacts with an actual chrome page instance... ie using https://www.reddit.com/dev/api to create a reddit bot
but then it's less about navigating pages, and more about navigating state effected by API calls, functions, etc. Grab data, parse it, make a decision, do something ie make a PUT/POST call to create data in a web app using a publicly shared API.
There is overlap between this and Piping.... not necessarily new stuff entirely. The downside is that you have to create an instance of
page
to inject it so maybe create a pageless pipe? ie:This function would be an Assembly-Line
BotAction
that ignorespage
provided and injectsundefined
forpage
param in assembled BotAction's.Have to be careful with this and not use it with BotAction's that use
page
The text was updated successfully, but these errors were encountered: