Everything about Slinky -- issues, ideas for features, where it's being used, and more
shadaj on main
Update sbt-scalafix to 0.10.0 (… (compare)
shadaj on main
Update sbt-sonatype to 3.9.13 (… (compare)
shadaj on main
Have Scala Steward always updat… (compare)
shadaj on main
Update sbt-idea-plugin to 3.13.… (compare)
shadaj on fix-docs-ssr
shadaj on main
Fix docs SSR unnecessarily depe… (compare)
shadaj on fix-docs-ssr
Fix docs SSR unnecessarily depe… (compare)
@react
annotation on external components only adds the nice apply
method, 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)
eval
with the component? Source maps by themselves would only map FunctionalComponent.js
to FunctionalComponent.scala
right?
@react
does (example), this way, you don't need to change the way you create components
Hi, what unit testing frameworks are people using with slinky react components?
Waiting for scalajs to transpile slows down testing. I've done some pretty extreme things, like deembedding parts of my code into cross compiled scala/scalajs projects, where pure scala unit tests execute lightening fast, but this has limitations. Anyone figure out super fast way to unit test?
unsafe-inline
. I have lots of react buttons that have onClick
handlers as well as inline style. Are these both no-nos for CSP? What are easy work arounds? I like inline onClick
and styles
, is there are a way to get the best of both worlds?
onClick
handlers through React you should be fine CSP wise. But you won't be able to create inline style tags so you will have to just set style properties locally perhaps?
I'm wondering if anyone in the slinky community does any code-splitting? I've been generating some bigger bundle sizes and was just reading about React.lazy
, but unfortuntely did that not get implemented in Slinky?:
shadaj/slinky#196
Are there other workarounds people use to code-split and lazy load their app progressively? This was a good read for anyone not familiar:
https://www.freecodecamp.org/news/how-to-use-react-lazy-and-suspense-for-components-lazy-loading-8d420ecac58/
React.lazy
in now, shouldn't be too much work. On bundle splitting that's something on my backlog (I want to set up a new template that has split modules by default), but haven't put it together just yet.
that's very cool! I think probably that would make sense as a separate project that just provides binary-compatible implementations of the Slinky APIs that run on the JVM
I think in general, having Slinky itself provide JVM implementations is going to be tricky because ensuring correct behavior would require basically reimplementing React, and in addition there would be no good way to test components that call out to external JS libraries
yeah that's what I'm thinking too. I separate project that provides fixtures for calling hooks in the right order, which itself gets (slowly) tested using React Testing Library. Since React versions don't change often, you'd seldom have to maintain these fixtures and once they are working reliably well you use them to test hooks from the JVM in your project, which runs lightening fast.
Basically it would be a state machine that would register each function you pass it as triggering certain behavior, which in turn would decide which hooks to call (such as useEffect, etc.)
More light weight question:
What's the defacto way to display an svg from a JSImport? Do I need to use @react
to turn it into a ReactElement
? Or is there a shorter syntax?