Platform.Cmd
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.
Commands
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!
Tell the runtime that there are no commands.
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.