I'm getting a strange error while trying to use ghcjs-servant-client with ghcjs-0.2.1.9008021_ghc-8.0.2, lts-8.21.

This is the relevant code:

        performEventAsync $
        flip fmap ue $ \(u, t) callback -> do
            void $
                liftIO $
                forkIO $ do
                    burl <- parseBaseUrl "http://localhost:8000"
                    errOrRes <-
                        runEitherT $
                        (client (Proxy :: Proxy AddItem) (Just burl)) t
                    callback $
                        case errOrRes of
                            Left err -> ErrorWhileSyncing u err
                            Right r -> SyncedAfterAdding u r

Any help would be greatly appreciated.

Leaving this issue here as I'd like to understand whether newer versions of servant will be supported.

Clients shouldn't convert JSON to JSVal and then convert JSVal to haskell datatypes. The conversion should be directly between haskell types and JSON.

If I'm mistaken in this, how can I automatically generate matching (To|From)JSVal instances from their (To|From)JSON counterparts?

When running inside a browser, the BaseUrl doesn't have to be set (unless one wants to use CORS). It seems to me that it would make sense to change the BaseUrl parameter to Maybe BaseUrl. It would allow to declare all the functions as top-level in a module. Along with some type signature changes, this seems to do the trick:

buildUrl :: Req -> Maybe BaseUrl -> URI
buildUrl req@(Req path qText mBody rAccept hs) baseurl =
  (baseURI baseurl){uriPath = path, uriQuery = query}
  where
    query = unpack $ renderQuery True $ queryTextToQuery qText
    baseURI Nothing = nullURI
    baseURI (Just (BaseUrl scheme host port)) =
      nullURI {
        uriScheme = schemeText,
        uriAuthority = Just $ URIAuth "" host portText
      }
      where
        portText = ":" <> (show port)
        buildQuery request = unpack $ renderQuery True $ queryTextToQuery qText
        schemeText = case scheme of
                            Http -> "http:"
                            Https -> "https:"

Currently the response type is hardcoded as "json". If the server returns response of different type, typically in te case of server error, parsing fails and we get null response body.

It would be better not to set response type and leave parsing the response to the api user.

I wonder if doing this would break processing in the non-error case.. can somebody comment?

I can do a pull request if this change is deemed correct.