Everything about Slinky -- issues, ideas for features, where it's being used, and more
slinky.native namespace. so far except for that PR I put in yesterday.
I've noticed that anything that can be represented as a ReactElement is implicitly convertible to a TagMod[Nothing]. but:
def group(els: TagMod[Nothing]*) = ???
// 1. This works:
group(Button(...), Button(...))
// 2. This doesn't:
buttons = List(Button(...), Button(...))
group(buttons: _*)
// 3. Given list of elements, one must:
group(buttons.map(_.asInstanceOf[TagMod[Nothing]]): _*)Can anyone think of a way to make the second case work?
ReactElement I think, which is converted to a TagMod[Nothing] via an implicit conversion. So the asInstanceOf is still required when defining each button in the list of buttons in my example. This might be #285 actually
TagMods, but #285 should help a lot with situations like this. I made a change in #263 to help improve this by defining an actual type hierarchy instead of depending on conversions (https://github.com/shadaj/slinky/pull/263/files#diff-bb19fdbf54abb277fcff78ce25743a71R14), but that PR also includes a lot of bundle-size optimizations through improved tag building macros that are blocked by a Scala compiler bug (https://github.com/scala/bug/issues/11628).
ReactElement => TagMod fix.
Has anyone had any luck getting "why did you render" monkey patch working?
Really useful for tracking unnecessary renders, but I'm not sure how compatible it is with slinky.
Since react devtools can't report on why slink props re-rendered (they get summarized as __). This is a nice tool to be able to use
@js.native
@JSImport("react", JSImport.Default)
object ReactLib extends js.Object
@js.native
@JSImport("@welldone-software/why-did-you-render", JSImport.Default)
class whyDidYouRender(reactRaw: js.Object, options: js.Object) extends js.Object
trait RenderTracker {
val renderTracker = if (env != "prod") {
println("WHY DID YOU RENDER ACTIVATED")
new whyDidYouRender(
ReactLib,
options = js.Dynamic.literal(
"include" -> List(RegExp(".*"))
)
);
} else {
null
}
}@shadaj so I'm able to get this working thanks to scalajs just needing a js.Array instead of List, but does Slinky implicitly load a monkey patched react library?
Reason I ask is because I notice none of my Slinky components are getting picked up when re-renders occur as expected, but all other react components from js.native imports are correctly getting renders detected.
So is there a way to pass my monkey patched version of react to slinky?
@shadaj I had a hunch that was the case. Yeah I noticed there's no way to conditionally import libraries like in native javascript.
I know monkey patches are out of scope (by definition), so this is extracurricular and I appreciate your thoughts on this. Would be really cool to be able to gain insights into extraneous rendering using this tool, especially since react devtools doesn't handle exploding Slinky's __ prop containter.
@shadaj is there a plan to support hot reload in hooks?
useState hook could be updated quite nicely to include RW def useState[T](default: T)(implicit r: Reader[T], w: Writer[T])On ony of my projects which is done in typescript I'm using hooks + hot reload via https://www.npmjs.com/package/react-hot-loader#hot-loaderreact-dom
is the novalidate attribute available in Slinky form?:
not found: value noValidate
[error] form(className := "col-10 px-1", noValidate := true)(I see it here, but it doesn't compile with error shown above:
https://github.com/shadaj/slinky/blob/fba7de821c1cfd3071b4a8db2216d71442e51b6b/generator/src/main/scala/slinky/generator/HTMLToJSMapping.scala#L86
All the examples I've tried give warnings like:
Timer.scala:13:2: Classes, traits and objects inheriting from js.Any should be annotated with @js.native, unless they have @ScalaJSDefined. The default will switch to Scala.js-defined in the next major version of Scala.js.Timer.scala:17:7: Members of traits, classes and objects extending js.Any may only contain members that call js.native. This will be enforced in 1.0.The annotations aren't helping. Is it complaining about StatelessComponent which is a js.Object? Not sure what to make of these, or if it's safe to ignore for now?
watchedObjects are referencing non-primitive types (potentially causing infinite render loops). Would be good to use a well maintained 3rd party library for this instead, but so far I've noticed many react tools have a hard time parsing scalajs components.
