More flexible upickle integration #1969
Conversation
|
@szymon-rd what do you think? :) |
| import sttp.client4._ | ||
| import sttp.client4.internal.Utf8 | ||
| import sttp.model.MediaType | ||
| import sttp.client4.json._ | ||
|
|
||
| trait SttpUpickleApi { | ||
| val upickleApi: upickle.Api |
There was a problem hiding this comment.
question: Can't we just have a default implementation = upickle.default here?
There was a problem hiding this comment.
we could but that wouldn't be very helpful. The type of the upickleApi needs to be overriden to the singleton type of the value (I'll extend the docs). Otherwise, things don't work as expected, as the compiler can't lookup the correct Reader/Writer values.
There was a problem hiding this comment.
Oh right, the value type has to be overridden by a concrete type. This dependent type management on the library user side is quite confusing.
|
It looks good and works very similarly to the upickle itself. I wonder if it will always type check, given using the path-dependent types in this trait. |
|
@szymon-rd that's a good question, but I'm not sure how to verify if that's the case :) In a way, you're always using path-dependent types with uPickle (by importing |
|
@szymon-rd I'd give this a go, however note that it will require changing imports (in the tutorials etc.) the import from But that's probably version in the toolkit? (that is, a specific version of the toolkit has its own docs & fixed sttp/upickle versions) |
|
@adamw We have one version of tutorials right now, we will add different versions when adoption grows. However, now, it is sufficient to just keep the most recent one. |
|
ok, releasing as 4.0.0-M6 :) we can always revert in case of problems |
Closes #1821