Note: Gren has managed effects, meaning that things like HTTP requests or writing to disk are all treated as data in Gren. When this data is given to the Gren runtime system, it can do some “query optimization” before actually performing the effect. Perhaps unexpectedly, this managed effects idea is the heart of why Gren is so nice for testing, reuse, reproducibility, etc.

Gren has two kinds of managed effects: commands and subscriptions.


type Cmd msg

A command is a way of telling Gren, “Hey, I want you to do this thing!” So if you want to send an HTTP request, you would need to command Gren to do it. Or if you wanted to ask for geolocation, you would need to command Gren to go get it.

Every Cmd specifies (1) which effects you need access to and (2) the type of messages that will come back into your application.

Note: Do not worry if this seems confusing at first! As with every Gren user ever, commands will make more sense as you work through the Gren Architecture Tutorial and see how they fit into a real application!

none : Cmd msg

Tell the runtime that there are no commands.

batch : Array (Cmd msg) -> Cmd msg

When you need the runtime system to perform a couple commands, you can batch them together. Each is handed to the runtime at the same time, and since each can perform arbitrary operations in the world, there are no ordering guarantees about the results.

Note: Cmd.none and Cmd.batch [ Cmd.none, Cmd.none ] and Cmd.batch [] all do the same thing.

Fancy Stuff

map : (a -> msg) -> Cmd a -> Cmd msg

Transform the messages produced by a command. Very similar to

This is very rarely useful in well-structured Gren code, so definitely read the section on structure in the guide before reaching for this!