I'm not sure if this is a bug with Slinky reader, but I am using
Reader[MyClass] when calling a facade that returns a JSON object in order to deserialize it into
It tricks the scala compiler into assuming the type of the result is
MyClass but unfortunately
Option[String] types are actually just
String causing runtime exceptions
Is there a way to get a
Reader to honor
MyClass has an attribute that is
Option[String], so could
Some("text") instead of just
I've got a question about
Reader. I'm trying to create a
final case class NoYes(value: Option[Boolean], onChange: Boolean => Unit)
And it blows up in
slinky.readwrite.FunctionReaders#function1 when the component tries to call
fn is not a function. It's not a function because
undefined. It wasn't entirely clear where
fn was coming from, it seemed to be part of the anonymous function.
Stepping through the JS code, the
Reader[NoYes] was trying to read
o.onChange instead of the actual properties which is some long fully qualified name with
. replaced with
_. Presumably this is the
Reader macro doing this? I've never had a problem before. Any idea why this one is different?
ReactComponentClass. Turns out I didn't need this (I accidentally used
React.memofrom ST and not the Slinky one).
@shadaj:matrix.org with Slinky being such a great advent, have you (un)seriously considered a Svelte companion-repo to Slinky?: https://svelte.dev/
Looks awesome but I'm too invested in React, unless the tides were to change (some day)...
zetashift: mostly, the API is identical except for not having the
@react macro available, so you'll have to manually use
ComponentWrapper for class components and create a nicer
but other than that, we actually share all the unit test code between Scala 2 and 3 so things are actually mostly source compatible too
@shadaj:matrix.org do you have any plans to allow propagating implicits from components? from what I see, there is a big deal when declaring a component by using
def instead of
val, which is what prevent this approach to work.
I understand that doing this would break exporting components to js but it would be pretty useful to propagate context in a type-safe way
Slinky comes ready with full integration with familiar tools like [...] React DevTools.
@reactannotation on external components only adds the nice
applymethod, but doesn't do any other rearranging.
method deriveWriter in trait MacroWriters does not match type slinky.readwrite.Writer[Props]
... react-dom.development.js:12657 The above error occurred in the <Component> component: at eval (webpack:///./target/scala-2.13/client-fastopt/slinky.core.FunctionalComponent.js?:77:59) at eval (webpack:///./target/scala-2.13/client-fastopt/slinky.core.FunctionalComponent.js?:77:59) at eval (webpack:///./target/scala-2.13/client-fastopt/slinky.core.FunctionalComponent.js?:77:59) at eval (webpack:///./target/scala-2.13/client-fastopt/slinky.core.FunctionalComponent.js?:77:59)
evalwith the component? Source maps by themselves would only map
@reactdoes (example), this way, you don't need to change the way you create components