Closed ntwilson closed 1 year ago
I don't see any problems with adding this. However I'm thinking if we can maybe get better than this? It is ok like it is now if you use fetch directly, but I also noticed that it gets unwieldy if you want to create a function that sets certain parameters.
Thanks! Is there any way I can help? I don't know of a good approach myself to be able to set certain parameters without either using some kind of library for handling optional fields like convertable-options or untagged-union, or else just having a concrete record with a default value defined that you can do an update on. Do you have any ideas how you would want to handle it?
There was another possible use case for fetch
with VTA here: https://github.com/purescript/registry-dev/pull/657#discussion_r1304950084
@pete-murphy thx, just saw it. created #10 , this should fix this, right? @ntwilson @pete-murphy
Sorry for the delay, haven't been doing much Purescript lately. I have drafted a new release v3.0.0. Not sure what is needed nowadays to publish a new release to the registry given that this requires v0.15.10 @thomashoneyman
Seems like this has been closed by #10 right?
This stems from this discussion on Discourse.
Right now it is impossible to call
fetch
with a still-unknown record for the options, even if you copy all the constraints straight fromfetch
. E.g., this will not compile:The trouble is that the compiler can't solve for
thruIn
used byfetch
, because thethruIn
offetch2
isn't known to be the same type asthruIn
forfetch
. When this library gets updated to purescript 0.15.10, would you consider makingthruIn
a target of a visible type application so that this would compile?My understanding is that the visible type application is optional, so if you're applying
fetch
to a real concrete record, you can leave the type application off, and the usage would be unchanged to what it is now.