@asaadza: I can only speak for myself, but Scala 3 is still early, IntelliJ isn't super smooth with it yet, and macros need more work.
So I don't think there is a very strong push for Scala 3 at the moment.
The PR open for Scala 3 support is quite far, but it doesn't have support for the @react annotation, which means the user experience won't be great.
Give it a few more months and the ecosystem will be available ready for Scala 3.
The point about IntelliJ is mostly to show that Scala 3 isn't fully mainstream yet, if not even IntelliJ has seamless support yet.
I'm not the guy for lightweight IDEs, I'm way too accustomed to the benefits of a fullblown IDE.
Scala 3 will get there, but Scala 2 is not in its grave yet.
@reactif that's something people would use!
applyproblem (which would probably be sufficient for those who prefer functional components anyway) so slinky react UI development is still the nicest and most intuitive UX in scalajs land.
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]