Though, I had to drop 2.11 for now, because of chameleon (I currently use optional dependencies there and circe is not available for 2.11 anymore).
I will want to revisit the two open PRs about multiple result types and serialization. So I think, i will make another release 0.3.0 soonish.
How can I write an implementation that returns a Result[T] when I don't know what T is
This message was deleted
I see it comes back to
ClientImpl#execute taking R
To be clear the T is the deserialized response from the request?
so I thought that you moved R out to the trait and what remained was ErrorType
of course that can't be because result is now Result[T]
but I didn't think into it I guess
I think I'm good now
What I do not like about the logRequest is that you actually have to come up with a way to
log (stringify) it, so there is only toString or pattern matching. Not sure what could be a better approach.
i.e. what are the motivating use cases
The purpose is to enable centralized logging in the client. The router is typically on the backend and you have ways to log your requests between your, e.g., http-api and calling the router. But in the client, you might use
Future or Task or your result type. So in order to not do the logging on each method call, you can define the loghandler through which all requests with their results go.
Is is empty by default and does nothing, but it makes sense for some applications.
My use case for extending it was to log failures
But when would I want to log the response object
Currently, we pretty much just use the request path
List with two strings (the trait name and the method name). See: https://github.com/cornerman/sloth/blob/master/sloth/src/main/scala/Router.scala#L13
@nafg I currently use the logger only for development and debugging. So, in development I have debug logs in the
LogHandler and in production the LogHandler is empty. Otherwise, I agree with you - you normally want to log failures.
All it took was avoiding full auto derivation using shapeless, by writing magnolia derivers that respect existing instances
I can share the code later
Hello. I've been using covenant and sloth to manage my client/server interactions in a Scala 2.12 / Scala JS 0.6.x environment. Now... for various reasons, I must move to Scala JS 1.x, but it doesn't look like there are covenant/sloth versions for 1.x, which leaves me high-and-dry. Any suggestions? What are others doing in this situation? Thanks in advance for any advice you have.
@kennerstross Hi there! There was work done on it, but currently an optional dependency in
chameleon hinders a merge of the PR: cornerman/sloth#55
We need to wait for an issue in the boopickle release.
Alternatively, we could split up chameleon into multiple projects (for each dependency instead of having one release with optional dependencies). And in sloth only depend on the core types. Then we could make this faster.