peterszerzo / elm-porter Goto Github PK

Currently, the user of this library has to write Sub.map PorterMsg and Cmd.map PorterMsg for every time he calls Porter.send somewhere.

I think it might be possible to hide this implementation detail a little more by making it part of the configuration. Porter.subscriptions already accepts the configuration as a parameter, so it would be able to just call into that.

Porter.send does not yet, which would make this a backwards-incompatible change, but I think it would make sense to accept the configuration as the first argument. This would also allow a user to wrap and name Porter.send someConfiguration, which makes it even nicer to use.

In a similar idea, one might specify the accessor method to the Porter field inside the model (like .porter) as part of the configuration, which would mean that the way Porter.update alters the model could be abstracted away from the user as well.

This means that the user only would have to type:

type alias Model =
    { my_porter_location : Porter.Model String String Msg
    , response : String
    }

port outgoing : Encode.Value -> Cmd msg
port incoming : (Decode.Value -> msg) -> Sub msg

porter config = 
    { outgoingPort = outgoing
    , incomingPort = incoming
    , encodeRequest = Encode.string
    , decodeRequest = Decode.string
    , porterMsg = MyPorterMsg
    , porterAccessor = .my_porter_location
    }

type Msg
    = OtherMsg String
     | MyPorterMsg (Porter.Msg String String Msg)

update msg model = 
    case msg of
       MyPorterMsg porter_msg ->
           Porter.update porterConfig porter_msg model 
        OtherMsg foo ->
            ...

subscriptions model = 
    Porter.subscriptions porterConfig

to set up porter.

Hello there! Porter is a wonderful library, and it definitely makes working with Elm's 0.18 (and upcoming 0.19)'s restrictions to interfacing with JavaScript a lot less painful.

I am attempting to perform a couple of Porter calls in sequence before these are mapped back to my main Msg; similar to Http.andThen, Task.andThen etc.

Is this currently possible or would it require a small change to the way response handlers are used?

As it is it's difficult to figure out the type to add to your model

So, after spending a couple of hours with the new andThen implementation, I realized that when writing a library, it is nice to expose concrete types as responses of the called functions to the user. (In practice, because of network failure and because we do not want to trust JS more than required, these types will be types like Result ErrorType String, Result ErrorType Bool, Result ErrorType Int).

Obviously, the API under the hood uses one single data type representation for the calls, and one single datatype for all responses (which means there is exactly one port-pair required). In my case, this is the 'Web3 Ethereum JSON-RPC API '. (The exact API I am consuming is this one).

However, to specialize the response types (which is a lot nicer than the user receiving SomeResponseType and having to handle whatever is returned themselves), we need to be able to specify a responseHandler function at request-creation time.

In the old API, this was no problem. We'd use the msg type for this result, and pass the proper res -> msg function as argument to the Porter.send function.

But in the new API, send and request have been split. There is no way to pass a responseHandler to a Porter.request call. However, in this example, I'd like to do:

user type 
-> (converted by Porter.Config.encodeRequest) req 
-> outgoing port 
-> JS 
-> incoming port 
-> (converted by Porter.Config.decodeRequest) res 
-> (converted by special response handler supplied to this specific request) specialzed_res 
-> (user-supplied response handler to Porter.send) msg

Maybe this is a way we could implement Porter.map: append a stage to the 'special response handler'?

This would turn the type of Porter.map into something like:

map : (resA -> resB) -> Request req inner_res resA -> Request req inner_res resB

(where chaining this directly to an andThen is obviously only possible when reqA === reqB)

I just came back from a very long day, but I did want to write this down now so you have some extra time to look at it, since this change will probably be not be able to be made in a backwards-compatible way.

Trying Main.elm from the Readme (git head):

-- NAMING ERROR ------------------------------------------------------- Main.elm

Cannot find variable `program`

59|   program
      ^^^^^^^
Maybe you want one of the following?

    Html.program
    Platform.program

Detected errors in 1 module.

When I replace this with Html.program, I run into a compiler error

-- TYPE MISMATCH ------------------------------------------------------ Main.elm

The argument to function `program` is causing a mismatch.

84|     Html.program
85|>        { init = init
86|>        , update = update
87|>        , subscriptions = subscriptions
88|>        , view = view
89|>        }

Function `program` is expecting the argument to be:

    elm-make: Type applications without concrete names should not get here.