Javascript to Elm
11: Fetch & Decoding JSON Part-1
- Autor: Vários
- Narrador: Vários
- Editora: Podcast
- Duração: 0:28:12
- Mais informações
Informações:
Sinopse
Fetching and Decoding JSON More that just fetch and use! fetch('dataURI') .then(res => res.json()) .then(payload => { alreadyJSObject(payload.coolstuff); }) .catch(err => neverFails(err)) So with that let’s talk about why it’s more effort than that? (Evan’s post) If I change a type, I want the compiler to complain I can pretty much agree with that statement. From someone who had to check if(obj == (NSString *)[NSNull null] || obj.length==0) in objc a grip ton on incoming JSON data, I can appricate the compilers help on this one. I also had to deal with SOAP endpoints without the cover of .NET to help me, so I don’t feel that JSON is bad, it’s better than what we had. But that doesn’t me it’s good, just that it’s better than what we had before. So we’re less worse off?? I would like some sort of contract between clients and servers. If that’s in a .format type file, great! If there’s something else, I’m willing to try it. I can’t think of a good reason a language should inclue in the stlib a p