Add Node driver#1
Conversation
|
Since |
- copy over from affjax - update URLs and names - add single dep on affjax
prepare-0.15 package set not yet include affjax
- fixing qualified imports - dropping unused imports
| , delete_ | ||
| , patch | ||
| , patch_ | ||
| ) where |
There was a problem hiding this comment.
We may as well export the driver too (so, everything I guess? 😄) - that way it can be passed in explicitly to the functions in -affjax if someone wants to / if something is added there but this isn't updated yet / etc.
There was a problem hiding this comment.
I'm hesitant about doing that because someone might try to use both the node and web drivers in the same code. By not exporting it, it forces them to use this API as is.
There was a problem hiding this comment.
Any updates on this?
There was a problem hiding this comment.
Yeah, I was just revisiting this stuff now actually :) will post more thoughts shortly.
There was a problem hiding this comment.
I don't think that exposing the driver will make it more or less likely that both dependencies end up in a project - it seems just as likely they'd try to import functions from both Affjax.Driver.Node and Affjax.Driver.Web to me?
Exposing the driver also enables extra capabilities - like my suggestion for allowing people to hook into the XHR object in the web case so they can attach event listeners or whatever, by having a method of constructing the driver(s) with extra arguments.
It also might actually make sense for some projects to have both drivers included, if the project has multiple entry points. They could acquire the driver value from a Reader so that part of the codebase can make requests in either context.
I've actually been in a situation exactly like this, where we had an API implementation that was shared between test code and the UI, where the test code would make API calls to set things up for automated browser tests to run against, and then clean up afterwards. Without the ability to pick the driver from the Reader, it would have meant implementing two entirely different types for whether it was the tests or the UI wanting to call the API, and the implementations would have been identical apart from having different imports.
There was a problem hiding this comment.
Ah good points! Ok, I'll export it then.
| - name: Build the project | ||
| run: npm run build | ||
| # - name: Build the project | ||
| # run: npm run build | ||
|
|
||
| - name: Run tests | ||
| run: npm run test | ||
| # - name: Run tests | ||
| # run: npm run test |
There was a problem hiding this comment.
I assume this is intentional in both the driver projects just now, until the core library PR is merged?
There was a problem hiding this comment.
It's intentional due to it calling spago test, which doesn't currently work due to the ESM changes.
2 participants
Description of the change
Copies over
Affjax.pursfrompurescript-affjaxand updates the_ajaxFFI to be Node specific via thexhr2library. See purescript-contrib/purescript-affjax#171Also updates this library to only compile on
0.15.0.Checklist: