I'm going to do something really different - I'm going to learn a new language in the open, and learn by trying to teach what I've learned step by...
For further actions, you may consider blocking this person and/or reporting abuse
This is awesome stuff, @selbekk ! Really well written :)
I just thought I'd add a small note regarding type vs type alias.
A type alias is just that, an alias. The actual type is what comes after
=
.That means that everywhere you use
Model
in type signatures, you could actually use the record type{ todos: List Todo ... }
instead and it would look the same to the compiler. You're essentially just giving a type another name.type
on the other hand actually creates a new type. So...When it comes to use. Type aliases are often used to shorten types or make them more readable. Records is one example of this, but also:
Ah, that's a really nice way to show the difference between the two! Thanks a ton for taking the time to clarify this - and thanks for all the great work you do with the Elm language.
Why do you write "They're kind of like React components in many ways, but more specialized and less "reusable" by design."
It shouldn't be to hard to create smaller functions that are reusable.
You can create reusable elements in Elm. But when each element needs to carry its own state, and becomes a component, this begins to clash with the Elm architecture.
As everything in Elm is immutable, you end up having to pass state up and down the line from model to component to sub-component and it quickly becomes complex.
Well, the way I've read the docs so far, it sounds to me like Elm promotes longer files and more repetition than reusable components that are split out. At least at first.
I'm sure you could create reusable components views here as well though, I kind of did with the radio with label view business.
Great stuff, thanks for sharing!