-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compatibility with scala-js #38
Conversation
…s into g4s-10-support-for-scalajs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is completely awesome!!
However, I've requested some changes before merging. Besides that, I'd suggest a different LGTM from @raulraja or @rafaparadela since there are some commits with my name :P (sbt stuff)
|
||
import monix.execution.Scheduler.Implicits.global | ||
|
||
def userAgent = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could be this method a val
?
.enablePlugins(AutomateHeaderPlugin) | ||
|
||
lazy val testSettings = Seq( | ||
fork in Test := false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this fork in Test := false
be moved to sharedJsSettings
? In this way, the github4s module can be defined simply with
lazy val github4sJS = github4s.js
fork in Test := false | ||
) | ||
|
||
addCommandAlias("testAllCoverable", ";docs/test;scalaz/test;github4sJVM/test") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should testAll
alias include the github4sJS/test
sbt command as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did it that way because I was under the impression that scoverage wasn't compatible with scala-js, which was the case until this: scoverage/scalac-scoverage-plugin#118. Do you know which version of the sbt-scoverage plugin are we using on sbt-catalyst-extras? (I haven't been able to find it). I'm not really familiar on how it works... Maybe we need to update it for the JS tests to be coverable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I switched to using a higher version of the sbt-scoverage plugin and proved to be compatible with ScalaJS, so I removed the extra command and all the tests go through the coverage process.
} | ||
|
||
// TODO: put it back as it was |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this TODO
comment make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ermmm... nope! https://media.giphy.com/media/CdwvDXD6bqCcw/giphy.gif
.withHeaders(rb.authHeader.toList: _*) | ||
.withHeaders(rb.headers.toList: _*) | ||
|
||
(rb.data match { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just giving here my personal preferences for the following piece of code ;) :
rb
.data
.map(d => request.send(CirceJSONBody(d)))
.getOrElse(request.send())
.map(toEntity[A])
.recoverWith {
case e => Future.successful(Either.left(UnexpectedException(e.getMessage)))
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Elegant! Totally changing it to this!
|
||
def toEntity[A](response: SimpleHttpResponse)(implicit D: Decoder[A]): GHResponse[A] = | ||
response match { | ||
case r if r.statusCode < 400 ⇒ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Status codes should be placed in single place, we prefer to do not have literals along the code when possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we could move somewhere here: github4s.HttpClient.HttpStatus
, together with github4s.HttpClient.HttpVerb
.
Does it make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Totally!
version in ThisBuild := "0.8.3-SNAPSHOT" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file shouldn't be edited manually, it's being modified automatically when releasing the new version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK!
Current coverage is 86.37% (diff: 88.03%)@@ master #38 diff @@
==========================================
Files 16 21 +5
Lines 261 301 +40
Methods 259 299 +40
Messages 0 0
Branches 2 2
==========================================
+ Hits 226 260 +34
- Misses 35 41 +6
Partials 0 0
|
@raulraja @rafaparadela I performed the changes requested by @juanpedromoreno. If you have the chance, could you take a look at this (i.e.: there are changes introduced by both JP and me); or is this safe to merge already? Thanks! |
LGTM! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but would like to see the recommendation addressed before merging.
In order for github4s to work in both JVM and scala-js environments, you'll need to place different implicits in your scope: | ||
|
||
```tut:silent | ||
object JVMProgram extends github4s.ImplicitsJVM { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should provide objects for implicits imports such as github4s.jvm.implicits._
beside traits for aggregation. In most use cases folks are going to want an import not aggregating a trait.
…ts - Gists in tests are not publico
@raulraja I Implemented objects for easier use of implicits in both the JS/JVM projects. As soon as the build passes OK I'll merge this branch to master. Thanks! |
👍 |
OK, this is a rather lengthy one...
This PR contains code to make github4s compatible with scala-js projects. The process of doing so implies modifications in the overall structure of the project. The changes comprises the following:
github4s
is now a cross-project composed of three different modulesgithub4s
which holds the shared code between both the JVM and the JS sides (most of the code is there),github4sJVM
which contains an implementation of the http-requests-handling code more or less similar with the one we had before (compatible with Task, Eval, Id...); andgithub4sJS
which contains an alternative implementation of that code, but working with Futures and a HTTP client compatible with scala-js (roshttp
).ImplicitsJVM
trait to their code, so our implicit instances for Id, Task, Eval... and thescalaj
http clients are available forgithub4s
.ImplicitsJS
trait to their code; but also a valid implicit execution context (i.e.:import scala.concurrent.ExecutionContext.Implicits.global
). In this case,github4s
is limited to be use withFuture
and theroshttp
client.tut
doesn't seem to be compatible with scala-js code, as well asscoverage
. Both have been limited access to the JS code for the moment.Fixes #10
Could you please review, @juanpedromoreno @raulraja? Thanks!