No extensible records in Model

[jfmengels]

What the rule should do:

Report when extensible records are used for data. In practice, I think that will mean forbid extensible records used directly or indirectly in Model (and Msg? Elsewhere?).

What problems does it solve:

As Evan Czaplicki once said (as quoted by Richard Feldman in Scaling Elm Apps):

Extensible records are useful to restrict arguments, not for Data modeling.

I find that code using extensible records for their data is often too coupled to where it is used, and a lot of unnecessary fields/values are necessary in places they are not needed.

Example of things the rule would report:

type alias User a = { a | id : UserId, name : String }

type alias Model =
  { user : User { age : Int }
  --       ^^^^
  }

view : Model -> Html msg
view model =
  div [] [ viewUser model.user ]

viewUser : User a -> Html msg
viewUser user =
    text (user.name ++ ": " ++ String.fromInt user.age) ++ " years old")

In this example, User would be reported because we don't want to store it in the model. Here, the id field is defined but not used, but we'll need to create it to be able to create a User.

In practice, I find that User is often defined in a separate module, so as to be able to re-use functions across modules, and that this increases the chance to have unused data (that needs to be fetched, initialized, ...).

Example of things the rule would not report:

type alias User = { name : String, age : Int }

type alias Model =
  { user : User
  }

viewUser : { a | name : String, age : Int } -> Html msg
viewUser user =
    text (user.name ++ ": " ++ String.fromInt user.age) ++ " years old")

type alias User = { name : String, age : Int }

----

type alias Config user =
  { getUserName : { user | name : String } -> String
  }

viewUser : Config user -> user -> Html msg
viewUser config user =
    text (config.getUserName user)

When (not) to enable this rule:

🤷‍♂️

I am looking for:

• Feedback. Is this a reasonable rule? Do you see any unwanted limitations this would create?
• Someone to implement it with/for me
• To know in which package(s) this would fit best