BackendTasks.Note that in order for this style to be usable, you'll need to use a special formatting script that allows you to use continuation style syntax without indenting each level in the continuation.
It is a bit advanced and cumbersome, so beware before committing to this style. That said, here is a script you can use to apply continuation-style formatting to your Elm code:
https://gist.github.com/xarvh/1b65cb00e7240f1ccfa0bdbf30f97c62
You can see more discussion of continuation style in Elm in this Discourse post: https://discourse.elm-lang.org/t/experimental-json-decoding-api/2121.
Same as do, but with a shorthand to call BackendTask.allowFatal on it.
import BackendTask exposing (BackendTask)
import FatalError exposing (FatalError)
import BackendTask.File as BackendTask.File
import BackendTask.Do exposing (allowFatal, do)
example : BackendTask FatalError ()
example =
do (BackendTask.File.rawFile "post-1.md" |> BackendTask.allowFatal) <|
\post1 ->
allowFatal (BackendTask.File.rawFile "post-2.md") <|
\post2 ->
Script.log (post1 ++ "\n\n" ++ post2)do is also helpful for building your own continuation-style utilities. For example, here is how glob is defined:
glob : String -> (List String -> BackendTask FatalError a) -> BackendTask FatalError a
glob pattern =
do <| Glob.fromString patternTo define helpers that have no resulting value, it is still useful to have an argument of () to allow the code formatter to
recognize it as a continuation chain.
sh :
String
-> List String
-> (() -> BackendTask FatalError b)
-> BackendTask FatalError b
sh command args =
do <| Shell.sh command argsA BackendTask that does nothing. Defined as BackendTask.succeed ().
It's a useful shorthand for when you want to end a continuation chain.
example : BackendTask FatalError ()
example =
exec "ls" [ "-l" ] <|
\() ->
log "Hello, world!" <|
\() ->
noopA do-style helper for Script.exec.
A do-style helper for Script.command.
A continuation-style helper for Glob.fromString.
In a shell script, you can think of this as a stand-in for globbing files directly within a command. The BackendTask.Stream.command
which lets you run shell commands sanitizes and escapes all arguments passed, and does not do glob expansion, so this is helpful for translating
a shell script to Elm.
This example passes a list of matching file paths along to an rm -f command.
example : BackendTask FatalError ()
example =
glob "src/**/*.elm" <|
\elmFiles ->
log ("Going to delete " ++ String.fromInt (List.length elmFiles) ++ " Elm files") <|
\() ->
exec "rm" ("-f" :: elmFiles) <|
\() ->
noopA do-style helper for Script.log.
example : BackendTask FatalError ()
example =
log "Starting script..." <|
\() ->
-- ...
log "Done!" <|
\() ->
noopA do-style helper for Env.expect.
example : BackendTask FatalError ()
example =
env "API_KEY" <|
\apiKey ->
allowFatal (apiRequest apiKey) <|
\() ->
noopcheckCompilationInDir : String -> BackendTask FatalError ()
checkCompilationInDir dir =
glob (dir ++ "/**/*.elm") <|
\elmFiles ->
each elmFiles
(\elmFile ->
Shell.sh "elm" [ "make", elmFile, "--output", "/dev/null" ]
|> BackendTask.quiet
)
<|
\_ ->
noopA do-style helper for BackendTask.failIf.
Use any
BackendTaskinto a continuation-style task.