Everything about Slinky -- issues, ideas for features, where it's being used, and more
noticed an interesting caveat when unit testing useEffect today. If my "dependencies" include a mutable map prop (which gets converted to js.Dictionary), the hook will get called even though the prop values never change!
So, the workaround is instead to set dependencies on explicit values within the map, like: watchedObjects = Seq(props.someMap("key1"), props.someMap("key2"))
Is this expected behavior with react? If not let me know and I can provide more detail
() => Unit version
maven-central badge is the latest version
I'm trying to use the react devtools profiler, and am noticing re-renders are occurring due to a phantom prop named __
I reported this in react github assuming it was some kind of short-hand, but the maintainer was confident this was indicative of there actually existing a prop called "__". Is Slinky passing hidden props like this? How could such a reference exist without it explicitly getting defined in a functional component?
I think my above post is true for all Slinky FunctionalComponents (class-based components don't have this issue). In React DevTools the Props are always consolidated under 1 object, called: __
The downside to this is React DevTools' latest feature that tells you why something re-rendered loses granularity in seeing which prop changed (since all of them are lumped into just one prop: __. This isn't an issue for class-based, which Slinky is fully complaint with and it's really nice seeing which specific prop changed leading to what render.
Is there a reason why Slinky FunctionalComponents might get interpreted as only having a single prop named __? I can provide a minimal example, but it requires installing React DevTools, which is a chrome extension.
__, both class-components and functional components share this behavior. The reason for this is that React strips out the .prototype key of the props. But we often need to pass down Scala objects that need the .prototype to be available. So to help fix this, Slinky emits the object under __ so that the prototype is preserved.
ok, you're right the class-based examples I mispoke on - those were ScalaJS facades and not Slinky components
So it sounds like I'm bumping up a hard limitation and that a better improvement would be for react devtools to support monitoring changes in hierarchical props objects, if that ever can be supported.
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