Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 18 20:09
    evbo commented #282
  • Sep 18 20:04
    evbo commented #282
  • Sep 11 15:44
    evbo closed #288
  • Sep 11 15:44
    evbo commented #288
  • Sep 11 13:44
    evbo commented #288
  • Sep 11 13:41
    evbo commented #288
  • Sep 10 21:21
    zakpatterson commented #293
  • Sep 10 21:20

    shadaj on master

    Add React Native Keyboard API f… (compare)

  • Sep 10 21:20
    shadaj closed #293
  • Sep 10 00:54
    zakpatterson synchronize #293
  • Sep 10 00:50
    zakpatterson synchronize #293
  • Sep 09 22:09
    zakpatterson edited #293
  • Sep 09 21:39
    zakpatterson edited #293
  • Sep 09 21:30
    zakpatterson opened #293
  • Sep 06 21:28
    shadaj commented #288
  • Sep 04 21:00
    yatesco commented #292
  • Sep 04 20:56
    ramnivas commented #292
  • Sep 04 20:09
    yatesco opened #292
  • Aug 18 20:21

    shadaj on master

    Fix #285, add support for using… (compare)

  • Aug 18 20:21
    shadaj closed #285
trepidacious
@trepidacious
The code has ended up much neater and more comprehensible as well, with nice simple types
trepidacious
@trepidacious
Hm, sorry for the essay, but final note I think - useState provides a stable setState function, so this can actually be used to make a stable dispatcher without additional messing about :)
aappddeevv
@aappddeevv
Same thing for useReducer, the dispatch is stable.
evbo
@evbo

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

Ramnivas Laddad
@ramnivas
@evbo That is to be expected, since on every conversion you will get a new js.Dictionary object and hooks dependency check use reference equality.
evbo
@evbo
okay, thanks!
trepidacious
@trepidacious
@shadaj @ramnivas Is there an equivalent of this form of React.useCallback in Slinky?
Looking through the code I can only see the () => Unit version
trepidacious
@trepidacious
Ah wow looks like I timed my question right... I guess this is it? shadaj/slinky@3dce67e
trepidacious
@trepidacious
How would I go about using the master version until the next release?
Shadaj Laddad
@shadaj
@trepidacious you can grab the version from the README (https://github.com/shadaj/slinky/blob/master/README.md), the version next to the maven-central badge is the latest version
trepidacious
@trepidacious
@shadaj Ah great, will do :)
evbo
@evbo

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?

evbo
@evbo

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.

Shadaj Laddad
@shadaj
@evbo Slinky always emits props under __, 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.
evbo
@evbo

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.

evbo
@evbo

@shadaj any general reason why .prototype might need to available? Just for performance? Or for access to public/private fields in certain cases?

Curious why react would strip out something that's useful like that!

Øyvind Raddum Berg
@oyvindberg
it's because afaiu react clones/rewrites the prop objects (for instance by adding key, ref, children), you should really just treat them as a collection of things instead of as an object which can have a prototype
so the direct consequence is that an instance of a scala type will come back in a way scala.js won't recognize, and you'll get a ClassCastException or whatever it is
and most scala.js wrappers like slinky work around this by wrapping it like you see here
Zak Patterson
@zakpatterson
HI, I was trying to create a touchable view that dismisses the keyboard on ios, is there support for the keyboard API? I wasn't able to find it in the source https://facebook.github.io/react-native/docs/keyboard
Zak Patterson
@zakpatterson
I think it just doesn't exist, I'll add the facade and a PR.
Zak Patterson
@zakpatterson
Shadaj Laddad
@shadaj
Yep, there are a fair number of React Native APIs (mostly the imperative ones) that don't have facades yet. My main use for Slinky is for websites, so many of the React Native definitions have been contributed by community members like you who are using it for mobile projects!
Zak Patterson
@zakpatterson
Sounds good, I'll try to add more PRs as I find the need for those APIs then.
Matt Hicks
@darkfrog26
is there any documentation about React Native with Slinky?
Also, anyone looking for some contract work to help us build a new UI for our application using React Native in Slinky?
it's for https://app.courio.com which is written entirely in Scala and Scala.js currently
Zak Patterson
@zakpatterson
I don't know about slinky react native documentation, but just looking at react-native's documentation, there's a one-to-one correspondence so far between what's in the 'react-native' js module and what's in the slinky.native namespace. so far except for that PR I put in yesterday.
Matt Hicks
@darkfrog26
@zakpatterson thanks, I'm a bit of a noob to React in general, so forgive my ignorance
Zak Patterson
@zakpatterson
no no, no forgiveness necessary. I think the best part about this library for me so far is to just expect that I can have the same power in scala as I would have in JS. that part is pretty good. documenting excessively on the slinky end would be duplication of effort or copy-pasting from react-native.
Matt Hicks
@darkfrog26
I think the best part is not having to write JavaScript. ;)
Zak Patterson
@zakpatterson
people have different priorities, no hate here for js.
static typing ftw though indeed.
mcallisto
@mcallisto
@darkfrog26 you might be interested in this demo (and related facades) https://github.com/mcallisto/slinky-antd-native.g8
Matt Hicks
@darkfrog26
@mcallisto, awesome, thanks!
Matt Hicks
@darkfrog26
@mcallisto the only thing missing from that is ReactNativeWeb support. ;)
Zak Patterson
@zakpatterson

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?

Zak Patterson
@zakpatterson
Actually the third case compiles but fails at runtime. so that's not great.
Øyvind Raddum Berg
@oyvindberg
@zakpatterson 2. looks like a classic type inference trap where types are inferred/converted in different ways based on expected type. If you annotate val buttons with the type List[TagMod[Nothing]] you should be good
Zak Patterson
@zakpatterson
Yeah it's tough here though because Button is a 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
Zak Patterson
@zakpatterson
Ah sorry, I oversimplified my example... my Button was actually a TouchableOpacity, which is an ExternalComponent. annotating my TouchableOpacity with ReactElement made it work. thanks for your advice @oyvindberg.
Shadaj Laddad
@shadaj
Yeah, elements unfortunately have a few implicit hoops to jump through before they can be used as 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).
Until the compiler bug can be fixed, I'm going to try and extract out the changes that don't depend on the new macros, which will probably include this ReactElement => TagMod fix.
evbo
@evbo

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

my attempt crashes:
@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
  }
}
evbo
@evbo

@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 Laddad
@shadaj
@evbo Hmm, Slinky just uses regular @JSImport to load React. If the monkey-patching depends on requires happening after it runs, that won't work in Scala.js since all @JSImports are put at the top of the file.
evbo
@evbo

@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.

Milan Satala
@msatala
Hi guys,
@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