purescript-contrib/purescript-affjax

Extract XHR stuff from the project

Opened this issue · 12 comments

garyb commented

Probably could do with free-ifying Affjax itself, or providing a "driver" by some means, so that XHR and node stuff can be supported without resorting to the xhr2 hacks too.

natefaubion commented

Do we need to Freeify it? Couldn't we just have all the functions build AjaxRequest configs, and then you can have different backends provide a way to interpret the AjaxRequest? Seems like Free might add an unnecessary layer since the request config has all the information you need.

garyb commented

Yeah, if we have a config that works too. It doesn't work so well with function like get however... could also be something class based perhaps.

I just meant some way of separating the request mechanism from the higher level interface, in whatever form that takes. There is purescript-affjax-algebra already, so a free version isn't something that would need to live in here.

natefaubion commented

I just meant we already have a config with AffjaxRequest. All the helper functions just modify defaultRequest, and then call affjax. Why do we need them to also call affjax? That's the only thing that ties it to an implementation.

natefaubion commented

It's the same thing with affjax-algebra https://github.com/slamdata/purescript-affjax-algebra/blob/master/src/Network/HTTP/AffjaxF.purs#L41 Why bake in the implementation instead of just building requests and having the user call run for the appropriate driver.

  • 👍1
paluh commented

@garyb, @natefaubion I've just encountered problem related to this xhr check under node with webpack (we are bundling our cli tools into self contained scripts under node) so I want to ask:

  • Do you still plan to abstract over _ajax?
  • Do you have any API proposition which I can try to implement to move away _ajax driver?
natefaubion commented

I'd image that all the functions would just build Requests rather than operating in Aff.

paluh commented

@natefaubion If I understand your suggestion correctly you opt for changing get, post, put etc. into Request constructors. What about functions like request and retry?
@garyb What do you think about this direction?

garyb commented

That sounds like a reasonable approach to me. request is essentially the interpreter for Request, so would be where you'd switch it out to avoid XHR, right?

retry I don't really think belongs in this library at all, since it could be made a little more general and then work for any Aff - I almost removed it in the last update, but thought I'd avoid breaking things any further than was already happening. 😉

garyb commented

Oh yeah, thinking about it, the reason I didn't make this change to free it from XHR in the last release is that I wasn't sure how useful Request is as an abstraction - whether we need to reconsider the options / parameters available to make it more suitable for non-XHR requests, that sort of thing.

paluh commented

request is essentially the interpreter for Request, so would be where you'd switch it out to avoid XHR, right?

Ok. On the other hand request is also where some response parsing "magic" happens.

  • Do we want to move this whole request logic to outside interpreters?

  • What kind of contrib do we want to provide - something like purescript-affjax-node (with let say Affjax.Node module) and purescript-affjax-web?

I wasn't sure how useful Request is as an abstraction (...)

It is hard to tell. Maybe we can leave it as it is till we find any additional scenarios / requirements which we have to cover.

garyb commented

Do we want to move this whole request logic to outside interpreters?

If there's useful stuff that can be shared between request interpreters then we can provide it from this library for sure.

something like purescript-affjax-node (with let say Affjax.Node module) and purescript-affjax-web?

Yeah, I think so - that way we should avoid any possible issues with bundling things.

joopringelberg commented

Apologies for barging in on a discussion I only half understand, with an issue that probably just obliquely touches the subject at hand. I ran into a problem with XHR2 as it doesn't support cookies which makes it impossible to use for Cookie authentication. There is a library based on XHR2 that does support cookies: https://github.com/souldreamer/xhr2-cookies.git. It solves my problem, so may be useful to others, too.