4 ms·
I've updated a few of my projects to 0.18 over the last couple weeks. The new HTTP library is much better than the one before. Working with Authentication Token
by zalmoxes 10y ago
I've updated a few of my projects to 0.18 over the last couple weeks. The new HTTP library is much better than the one before. Working with Authentication Tokens, decoding errors etc is much easier now.
I also welcome the continuous work to remove things which are difficult for beginners and make code less readable, like the backtick syntax and the prime notation.
I mostly work with backend code, and I wanted to learn some JS but found the ecosystem hard to swallow. Elm offers a very practical, and quick to get started experience for writing reliable frontend. For a quick win with UI work, also check out the Elm-MDL library. https://debois.github.io/elm-mdl/ https://debois.github.io/elm-mdl/
---
Coincidentally, I was watching MPJ's FunFunFunction today, where he talks about JS libraries that coerce HTTP statuses into JS errors, and he managed to articulate some of my frustrations with elm-lang/http. The library tries to be helpful by returning a `BadStatus (Response String)` error if the status is not a 20x code. An error is what I want sometimes, but far from always. The result is also a string, while most of the API's I interact with return JSON for errors.
https://www.youtube.com/watch?v=gRsyY0kzXfw&feature=youtu.be&t=404 https://www.youtube.com/watch?v=gRsyY0kzXfw&feature=youtu.be...
- Skinney 10y agoHttp does allow you to get the raw data and treat it as you will. It also isn't that much code. Check out the custom requests section of the documentation.
- zalmoxes 10y agoRight, I know how to get around this issue when I need to. My point was that the library makes a default assumption which is often enough false. And then I have to change things. Compare this to Go, or even Fetch. You send a request, and you get back a response, with a Body, Headers and Status. A language error type is only expected in case of the request not succeeding, like a timeout. Here, the library makes 2 assumptions. That a non-200 status is an Error, and that the response is a String. These assumptions would be ok in a higher level library someone wanted to build, but as part of a core, they're too high level to work for everyone with the defaults.