Everything about Slinky -- issues, ideas for features, where it's being used, and more
3.0.0-M2. There could be non-obvious things and my stuff in non-ui. There is the Dotty plugin plus mapping the dependencies withisDotty` if needed. I have support in https://github.com/ekrich/sconfig/blob/master/build.sbt#L157-L161 and https://github.com/ekrich/sconfig/blob/master/project/plugins.sbt
Seems since I've upgraded to scalajs 1.3.1, scala2.13, and slinky0.6.6that none of the slinky reader/writer auto conversions are taking place. I'm having to Type things likejs.Function0[Unit]instead of() => Unit` and am unsure what could be causing it? Any ideas on how to debug root cause for this?
For instance, one runtime error I get for not using a function type with js.Function3 is:
Uncaught org.scalajs.linker.runtime.UndefinedBehaviorError: java.lang.ClassCastException: (arg1$2, arg2$2, arg3$2) => f$4.applyOOOO(arg1$2, arg2$2, arg3$2) is not an instance of scala.Function3
@shadaj thanks I double checked and did not see compile warnings when running client/fastOptJS::startWebpackDevServer;~client/fastOptJS (only warn was that there were deprecations...)
I thought I should put together a simpler example, so here's an object used by my react-table facade for headerGroupProps the table uses to store header information:
case class HeaderGroupProps(key: String, role: String)That compiles, but for this to successfully run I must write it as:
class HeaderGroupProps(val key: String, val role: String) extends js.Object
// example usage:
val g = headerGroup.getHeaderGroupProps()Else I get error:
Uncaught org.scalajs.linker.runtime.UndefinedBehaviorError: java.lang.ClassCastException: [object Object] is not an instance of HeaderGroupProps
Another example (for a simple object used by same facade) where if I try to use a Seq instead of js.Array I get:
Uncaught org.scalajs.linker.runtime.UndefinedBehaviorError: java.lang.ClassCastException: [object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object] is not an instance of scala.collection.immutable.Seq
Other versions I forgot to mention: sbt 1.3.13, Java 11.0.9.1
getHeaderGroupProps defined? JS objects will only be converted through Slinky readers when they are used as props for a Slinky component
What's a reasonable/idiomatic way to do this given
def useClientRect(initial: ClientRect) = {
val (rect, setRect) = Hooks.useState[ClientRect](initial)
val ref = Hooks.useCallback[Element => ()](node => {
if (node != null) {
setRect(node.getBoundingClientRect())
}
}, List())
(rect, ref)
}?
hopefully, this is not the best answer
val component = FunctionalComponent[Unit] { _ =>
val (rect, cb) = Draw.useClientRect(null)
val ref1 = Hooks.useRef[dom.html.Element](null)
Hooks.useEffect({ () => cb(ref1.current) })
div(
h1(ref := ref1)("Tall Writings"),
{
if(rect != null)
h2(s"How tall?! ${rect.height}")
else
h2("nope")
}
)
}especially since it gives Warning: Maximum update depth exceeded. This can happen when a component calls setState inside useEffect, but useEffect either doesn't have a dependency array, or one of the dependencies changes on every render.
rect, which causes the effect to run again, and so on. You probably need to use useLayoutEffect with an empty dependency array so that the ref1 will be available but the effect will only run once
dom.html.Element and use the client properties on it in some side-effecty hook (which might turn out to be the one you suggest anyway, to make sure everything is already where it is meant to be!). I was really more wondering whether slinky will support setting the ref attribute to a callback at some point, since it seems to make the non-determinism argument moot in such cases, or do you consider that to be an anti-pattern in this context.PS that live example/hackery I linked to in my initial post is actually based on the react hooks FAQ, :) , and it did look like interesting "sugar" for that sort of use case, even though it's a shame we have to resort to such measures at all.
Is there some alternative to scalafiddle these days? Hopefully scala-center will take that over at some point because it was a great resource, for all sorts of reasons, while the available libs and scala/sjs versions were kept close to uptodate, and even though scastie is also really good too, it wouldn't probably help us here.
@shadaj - is this the intended usage?
div(
ref :=[div.tagType] { el =>
if (el != null) {
val rect = el.getBoundingClientRect()
println(rect.top)
}
}
),That works anyway (not sure why inference was failing, but with the explicit type param it's OK).
Nice job for including even that in Slinky! Have you, or anybody, actually used it anywhere?
1 reply
if (isLoading) { h1(“loading”) } else { render the stuff.... } but it didn’t seem to work
Hi all. I'm sure I'm missing something obvious here. What's the Slinky equivalent of creating an array of Refs? I'm using functional components with hooks.
In vanilla React we have:
const ref = useRef();
const refsArray = useRef([]);In Slinky we have:
val ref = useRef[T](null)
val refsArray = ???I'm struggling to fill in the question marks. As you can tell, I'm trying to create a dynamic collection of Refs. Any hints or examples greatly appreciated!
Refs. In the JavaScript example you gave, what you actually end up with is a Ref containing an array. So in Slinky, the equivalent code would be useRef(Array(...))
Refs? In my case I have a dynamically growing collection of charts (using chart js via ScalablyTyped) for which I need a dynamically growing collection of Canvas Refs. It's proving much trickier than I first envisaged.
If anyone has better ideas please do let me know! I'm getting a lot done with Slinky, but I've never written a line of JS in my life so I've plenty to learn.
I will also get back at some point re your comment about the type-inference wrt call back refs, thanks.
