ScalablyTyped/community

https://scalablytyped.org/docs/plugin

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

Where communities thrive

People

Repo info

Activity