Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Apr 02 21:46

    oyvindberg on reintroduce-circe-fork

    (compare)

  • Apr 02 21:46

    oyvindberg on master

    Revert "Prepare to release on m… (compare)

  • Apr 02 20:39

    oyvindberg on reintroduce-circe-fork

    Revert "Prepare to release on m… (compare)

  • Apr 02 19:19

    oyvindberg on master

    Update os-lib to 0.7.4 (#288) (compare)

  • Apr 01 16:58

    oyvindberg on master

    Update sourcecode to 0.2.5 (#28… (compare)

  • Apr 01 16:58

    oyvindberg on master

    Update fansi to 0.2.12 (#286) (compare)

  • Apr 01 10:08

    oyvindberg on master

    Update scalatest to 3.2.7 (#285) (compare)

  • Mar 31 21:07

    oyvindberg on master

    Followup from #283, only rewrit… (compare)

  • Mar 30 21:30

    oyvindberg on type-aliases-with-intersection-types

    (compare)

  • Mar 30 21:30

    oyvindberg on master

    Make typa aliases with intersec… (compare)

  • Mar 30 21:18

    oyvindberg on master

    Update sbt-mdoc to 2.2.19 (#284) (compare)

  • Mar 30 00:56

    oyvindberg on type-aliases-with-intersection-types

    Make typa aliases with intersec… (compare)

  • Mar 29 23:17

    oyvindberg on master

    Update sbt-ci-release to 1.5.7 … (compare)

  • Mar 21 21:44

    oyvindberg on gh-pages

    Deploy website Deploy website … (compare)

  • Mar 21 21:43

    oyvindberg on master

    fix render sidebar (#280) (compare)

  • Mar 21 11:40

    oyvindberg on master

    fix build/release - set sonaty… (compare)

  • Mar 21 06:19

    oyvindberg on v1.0.0-beta31

    (compare)

  • Mar 21 06:19

    oyvindberg on gh-pages

    Deploy website Deploy website … (compare)

  • Mar 21 05:08

    oyvindberg on master

    touchup release script for demo… (compare)

  • Mar 21 05:02

    oyvindberg on master

    Mangler: fix for apply methods … touchup release script for demo… (compare)

mcallisto
@mcallisto
yarn cache clean
Alexis Hernandez
@AlexITC
its worth trying
no luck, I'll try more stuff this evening, thanks
mcallisto
@mcallisto
You are welcome, it was just a quick idea, sorry it didn't help
Øyvind Raddum Berg
@oyvindberg

Ok, so just for the digging part first. On my machine your project ended up using @types/react-router version 5.1.13. This notably includes this commit https://github.com/DefinitelyTyped/DefinitelyTyped/commit/d200f1d32f7a7e69f4f4a248187f6e6641946ba4#diff-5c882d0b3aa2b278136fcaa031921b80600f8a5d45ff9cd6e13f4ece6f0fa91a which changes the API of the Router component.

If you dig up an earlier version number and put that into npmDependencies explicitly it should be picked up.

It now seems to support some TS magic where it extract parameter names from the path string
as you might imagine that's pretty hard to express in Scala
Øyvind Raddum Berg
@oyvindberg
So what to do about this? Either you stay on an old version of the type definitions forever, that works for a long while. JS APIs are not broken often because they cant do that
the other options is really to keep what's useful from the generated code and add your own glue code on top
I sketched this
package net.wiringbits.cazadescuentos

import slinky.core.facade.ReactElement
import slinky.web.html.*.tag
import typings.StBuildingComponent
import typings.history.mod.{Location, LocationState}
import typings.reactRouter.mod.{RouteComponentProps, StaticContext}

import scala.scalajs.js
import scala.scalajs.js.annotation.JSImport
import scala.scalajs.js.|

object SimpleRoute {

  def detailed[Params /* <: js.Object */, Path /* <: String */ ]: Builder[Params, Path] =
    new Builder[Params, Path](js.Array(this.component, js.Dictionary.empty))()

  @JSImport("react-router-dom", "Route")
  @js.native
  val component: js.Object = js.native

  @scala.inline
  class Builder[Params /* <: js.Object */, Path /* <: String */ ](val args: js.Array[js.Any])
    extends AnyVal
      with StBuildingComponent[tag.type, typings.reactRouterDom.mod.Route[Params, Path]] {

    @scala.inline
    def exact(value: Boolean) = set("exact", value.asInstanceOf[js.Any])

    @scala.inline
    def location(value: Location[LocationState]) = set("location", value.asInstanceOf[js.Any])

    @scala.inline
    def path(value: Path | js.Array[Path]) = set("path", value.asInstanceOf[js.Any])

    @scala.inline
    def pathVarargs(value: Path*) = set("path", js.Array(value: _*))

    @scala.inline
    def render(value: /* props */ RouteComponentProps[Params, StaticContext, LocationState] => ReactElement) =
      set("render", js.Any.fromFunction1(value))

    @scala.inline
    def sensitive(value: Boolean) = set("sensitive", value.asInstanceOf[js.Any])

    @scala.inline
    def strict(value: Boolean) = set("strict", value.asInstanceOf[js.Any])
  }

  implicit def make(companion: SimpleRoute.type): Builder[js.Object, String] =
    detailed
}
          SimpleRoute
            .exact(true)
            .path("/")
            .render { route =>
              div(
                menu(route.location.pathname),
                HomeComponent.component(HomeComponent.Props(props.api, props.appInfo))
              )
            },
That's just a little copy/paste with the difficult parts taken out
note that Path and Params can easily be removed as well
Øyvind Raddum Berg
@oyvindberg
but if you want to extract parameters Params is probably useful, anyways you can easily tweak that
So the next thing is what to do with the translation for this. I've been thinking about some type simplification step for a while. I'll probably open an issue soon to discuss possible simplifications
Alexis Hernandez
@AlexITC
makes sense, how did you found about @types/react-router 5.1.13? my first idea was checking this but I checked the yarn.lock and saw version 4

If you dig up an earlier version number and put that into npmDependencies explicitly it should be picked up.

now I'm confused with the versions, effectively this is what I have in the npm dependencies, my other project does too which works smoothly, SlinkyDemos as well

Øyvind Raddum Berg
@oyvindberg
cat target/scala-2.13/scalajs-bundler/main/node_modules/@types/react-router/package.json |jq .version
"5.1.13"
Alexis Hernandez
@AlexITC
makes sense, the npm dependencies have the version 5.1.2 defined (see), which is pulling 5.1.13, do you know a way to enforce it?
Øyvind Raddum Berg
@oyvindberg
try to add a line for react-router (without dom) as well
Alexis Hernandez
@AlexITC
no luck :(, in my case after sbt clean, I'm not even getting the target/scala-2.13/scalajs-bundler folder generated because the app won't compile
I added these lines:
    Compile / npmDependencies ++= Seq(
      "react-router" -> "5.1.2",
      "@types/react-router" -> "5.1.2"
    )
Alexis Hernandez
@AlexITC
this is crazy:
➜  pwa git:(master) ✗ cat target/scala-2.13/scalajs-bundler/main/node_modules/@types/react-router/package.json |jq .version
"5.1.2"
Alexis Hernandez
@AlexITC
I ended up applying your suggestions + reverting back to scalablytyped beta29 which fixed the build issues locally, I'm hoping that it fixes circleci too, thanks for your help
Alexis Hernandez
@AlexITC
indeed, its fixed!
Øyvind Raddum Berg
@oyvindberg
Well that's great, but was the revert necessary?
Alexis Hernandez
@AlexITC
that's the only way it worked, I'll try to upgrade again soon
Øyvind Raddum Berg
@oyvindberg
I'm wondering if there is an invalidation issue. I tried iocally to add "@types/react-router" -> "5.1.2", and it didn't reimport, like you observerd. When I made another change to npmDependencies (commented out classNames) it did reimport and it all compiled fine
Alexis Hernandez
@AlexITC
to be honest, I don't know what exactly I did because I tried many ways, like clearing local ivy2 cache, sbt clean, etc, something worked but I don't know what exactly was
I reverted the application's back to beta31, its compiling fine now, let's see how it goes in circleci
Alexis Hernandez
@AlexITC
it worked! I guess some cache issues was biting me before, in any case, thanks for all the help
Binh Nguyen
@ngbinh
@oyvindberg do you think it is feasible/easy to extend to generate bindings/facades from C/C++ for scala native?
Alexis Hernandez
@AlexITC
I'd look into GraalVM which might work for your use case
Øyvind Raddum Berg
@oyvindberg
@ngbinh certainly, it's done a lot for other languages I think. I don't have much time for it, but I'd gladly share ideas and experience from ST if someone is to try it
Does graalvm really help for integrating with c libraries @AlexITC ?
Alexis Hernandez
@AlexITC
I understand they claim to be that way but I haven't tried
Øyvind Raddum Berg
@oyvindberg
Finally had the time to write release notes for beta31 https://github.com/ScalablyTyped/Converter/releases/tag/v1.0.0-beta31
Alexis Hernandez
@AlexITC
nice, thanks!
Alexis Hernandez
@AlexITC
This message was deleted
Alexis Hernandez
@AlexITC
FYI: sbt 1.5.0 has been released but the scalablytyped plugin checks that you use 1.4.x, I want to believe there is nothing else preventing us to use sbt 1.5.x
Øyvind Raddum Berg
@oyvindberg
I believe it'll work too, but haven't verified
Alexis Hernandez
@AlexITC
Related to how the styles are being used in the material-ui example (see), the CSSProperties builder is nice but accessing the classes is stringly-typed (like classes("root")) which causes runtime errors when the string is missing from the map, is there any strongly typed alternative?
Øyvind Raddum Berg
@oyvindberg
This is something typescript is awesome at, and scala isn't. You can make a static JavaScript trait out of it, or you can use heavy duty type machinery to do it dynamically
Alexis Hernandez
@AlexITC
I will stick to the current approach for now, thanks for confirming what's available
Alexis Hernandez
@AlexITC
Does it makes sense to define generate types like A | Null instead of Option[A]? I'm trying the stripe library which leads to one of those
Øyvind Raddum Berg
@oyvindberg
@AlexITC well yes, when describing what the javascript looks like unfortunately it has to be like that. I've deliberately ignored the situation with A | Null and how it's horrible to use while waiting for Scala 3 to see how it turns out there. I guess the jury (and PRs) are still out for how good it'll actually be. There will always be the opportunity to add a NullOr class which mirrors js.UndefOr
Øyvind Raddum Berg
@oyvindberg
Also I've been thinking about more encoding changes where we describe javascript just through implicit sugar. Definitely an interesting direction, and all the code is already there
// now
trait A extends js.Object {
  var b: Foo | Null
}

// after
trait A extends js.Object
object A {
  implicit class Ops(a: A) {
    def b: Option[Foo] = Option(a.asInstanceOf[js.Dynamic].selectDynamic("b").asInstanceOf[Foo])
    def b_=(value: Option[Foo]) = a.asInstanceOf[js.Dynamic].updateDynamic("b", value.orNull)
  }
}
but then it's not very pretty