201–210 of 278 posts
If decoding json in Elm is considered hard, I'd recommend checking out miso ( https://github.com/dmjio/miso ), a Haskell re-implementation of the Elm arch. It has access to mature json libraries like aeson for that sort of thing, along with mature lens libraries for updating your model. Here's an example of decoding json with GHC.Generics using typeclasses. https://github.com/dmjio/miso/blob/master/examples/xhr/Main.…
Earlier quoted context omitted.
Yup. There are a bazillion libraries now trying to pretend to make it look like it's easy to deal with JSON in Elm. An online converter is definitely not something I would advertise for a "production-ready highly productive amazing pragmatic language to be used in a serious company"
For god's sake, Elm is the only language I know that has _an entire book written on how to handle JSON_: https://www.brianthicks.com/post/2017/01/06/announcing-the-j... It's introduction is: "You know how it takes so much effort to produce even the simplest of programs when JSON parsing is involved? Wouldn’t it be nice if you could breeze right on by that step and get on with writing your business logic? This is what…
Great article! I have no experience with Elm but I'm much more likely to try it out now. I'm curious to hear your thoughts on this though: http://reasonablypolymorphic.com/blog/elm-is-wrong
The core complaint is the lack of typeclasses. If your coding style relies heavily on generics, maybe Elm isn't for you.
Earlier quoted context omitted.
Or that the documentation can be improved, or the API could be improved, or a number of other things. But really, JSON encoding/decoding in Elm boils down to specifying what the type of an object's field is. If that is difficult, interfaces and classes must be a nightmare.
Here is what people are comparing it to, in terms of difficulty: json.loads('foo.json') I spent 3 days about 6 months ago, off and on, trying to figure out json decoding in elm, and gave up on the language entirely. It wasn't a matter of simply specifying types. The syntax is confusing the compiler isn't any help. I had very little difficulty working with anything else in Elm, so I think there is a lot of work to be…
And yes, it is. Here is code from my own project:
Json.map3 HintTemplate
(Json.field "ID" Json.int)
(Json.field "Text" Json.string)
(Json.field "Image" Json.string)
Earlier quoted context omitted.
Or that the documentation can be improved, or the API could be improved, or a number of other things. But really, JSON encoding/decoding in Elm boils down to specifying what the type of an object's field is. If that is difficult, interfaces and classes must be a nightmare.
Here is what people are comparing it to, in terms of difficulty: json.loads('foo.json') I spent 3 days about 6 months ago, off and on, trying to figure out json decoding in elm, and gave up on the language entirely. It wasn't a matter of simply specifying types. The syntax is confusing the compiler isn't any help. I had very little difficulty working with anything else in Elm, so I think there is a lot of work to be…
Generate JavaScript with great performance and no runtime exceptions.
Here's a short example in Typescript:
import fetch from "node-fetch"
interface Post {
user_id: number,
id: number,
title: string,
body: string
}
const postUrl = 'https://jsonplaceholder.typicode.com/posts/1'
const show = function(post: Post) {
console.log(post.user_id)
console.log(post.id)
console.log(post.title)
console.log(post.body)
}
function getJSON(): Promise {
return fetch(postUrl).then(x => x.json())
}
getJSON().then(show)
Everything in programming is about tradeoffs. If you don't care about strong type correctness, use something like Typescript. If you do care, Elm is a great choice.
[1]: http://elm-lang.org/
Earlier quoted context omitted.
#[derive(Serialize, Deserialize)] but yeah, same difference.
Ah. That derives both "ToJSON" and "FromJSON", as Aeson calls them. Cool!
Earlier quoted context omitted.
Author here. As I posted in a different reply: JSON decoding is hard relative to what it is like in JavaScript. In your JS code you can just call JSON.parse() and get the corresponding JavaScript object. In Elm, decoding is not nearly as easy as it is in JS because every field must be explicitly converted to an Elm value. Depending on the complexity of your conversion from JSON to Elm value (e.g. whether you are just…
Can you not do the same thing as JSON.parse() in Elm by parsing into an unstructured JSON type?
Earlier quoted context omitted.
> I cannot emphasize enough how much better working with Elm is. >In every single aspect. I just wish that it will get mainstream as soon as possible. I completely agree - I will be a huge benefit to the industry when elm is as common as js. The concepts it introduces, the benefits it shows are all huge. I've been programming a long time, and elm shattered my views of the relationship between a coder and his/her comp…
> I've been programming a long time, and elm shattered my views of the relationship between a coder and his/her compiler. I love Elm as much as the next guy, but be aware that you can get many, if not most, of these same benefits while working in JS if you use Flow.js or Typescript. I prefer Flow because the community is more oriented toward functional programming vs OOP in Typescript, but they're both capable static…
* Lack of purity. You can unintentionally trigger side effects from a function that's a supposed to simply return a value.
function add(x: number, y: number): number {
fireTheMissiles()
return x + y
}
First: > Elm has an incredibly powerful type system Near the end of the article: >Want to decode some JSON? Hard, especially if the JSON is heavily nested and it must be decoded to custom types defined in your application. IMHO the lack of typeclasses/traits is really hurting Elm. Take haskell f.e. {-# LANGUAGE DeriveGeneric #-} import GHC.Generics data Person = Person { name :: Text , age :: Int } deriving (Generic,…
I really wish people would stop spreading the meme that decoding JSON in Elm is "hard". Yes, Haskell allows you to automatically decode/encode datatypes, but this only works in the simplest of cases. For example, if your backend returns a JSON object with snake-cased fields, but your model has camel-cased fields, `instance ToJSON Person` won't work; you'll have to write a custom decoder. The automatic decoders/encode…
For example, here's how you rename a JSON field while serializing/deserializing a data type in Rust:
https://play.rust-lang.org/?gist=1b382bc1572858841d5e392435d...
You just annotate the field with #[serde(rename = "..")]. Here is a list of such annotations
https://serde.rs/field-attrs.html
Serde is also generic in the serialization format; the example I linked uses serde_json, and was adapted from its README here https://github.com/serde-rs/json
Earlier quoted context omitted.
I would disagree strongly with this, but I don't quite know how to put my objection into words. The enforced functional purity, "true" and incredibly friendly compiler, and the robust message system are all things that I don't think you really get in those other languages. To me, it's a bit like saying that you get all the benefits of Haskell in Java, because Java is also statically typed.
Please read my comment again, I said "many if not most" of the benefits. And I was referring specifically to the tire system, not the language as a whole. Listen, I love pure functional languages, but the step up from JavaScript to flow in program correctness is greater than the step up from flow to elm (in my opinion). Flow even has sum types. Have you actually tried flow?