elm-pages 3.0.0-beta.13 → 3.0.0-beta.14

package/src/{DataSource.elm → BackendTask.elm}

@@ -1,31 +1,32 @@
-module DataSource exposing
-    ( DataSource
+module BackendTask exposing
+    ( BackendTask
     , map, succeed, fail
     , fromResult
     , andThen, resolve, combine
     , andMap
     , map2, map3, map4, map5, map6, map7, map8, map9
+    , catch, throw, mapError, onError, toResult
     )
 
-{-| In an `elm-pages` app, each Route Module can define a value `data` which is a `DataSource` that will be resolved **before** `init` is called. That means it is also available
+{-| In an `elm-pages` app, each Route Module can define a value `data` which is a `BackendTask` that will be resolved **before** `init` is called. That means it is also available
 when the page's HTML is pre-rendered during the build step. You can also access the resolved data in `head` to use it for the page's SEO meta tags.
 
-A `DataSource` lets you pull in data from:
+A `BackendTask` lets you pull in data from:
 
-  - Local files ([`DataSource.File`](DataSource-File))
-  - HTTP requests ([`DataSource.Http`](DataSource-Http))
-  - Globs, i.e. listing out local files based on a pattern like `content/*.txt` ([`DataSource.Glob`](DataSource-Glob))
-  - Ports, i.e. getting JSON data from running custom NodeJS, similar to a port in a vanilla Elm app except run at build-time in NodeJS, rather than at run-time in the browser ([`DataSource.Port`](DataSource-Port))
-  - Hardcoded data (`DataSource.succeed "Hello!"`)
-  - Or any combination of the above, using `DataSource.map2`, `DataSource.andThen`, or other combining/continuing helpers from this module
+  - Local files ([`BackendTask.File`](BackendTask-File))
+  - HTTP requests ([`BackendTask.Http`](BackendTask-Http))
+  - Globs, i.e. listing out local files based on a pattern like `content/*.txt` ([`BackendTask.Glob`](BackendTask-Glob))
+  - Ports, i.e. getting JSON data from running custom NodeJS, similar to a port in a vanilla Elm app except run at build-time in NodeJS, rather than at run-time in the browser ([`BackendTask.Port`](BackendTask-Port))
+  - Hardcoded data (`BackendTask.succeed "Hello!"`)
+  - Or any combination of the above, using `BackendTask.map2`, `BackendTask.andThen`, or other combining/continuing helpers from this module
 
 
-## DataSource's vs. Effect's/Cmd's
+## BackendTask's vs. Effect's/Cmd's
 
-DataSource's are always resolved before the page is rendered and sent to the browser. A DataSource is never executed
-in the Browser. Instead, the resolved data from the DataSource is passed down to the Browser - it has been resolved
+BackendTask's are always resolved before the page is rendered and sent to the browser. A BackendTask is never executed
+in the Browser. Instead, the resolved data from the BackendTask is passed down to the Browser - it has been resolved
 before any client-side JavaScript ever executes. In the case of a pre-rendered route, this is during the CLI build phase,
-and for server-rendered routes its DataSource is resolved on the server.
+and for server-rendered routes its BackendTask is resolved on the server.
 
 Effect's/Cmd's are never executed on the CLI or server, they are only executed in the Browser. The data from a Route Module's
 `init` function is used to render the initial HTML on the server or build step, but the Effect isn't executed and `update` is never called
@@ -37,33 +38,33 @@ So why not just get the data the old-fashioned way, with `elm/http`, for example
 
 A few reasons:
 
-1.  DataSource's allow you to pull in data that you wouldn't normally be able to access from an Elm app, like local files, or listings of files in a folder. Not only that, but the dev server knows to automatically hot reload the data when the files it depends on change, so you can edit the files you used in your DataSource and see the page hot reload as you save!
+1.  BackendTask's allow you to pull in data that you wouldn't normally be able to access from an Elm app, like local files, or listings of files in a folder. Not only that, but the dev server knows to automatically hot reload the data when the files it depends on change, so you can edit the files you used in your BackendTask and see the page hot reload as you save!
 2.  You can pre-render HTML for your pages, including the SEO meta tags, with all that rich, well-typed Elm data available! That's something you can't accomplish with a vanilla Elm app, and it's one of the main use cases for elm-pages.
-3.  Because `elm-pages` has a build step, you know that your `DataSource.Http` requests succeeded, your decoders succeeded, your custom DataSource validations succeeded, and everything went smoothly. If something went wrong, you get a build failure and can deal with the issues before the site goes live. That means your users won't see those errors, and as a developer you don't need to handle those error cases in your code! Think of it as "parse, don't validate", but for your entire build. In the case of server-rendered routes, a DataSource failure will render a 500 page, so more care needs to be taken to make sure all common errors are handled properly, but the tradeoff is that you can use DataSource's to pull in highly dynamic data and even render user-specific pages.
-4.  For static routes, you don't have to worry about an API being down, or hitting it repeatedly. You can build in data and it will end up as optimized binary-encoded data served up with all the other assets of your site. If your CDN (static site host) is down, then the rest of your site is probably down anyway. If your site host is up, then so is all of your `DataSource` data. Also, it will be served up extremely quickly without needing to wait for any database queries to be performed, `andThen` requests to be resolved, etc., because all of that work and waiting was done at build-time!
+3.  Because `elm-pages` has a build step, you know that your `BackendTask.Http` requests succeeded, your decoders succeeded, your custom BackendTask validations succeeded, and everything went smoothly. If something went wrong, you get a build failure and can deal with the issues before the site goes live. That means your users won't see those errors, and as a developer you don't need to handle those error cases in your code! Think of it as "parse, don't validate", but for your entire build. In the case of server-rendered routes, a BackendTask failure will render a 500 page, so more care needs to be taken to make sure all common errors are handled properly, but the tradeoff is that you can use BackendTask's to pull in highly dynamic data and even render user-specific pages.
+4.  For static routes, you don't have to worry about an API being down, or hitting it repeatedly. You can build in data and it will end up as optimized binary-encoded data served up with all the other assets of your site. If your CDN (static site host) is down, then the rest of your site is probably down anyway. If your site host is up, then so is all of your `BackendTask` data. Also, it will be served up extremely quickly without needing to wait for any database queries to be performed, `andThen` requests to be resolved, etc., because all of that work and waiting was done at build-time!
 
 
 ## Mental Model
 
-You can think of a DataSource as a declarative (not imperative) definition of data. It represents where to get the data from, and how to transform it (map, combine with other DataSources, etc.).
+You can think of a BackendTask as a declarative (not imperative) definition of data. It represents where to get the data from, and how to transform it (map, combine with other BackendTasks, etc.).
 
 
-## How do I actually use a DataSource?
+## How do I actually use a BackendTask?
 
 This is very similar to Cmd's in Elm. You don't perform a Cmd just by running that code, as you might in a language like JavaScript. Instead, a Cmd _will not do anything_ unless you pass it to The Elm Architecture to have it perform it for you.
 You pass a Cmd to The Elm Architecture by returning it in `init` or `update`. So actually a `Cmd` is just data describing a side-effect that the Elm runtime can perform, and how to build a `Msg` once it's done.
 
-`DataSource`'s are very similar. A `DataSource` doesn't do anything just by "running" it. Just like a `Cmd`, it's only data that describes a side-effect to perform. Specifically, it describes a side-effect that the _elm-pages runtime_ can perform.
-There are a few places where we can pass a `DataSource` to the `elm-pages` runtime so it can perform it. Most commonly, you give a field called `data` in your Route Module's definition. Instead of giving a `Msg` when the side-effects are complete,
+`BackendTask`'s are very similar. A `BackendTask` doesn't do anything just by "running" it. Just like a `Cmd`, it's only data that describes a side-effect to perform. Specifically, it describes a side-effect that the _elm-pages runtime_ can perform.
+There are a few places where we can pass a `BackendTask` to the `elm-pages` runtime so it can perform it. Most commonly, you give a field called `data` in your Route Module's definition. Instead of giving a `Msg` when the side-effects are complete,
 the page will render once all of the side-effects have run and all the data is resolved. `elm-pages` makes the resolved data available your Route Module's `init`, `view`, `update`, and `head` functions, similar to how a regular Elm app passes `Msg`'s in
 to `update`.
 
-Any place in your `elm-pages` app where the framework lets you pass in a value of type `DataSource` is a place where you can give `elm-pages` a DataSource to perform (for example, `Site.head` where you define global head tags for your site).
+Any place in your `elm-pages` app where the framework lets you pass in a value of type `BackendTask` is a place where you can give `elm-pages` a BackendTask to perform (for example, `Site.head` where you define global head tags for your site).
 
 
 ## Basics
 
-@docs DataSource
+@docs BackendTask
 
 @docs map, succeed, fail
 
@@ -78,19 +79,23 @@ Any place in your `elm-pages` app where the framework lets you pass in a value o
 
 @docs map2, map3, map4, map5, map6, map7, map8, map9
 
+
+## Exception Handling
+
+@docs catch, throw, mapError, onError, toResult
+
 -}
 
-import Pages.Internal.StaticHttpBody as Body
-import Pages.StaticHttp.Request as HashRequest
+import Exception exposing (Catchable(..), Throwable)
+import Json.Encode
 import Pages.StaticHttpRequest exposing (RawRequest(..))
-import RequestsAndPending exposing (RequestsAndPending)
 
 
-{-| A DataSource represents data that will be gathered at build time. Multiple `DataSource`s can be combined together using the `mapN` functions,
+{-| A BackendTask represents data that will be gathered at build time. Multiple `BackendTask`s can be combined together using the `mapN` functions,
 very similar to how you can manipulate values with Json Decoders in Elm.
 -}
-type alias DataSource value =
-    RawRequest value
+type alias BackendTask error value =
+    RawRequest error value
 
 
 {-| Transform a request into an arbitrary value. The same underlying HTTP requests will be performed during the build
@@ -98,14 +103,14 @@ step, but mapping allows you to change the resulting values by applying function
 
 A common use for this is to map your data into your elm-pages view:
 
-    import DataSource
+    import BackendTask
     import Json.Decode as Decode exposing (Decoder)
 
     view =
-        DataSource.Http.get
+        BackendTask.Http.get
             (Secrets.succeed "https://api.github.com/repos/dillonkearns/elm-pages")
             (Decode.field "stargazers_count" Decode.int)
-            |> DataSource.map
+            |> BackendTask.map
                 (\stars ->
                     { view =
                         \model viewForPage ->
@@ -117,36 +122,33 @@ A common use for this is to map your data into your elm-pages view:
                 )
 
 -}
-map : (a -> b) -> DataSource a -> DataSource b
+map : (a -> b) -> BackendTask error a -> BackendTask error b
 map fn requestInfo =
     case requestInfo of
         ApiRoute value ->
-            ApiRoute (fn value)
+            ApiRoute (Result.map fn value)
 
         Request urls lookupFn ->
             Request
                 urls
                 (mapLookupFn fn lookupFn)
 
-        RequestError error ->
-            RequestError error
 
-
-mapLookupFn : (a -> b) -> (d -> c -> DataSource a) -> d -> c -> DataSource b
+mapLookupFn : (a -> b) -> (d -> c -> BackendTask error a) -> d -> c -> BackendTask error b
 mapLookupFn fn lookupFn maybeMock requests =
     map fn (lookupFn maybeMock requests)
 
 
 {-| Helper to remove an inner layer of Request wrapping.
 -}
-resolve : DataSource (List (DataSource value)) -> DataSource (List value)
+resolve : BackendTask error (List (BackendTask error value)) -> BackendTask error (List value)
 resolve =
     andThen combine
 
 
 {-| Turn a list of `StaticHttp.Request`s into a single one.
 
-    import DataSource
+    import BackendTask
     import Json.Decode as Decode exposing (Decoder)
 
     type alias Pokemon =
@@ -178,7 +180,7 @@ resolve =
             |> StaticHttp.andThen StaticHttp.combine
 
 -}
-combine : List (DataSource value) -> DataSource (List value)
+combine : List (BackendTask error value) -> BackendTask error (List value)
 combine items =
     List.foldl (map2 (::)) (succeed []) items |> map List.reverse
 
@@ -206,148 +208,119 @@ combine items =
             )
 
 -}
-map2 : (a -> b -> c) -> DataSource a -> DataSource b -> DataSource c
+map2 : (a -> b -> c) -> BackendTask error a -> BackendTask error b -> BackendTask error c
 map2 fn request1 request2 =
+    -- elm-review: known-unoptimized-recursion
+    -- TODO try to find a way to optimize tail-call recursion here
     case ( request1, request2 ) of
         ( ApiRoute value1, ApiRoute value2 ) ->
-            ApiRoute (fn value1 value2)
+            ApiRoute (Result.map2 fn value1 value2)
 
         ( Request urls1 lookupFn1, Request urls2 lookupFn2 ) ->
             Request
                 (urls1 ++ urls2)
-                (mapReq fn lookupFn1 lookupFn2)
+                (\resolver responses ->
+                    map2 fn
+                        (lookupFn1 resolver responses)
+                        (lookupFn2 resolver responses)
+                )
 
         ( Request urls1 lookupFn1, ApiRoute value2 ) ->
             Request
                 urls1
-                (mapReq fn lookupFn1 (\_ _ -> ApiRoute value2))
+                (\resolver responses ->
+                    map2 fn
+                        (lookupFn1 resolver responses)
+                        (ApiRoute value2)
+                )
 
         ( ApiRoute value2, Request urls1 lookupFn1 ) ->
             Request
                 urls1
-                (mapReq fn (\_ _ -> ApiRoute value2) lookupFn1)
-
-        ( RequestError error, _ ) ->
-            RequestError error
-
-        ( _, RequestError error ) ->
-            RequestError error
-
-
-mapReq : (a -> b -> c) -> (e -> d -> DataSource a) -> (e -> d -> DataSource b) -> e -> d -> DataSource c
-mapReq fn lookupFn1 lookupFn2 maybeMock rawResponses =
-    map2 fn
-        (lookupFn1 maybeMock rawResponses)
-        (lookupFn2 maybeMock rawResponses)
-
-
-lookup : Maybe Pages.StaticHttpRequest.MockResolver -> DataSource value -> RequestsAndPending -> Result Pages.StaticHttpRequest.Error value
-lookup maybeMockResolver requestInfo rawResponses =
-    case requestInfo of
-        Request urls lookupFn ->
-            lookup maybeMockResolver
-                (addUrls urls (lookupFn maybeMockResolver rawResponses))
-                rawResponses
-
-        ApiRoute value ->
-            Ok value
-
-        RequestError error ->
-            Err error
-
-
-addUrls : List HashRequest.Request -> DataSource value -> DataSource value
-addUrls urlsToAdd requestInfo =
-    case requestInfo of
-        ApiRoute value ->
-            ApiRoute value
-
-        Request initialUrls function ->
-            Request (initialUrls ++ urlsToAdd) function
-
-        RequestError error ->
-            RequestError error
-
-
-{-| The full details to perform a StaticHttp request.
--}
-type alias RequestDetails =
-    { url : String
-    , method : String
-    , headers : List ( String, String )
-    , body : Body.Body
-    , useCache : Bool
-    }
-
-
-lookupUrls : DataSource value -> List RequestDetails
-lookupUrls requestInfo =
-    case requestInfo of
-        ApiRoute _ ->
-            []
-
-        Request urls _ ->
-            urls
-
-        RequestError _ ->
-            -- TODO should this have URLs passed through?
-            []
+                (\resolver responses ->
+                    map2 fn
+                        (ApiRoute value2)
+                        (lookupFn1 resolver responses)
+                )
 
 
-{-| Build off of the response from a previous `DataSource` request to build a follow-up request. You can use the data
+{-| Build off of the response from a previous `BackendTask` request to build a follow-up request. You can use the data
 from the previous response to build up the URL, headers, etc. that you send to the subsequent request.
 
-    import DataSource
+    import BackendTask
     import Json.Decode as Decode exposing (Decoder)
 
-    licenseData : DataSource String
+    licenseData : BackendTask String
     licenseData =
-        DataSource.Http.get
+        BackendTask.Http.get
             (Secrets.succeed "https://api.github.com/repos/dillonkearns/elm-pages")
             (Decode.at [ "license", "url" ] Decode.string)
-            |> DataSource.andThen
+            |> BackendTask.andThen
                 (\licenseUrl ->
-                    DataSource.Http.get (Secrets.succeed licenseUrl) (Decode.field "description" Decode.string)
+                    BackendTask.Http.get (Secrets.succeed licenseUrl) (Decode.field "description" Decode.string)
                 )
 
 -}
-andThen : (a -> DataSource b) -> DataSource a -> DataSource b
+andThen : (a -> BackendTask error b) -> BackendTask error a -> BackendTask error b
 andThen fn requestInfo =
-    Request
-        (lookupUrls requestInfo)
-        (\maybeMockResolver rawResponses ->
-            lookup maybeMockResolver
-                requestInfo
-                rawResponses
-                |> (\result ->
-                        case result of
-                            Ok value ->
-                                case fn value of
-                                    ApiRoute finalValue ->
-                                        ApiRoute finalValue
-
-                                    Request values function ->
-                                        Request values function
-
-                                    RequestError error ->
-                                        RequestError error
-
-                            Err error ->
-                                RequestError error
-                   )
-        )
-
-
-{-| A helper for combining `DataSource`s in pipelines.
+    -- elm-review: known-unoptimized-recursion
+    -- TODO try to find a way to optimize recursion here
+    case requestInfo of
+        ApiRoute a ->
+            case a of
+                Ok okA ->
+                    fn okA
+
+                Err errA ->
+                    fail errA
+
+        Request urls lookupFn ->
+            if List.isEmpty urls then
+                andThen fn (lookupFn Nothing (Json.Encode.object []))
+
+            else
+                Request urls
+                    (\maybeMockResolver responses ->
+                        lookupFn maybeMockResolver responses
+                            |> andThen fn
+                    )
+
+
+{-| -}
+onError : (error -> BackendTask mappedError value) -> BackendTask error value -> BackendTask mappedError value
+onError fromError backendTask =
+    -- elm-review: known-unoptimized-recursion
+    case backendTask of
+        ApiRoute a ->
+            case a of
+                Ok okA ->
+                    succeed okA
+
+                Err errA ->
+                    fromError errA
+
+        Request urls lookupFn ->
+            if List.isEmpty urls then
+                onError fromError (lookupFn Nothing (Json.Encode.object []))
+
+            else
+                Request urls
+                    (\maybeMockResolver responses ->
+                        lookupFn maybeMockResolver responses
+                            |> onError fromError
+                    )
+
+
+{-| A helper for combining `BackendTask`s in pipelines.
 -}
-andMap : DataSource a -> DataSource (a -> b) -> DataSource b
+andMap : BackendTask error a -> BackendTask error (a -> b) -> BackendTask error b
 andMap =
     map2 (|>)
 
 
 {-| This is useful for prototyping with some hardcoded data, or for having a view that doesn't have any StaticHttp data.
 
-    import DataSource
+    import BackendTask
 
     view :
         List ( PagePath, Metadata )
@@ -369,23 +342,20 @@ andMap =
             }
 
 -}
-succeed : a -> DataSource a
+succeed : a -> BackendTask error a
 succeed value =
-    ApiRoute value
+    ApiRoute (Ok value)
 
 
-{-| Stop the StaticHttp chain with the given error message. If you reach a `fail` in your request,
-you will get a build error. Or in the dev server, you will see the error message in an overlay in your browser (and in
-the terminal).
--}
-fail : String -> DataSource a
-fail errorMessage =
-    RequestError (Pages.StaticHttpRequest.UserCalledStaticHttpFail errorMessage)
+{-| -}
+fail : error -> BackendTask error a
+fail error =
+    ApiRoute (Err error)
 
 
-{-| Turn an Err into a DataSource failure.
+{-| Turn an Err into a BackendTask failure.
 -}
-fromResult : Result String value -> DataSource value
+fromResult : Result error value -> BackendTask error value
 fromResult result =
     case result of
         Ok okValue ->
@@ -395,13 +365,31 @@ fromResult result =
             fail error
 
 
+{-| -}
+mapError : (error -> errorMapped) -> BackendTask error value -> BackendTask errorMapped value
+mapError mapFn requestInfo =
+    case requestInfo of
+        ApiRoute value ->
+            ApiRoute (Result.mapError mapFn value)
+
+        Request urls lookupFn ->
+            Request
+                urls
+                (mapLookupFnError mapFn lookupFn)
+
+
+mapLookupFnError : (error -> errorMapped) -> (d -> c -> BackendTask error a) -> d -> c -> BackendTask errorMapped a
+mapLookupFnError fn lookupFn maybeMock requests =
+    mapError fn (lookupFn maybeMock requests)
+
+
 {-| -}
 map3 :
     (value1 -> value2 -> value3 -> valueCombined)
-    -> DataSource value1
-    -> DataSource value2
-    -> DataSource value3
-    -> DataSource valueCombined
+    -> BackendTask error value1
+    -> BackendTask error value2
+    -> BackendTask error value3
+    -> BackendTask error valueCombined
 map3 combineFn request1 request2 request3 =
     succeed combineFn
         |> map2 (|>) request1
@@ -412,11 +400,11 @@ map3 combineFn request1 request2 request3 =
 {-| -}
 map4 :
     (value1 -> value2 -> value3 -> value4 -> valueCombined)
-    -> DataSource value1
-    -> DataSource value2
-    -> DataSource value3
-    -> DataSource value4
-    -> DataSource valueCombined
+    -> BackendTask error value1
+    -> BackendTask error value2
+    -> BackendTask error value3
+    -> BackendTask error value4
+    -> BackendTask error valueCombined
 map4 combineFn request1 request2 request3 request4 =
     succeed combineFn
         |> map2 (|>) request1
@@ -428,12 +416,12 @@ map4 combineFn request1 request2 request3 request4 =
 {-| -}
 map5 :
     (value1 -> value2 -> value3 -> value4 -> value5 -> valueCombined)
-    -> DataSource value1
-    -> DataSource value2
-    -> DataSource value3
-    -> DataSource value4
-    -> DataSource value5
-    -> DataSource valueCombined
+    -> BackendTask error value1
+    -> BackendTask error value2
+    -> BackendTask error value3
+    -> BackendTask error value4
+    -> BackendTask error value5
+    -> BackendTask error valueCombined
 map5 combineFn request1 request2 request3 request4 request5 =
     succeed combineFn
         |> map2 (|>) request1
@@ -446,13 +434,13 @@ map5 combineFn request1 request2 request3 request4 request5 =
 {-| -}
 map6 :
     (value1 -> value2 -> value3 -> value4 -> value5 -> value6 -> valueCombined)
-    -> DataSource value1
-    -> DataSource value2
-    -> DataSource value3
-    -> DataSource value4
-    -> DataSource value5
-    -> DataSource value6
-    -> DataSource valueCombined
+    -> BackendTask error value1
+    -> BackendTask error value2
+    -> BackendTask error value3
+    -> BackendTask error value4
+    -> BackendTask error value5
+    -> BackendTask error value6
+    -> BackendTask error valueCombined
 map6 combineFn request1 request2 request3 request4 request5 request6 =
     succeed combineFn
         |> map2 (|>) request1
@@ -466,14 +454,14 @@ map6 combineFn request1 request2 request3 request4 request5 request6 =
 {-| -}
 map7 :
     (value1 -> value2 -> value3 -> value4 -> value5 -> value6 -> value7 -> valueCombined)
-    -> DataSource value1
-    -> DataSource value2
-    -> DataSource value3
-    -> DataSource value4
-    -> DataSource value5
-    -> DataSource value6
-    -> DataSource value7
-    -> DataSource valueCombined
+    -> BackendTask error value1
+    -> BackendTask error value2
+    -> BackendTask error value3
+    -> BackendTask error value4
+    -> BackendTask error value5
+    -> BackendTask error value6
+    -> BackendTask error value7
+    -> BackendTask error valueCombined
 map7 combineFn request1 request2 request3 request4 request5 request6 request7 =
     succeed combineFn
         |> map2 (|>) request1
@@ -488,15 +476,15 @@ map7 combineFn request1 request2 request3 request4 request5 request6 request7 =
 {-| -}
 map8 :
     (value1 -> value2 -> value3 -> value4 -> value5 -> value6 -> value7 -> value8 -> valueCombined)
-    -> DataSource value1
-    -> DataSource value2
-    -> DataSource value3
-    -> DataSource value4
-    -> DataSource value5
-    -> DataSource value6
-    -> DataSource value7
-    -> DataSource value8
-    -> DataSource valueCombined
+    -> BackendTask error value1
+    -> BackendTask error value2
+    -> BackendTask error value3
+    -> BackendTask error value4
+    -> BackendTask error value5
+    -> BackendTask error value6
+    -> BackendTask error value7
+    -> BackendTask error value8
+    -> BackendTask error valueCombined
 map8 combineFn request1 request2 request3 request4 request5 request6 request7 request8 =
     succeed combineFn
         |> map2 (|>) request1
@@ -512,16 +500,16 @@ map8 combineFn request1 request2 request3 request4 request5 request6 request7 re
 {-| -}
 map9 :
     (value1 -> value2 -> value3 -> value4 -> value5 -> value6 -> value7 -> value8 -> value9 -> valueCombined)
-    -> DataSource value1
-    -> DataSource value2
-    -> DataSource value3
-    -> DataSource value4
-    -> DataSource value5
-    -> DataSource value6
-    -> DataSource value7
-    -> DataSource value8
-    -> DataSource value9
-    -> DataSource valueCombined
+    -> BackendTask error value1
+    -> BackendTask error value2
+    -> BackendTask error value3
+    -> BackendTask error value4
+    -> BackendTask error value5
+    -> BackendTask error value6
+    -> BackendTask error value7
+    -> BackendTask error value8
+    -> BackendTask error value9
+    -> BackendTask error valueCombined
 map9 combineFn request1 request2 request3 request4 request5 request6 request7 request8 request9 =
     succeed combineFn
         |> map2 (|>) request1
@@ -533,3 +521,31 @@ map9 combineFn request1 request2 request3 request4 request5 request6 request7 re
         |> map2 (|>) request7
         |> map2 (|>) request8
         |> map2 (|>) request9
+
+
+{-| -}
+catch : BackendTask (Catchable error) value -> BackendTask error value
+catch ds =
+    ds
+        |> onError
+            (\exception ->
+                case exception of
+                    Catchable error _ ->
+                        fail error
+            )
+
+
+{-| -}
+throw : BackendTask (Catchable error) data -> BackendTask Throwable data
+throw backendTask =
+    backendTask
+        |> onError (Exception.throw >> fail)
+
+
+{-| -}
+toResult : BackendTask (Catchable error) data -> BackendTask noError (Result error data)
+toResult backendTask =
+    backendTask
+        |> catch
+        |> andThen (Ok >> succeed)
+        |> onError (Err >> succeed)