I have to explain quite often why the _ wildcard is dangerous, as mentioned briefly here. I think a nice entry about this in the website could be a nice pointer to refer newcomers to 😉

You've got a section on the Action pattern, but the Effect pattern is also nice and creates some improved testability. http://reasonableapproximation.net/2019/10/20/the-effect-pattern.html

Also recently discussed on slack at the the sadly transient https://elmlang.slack.com/archives/C0CJ671HU/p1597424308223600

On this page,
http://sporto.github.io/elm-patterns/advanced/pipeline-builder.html
this is given as a defective example:

Ok User
        |> validateEmail user.email
        |> validateName user.name

I think the intention was to have something like this instead:

 Ok User
        |> validateName user.email
        |> validateEmail user.name

Hi!

When modelling an offline-first application, I stumbled twice upon a pattern regarding entities that start with a globally non-unique String ID ("client" entities) that after being stored globally are promoted to "server" entities, which have a globally unique Integer ID provided by the server.

TL;DR: We are modelling an entity that has a state machine with different information in each state, and other information common to all states. We want to enforce the process flow through the states but we also need a way to access the common data regardless of the state, while keeping the internals private to our module. Current patterns in the catalog only solve part of the problem (the closest one being "Process flow using phantom types", so I describe here the problem and the pattern I found:

The problem

This is a process flow I want to be able to restrict:

• Without API interaction, only Client entities can be created.
• The API decoders are the only ones that can create Server entities from Client entities.
• The API accepts only Client entities for creation and only Server entities for modification.

It is a simple state machine:

ClientEntity {id: String} -> ServerEntity {id: Int}

But it has a small peculiarity that makes the pattern "Process flow using phantom types" a bad idea: Some functions are not restricted to a specific state, but act differently on each state.

In my case, client IDs are Strings but server IDs are Integers, but we still need one function to get the ID as string no matter the state.

Anti-patterns

Phantom types

If we try to solve it with phantom types:

type Entity a
    = Entity Id GenericInternals

type alias GenericInternals = { someData: String, ... }

type Id
    = ClientId String
    | ServerId Int

type Client = Client

type Server = Server

we will find out that we need to manage invalid cases in our strict functions, because there is no relationship between the phantom type and our Id type :

insertEntity : Entity Client -> (Entity Server -> msg) -> Cmd msg
insertEntity (Entity id _) msg =
    let
        oldId = case id of
            ServerId id -> -- Invalid case!! An Entity Client should never contain a ServerId!

"Process flow using phantom types" pattern

If we instead try to solve it with "Process flow using phantom types" pattern:

type alias Internals =
    { clientId : String
    , serverId : Int
    ...
    }

type Entity a = Entity Internals

type Client = Client

type Server = Server

Then we can't implement strategy functions (functions that work with all states but differently with each one):

getIdAsString : Entity a -> String
getIdAsString (Entity internals) =
    -- Should we use clientId or serverId??

We should implement a different getId function for each state, so we would be forcing the consumer to store the state of each of the entities itself, thus rendering our phantom type useless or redundant.

Polymorphic type

Finally, if we try to solve it with a polymorphic type:

type Entity a
    = Entity a GenericInternals

type Client = Client String

type Server = Server Int

Then we have no way to access the state-specific internals in strategy functions, like getIdAsString : Entity a -> String, because Elm has no way to infer that a will be Client | Server.

Pattern

We expose the state machine type with all its states. Meanwhile the states, containing both state-specific and state-generic internals, are represented with opaque types:

module Entity exposing (Entity(..), ClientEntity, ServerEntity)

type Entity
    = Client ClientEntity
    | Server ServerEntity


-- Private types

type alias GenericInternals = { someData: String, ... }


-- Opaque types

type ClientEntity = ClientEntity String GenericInternals

type ServerEntity = ServerEntity Int GenericInternals

This allows both generic functions and restricted functions:

getIdAsString : Entity -> String
getIdAsString entity =
    case entity of
        Client (ClientEntity s _) -> s
        Server (ServerEntity i _) -> String.fromInt i

insertEntity : ClientEntity -> (ServerEntity -> msg) -> Cmd msg

Tradeoffs

This pattern forces the consumer to be wrapping and unwrapping the entity in the generic Entity type, depending on which function is being used. This can become tedious, so use it only when the acquired guarantees make this worth it.

This is not meant to be the pattern redaction, I would make a PR for that.
What do you think? Is this problem usual? Do you find the pattern idiomatic? Would you solve it differently?

Thank you for reading this.

The section on Opaque Types http://sporto.github.io/elm-patterns/advanced/opaque-types.html presents them as principally useful for packages. But I think the most useful part of opaque types is making it possible to ensure a representation invariant. For instance, a type SortedList would benefit from being opaque -- if its internals were exposed, user code could modify the underlying representation and break the "sorted" invariant. I think this is more important, for most people, than the package API stability argument.

I wonder if any of these can qualify as pattern

update : Msg -> Model -> Outcome

On phantom types:

activeUsers is a function that only takes all users and returns only active users.

The first "only" should be omitted:

activeUsers is a function that takes all users and returns only active users.

Hi :)

I'm still learning with Elm in Action, and I've only made a learning project so far. So please excuse if this is not a pattern or it's inappropriate. Should this fit, it would make a great addition: "Solving the Boolean Identity Crisis" by Jeremy Fairbank.

It boils down to be more specific about True/False values and only use a Bool when strictly necessary. Else use Types to make code clearer and making sense of "an opaque logic". I applied this to the sound control of to the SpeechSynthesis Web API.

Elm code in Main.elm:

type Msg
    = ...
    ...
    | SetSound Sound

type Sound
    = On
    | Off

type alias Model =
    { ...
    , sound : Sound
      ...
    }

initialModel : Model
initialModel =
    { ...
    , sound = On
      ...
    }

        ...
        , button [ onClick (SetSound On) ] [ text "Sound On" ]
        , button [ onClick (SetSound Off) ] [ text "Sound Off" ]
        ...

update msg model =
    case msg of
        SetSound param ->
            ( model, setSound param)

setSound : Sound -> Cmd Msg
setSound switch =
    case switch of
        On ->
            sound True

        Off ->
            sound False

port sound : Bool -> Cmd msg

JavaScript code in index.html

      ...

      // Pause/Resume Speech Synth API (SetSound On | Off)
      app.ports.sound.subscribe(function (message) {
        synth.cancel();
        if (message == true) {
          synth.resume();
        } else {
          synth.pause();
        }
      });

      ...

I hope this makes sense, and I invite everyone reading this to watch Jeremy's video and rationale. It is amazing.

Should this idea be viable, and if necessary, I could come up with a PR.

Cheers