![Advanced Elm](https://static.frontendmasters.com/assets/courses/2018-10-18-advanced-elm/thumb.webp)
Check out a free preview of the full Advanced Elm course
The "Questions & Review" Lesson is part of the full, Advanced Elm course featured in this preview video. Here's what you'd learn in this lesson:
A clarification question is asked about the example that was last shown, Richard gives a word of caution about open records, and this section of the course is briefly reviewed.
Transcript from the "Questions & Review" Lesson
[00:00:00]
>> Speaker 1: So if you were to, this seems like it's maybe just a more accurate and concise way, as opposed to creating a type alias for both Preview Article and Full Article, where you would have to repeat stuff like. You know, you'd have the same representation in two different type aliases.
[00:00:21]
>> Richard Feldman: Yeah. Right. So, right, so another way you could do this is you could make two completely different types, you could [INAUDIBLE] pseudotype alias. You could just say, I'm gonna have type four article, type preview article and just keep them completely separate. The assumption here, is that we have some significant chunk of this that we want to reuse in both contacts because it's always going to be the same.
[00:00:39]
And in particular, if you're dealing with decoders on these things, you know that if one changes the other one is gonna change,because the server format is gonna change, like you know the server is going to be maintained the same between both. But it is a good point to make that quite often, and we'll come back to this in a future section, things look similar but are not quite the same.
[00:01:01]
And actually, it can be a better choice to actually duplicate them and make them completely separate, than to try and reuse one it doesn't actually make sense. The really important point to make here is that. Any situation where you find yourself saying, I'm going to use an open record for parameters or I'm going to use an open record for data modeling, there is always an alternative.
[00:01:22]
Like if you're doing for parameters, you can just take a closed record if you wanna give a name or arguments or you could use an opaque type or even just a custom type to maybe disambiguate in a different way and that will definitely work. Also, if you're using for data modelling, you could also use it this way.
[00:01:37]
Just use a custom type instead and that will definitely work as well. And in fact, this is more flexible, using it with an extra type parameter. Gives you the flexibility to make extra info have whatever type you want, not just a record. The reason I mention this is that, I think that the future of open records as a concept nill [ph] has been recently called into question, because it looks like there is a downside when it comes to compiling due web assembly, in terms of how well we can optimize, what we're compiling too.
[00:02:03]
So it'd be really great if we knew that every record had a consistent shape. And we could say, I'm gonna lay out in memory exactly where these bits are, and I can say in field access means go to this offset in memory. Field access for this means goes to this offset in memory.
[00:02:17]
If you have open records, then potentially a function that takes an open record can no longer compile to just one implementation that says always go to this offset in memory. Because depending on what records it accepts, it could potentially need to go to different offsets in memory. So that's the downside that means that, maybe this isn't actually the right solution for the Elms record syntax.
[00:02:35]
And maybe there is some other way that it ought to work and maybe remove open records at least as they exist today as a concept in the language. Now I'm not saying that will or will not happen, nobody really knows that that's going to happen or not. But, I wanna raise i as a red flag to say like, these unintended uses of open records are not guaranteed to be supportive long term and in fact, there's already at least one reason why they might not be.
[00:02:58]
So I'd encourage you, when writing your code, to reach for these other things first. There's always an alternative. Any time you're using an open record for something and I would tend to prefer those things, because there future is a lot more secure than the future of open records, at least the way they're currently implemented.
[00:03:13]
Okay, so to recap, we talked sort off talking about constraint unification and how Elm's type checker goes from going from one type to another possibly more specific type and possibly through a type mismatch. We talked about differences between open and closed records. We talked about the reason that open records exists.
[00:03:34]
And finally, we talked about how to make extensible custom types as alternative data modeling solutions to using open records
Learn Straight from the Experts Who Shape the Modern Web
- In-depth Courses
- Industry Leading Experts
- Learning Paths
- Live Interactive Workshops