Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 17 02:41
    scala-steward opened #296
  • Oct 06 19:15
    scala-steward opened #295
  • Oct 04 09:58
    romansky commented #294
  • Oct 04 09:02
    Atry closed #294
  • Oct 04 09:02
    Atry commented #294
  • Oct 01 15:27

    Atry on master

    Update the link (compare)

  • Oct 01 15:17
    romansky opened #294
  • Sep 29 23:57
    scala-steward opened #293
  • Sep 18 21:04
    scala-steward opened #292
  • Sep 14 19:28
    scala-steward opened #291
  • Sep 08 17:57
    scala-steward opened #290
  • Aug 31 04:42
    scala-steward opened #289
  • Aug 11 03:17
    scala-steward opened #288
  • Aug 07 06:53
    scala-steward opened #287
  • Jul 27 16:34
    scala-steward opened #286
  • Jul 20 19:58
    scala-steward opened #285
  • Jul 11 00:24
    scala-steward opened #284
  • Jun 30 21:04
    scala-steward opened #281
  • Jun 29 15:04
    scala-steward opened #280
  • Jun 28 01:13
    scala-steward opened #279
Yang, Bo
@Atry
As far as I know, @Joannayu is translating part 3
Rajeev Kumar kallempudi
@rajeevprasanna
Rajeev Kumar kallempudi
@rajeevprasanna
@Atry Thank you
Yang, Bo
@Atry
:smile:
Rajeev Kumar kallempudi
@rajeevprasanna
Basim Khajwal
@basimkhajwal
Hi,
I was reading through https://blog.scalac.io/binding-scala.html#scalajs-ui and it seems that the way to reference elements is by using the id of the element which is exposed as a local symbol through @dom. This compiles fine for me but the issue I have is that I haven't found any way to make this work inside IntelliJ. Is there any other way to reference elements that will type-check in IntelliJ (even by making a local variable if necessary) ?
Rajeev Kumar kallempudi
@rajeevprasanna
Basim Khajwal
@basimkhajwal
Is there any way to convert a Seq[Binding[A]] to BindingSeq[A] ?
Kahli Burke
@kahliburke
@basimkhajwal As an example: val bindSeq = Constants(seqOfBinding: _*) map (_.bind)
Kahli Burke
@kahliburke
@basimkhajwal As for your first question, yeah it's a little unfortunate that IntellJ doesn't know about the existence of the variable. However I think something like in this ScalaFiddle would work: https://scalafiddle.io/sf/cLY6dLz/1
Kahli Burke
@kahliburke
@Atry I ran into an interesting bug/issue that I'm curious if you have any insight about. I started getting this error applyDynamic does not support passing a vararg parameter [error] <section class="backgroundrepeating l-containerhorizontal" data:role="main" data:aria-labelledby="main-title">. This occurs if any data:* attributes are on this section tag, however I can workaround it by taking the contents of the section tag and putting them into a different @dom annotated method.
I'm guessing it's in the macro generated code somewhere but not quite sure where this issue is cropping up. I see that this error seems to refer to a scala compiler bug. https://issues.scala-lang.org/browse/SI-9308
Yang, Bo
@Atry
@kahliburke You can create an issue with reproducible example.
Kahli Burke
@kahliburke
Yeah, hard to do at this point because it seems to depend very heavily on how things are structured. Just was wondering if you had run into anything like it.
Kahli Burke
@kahliburke
@Atry I have a scalafiddle that shows this: https://scalafiddle.io/sf/yXNtdXr/0
I'll put an issue in github
Kahli Burke
@kahliburke
ThoughtWorksInc/Binding.scala#64
Yang, Bo
@Atry
@kahliburke It is a known bug in Scala's macro system
Kahli Burke
@kahliburke
I see, do you want me to close the issue? Or link to the actual cause and keep it there for someone else who might be looking (considering there is a workaround documented there too)?
Yang, Bo
@Atry
I saw this bug report at some time, but I can't find it now
Kahli Burke
@kahliburke
I imagine this is what you're referring to? https://issues.scala-lang.org/browse/SI-9308
Yang, Bo
@Atry
I'm not sure
Kahli Burke
@kahliburke
Thanks for fixing #56 , I tested it here and that is working
Yang, Bo
@Atry
Thank you for point out this bug! @kahliburke :+1:
Kahli Burke
@kahliburke
Sure, sorry I didn't figure it out myself...
Kahli Burke
@kahliburke
If you have any time to talk about stuff related to this library, my difficulty now is in trying to optimize the size of the macro generated code. In particular the differing implementation of Jvm vs Js as imported via the @enableMembersIf macro led me to the discovery that in deeply nested calls, ScalaJS does not optimize away certain conversion between Seq and js.Array (https://github.com/ThoughtWorksInc/Binding.scala/blob/1300e7bf0dbff01ccf100ad2fa4b7cc414cdd116/Binding/src/main/scala/com/thoughtworks/binding/Binding.scala#L146) which results in larger blocks of code than is necessary. I've inquired about it on the scala-js channel. Also, just trying to figure out how to reduce the resulting code size to make the fastOpt process run "fast". Large DOM views result in a lot of nested calls, and I'm curious whether some of the domBindingSeq calls from macros could be improved to prevent sibling nodes from producing nested Bindings.
Yang, Bo
@Atry
How about removing the @inline annoation from toConstantsData?
Those nested calls are actually IIFEs. See scala-js/scala-js#2675
Kahli Burke
@kahliburke
Something to try... I remember reading this discussion between the two of you earlier, thanks for making that connection. So is it possible to avoid them?
If I have many sibling nodes like
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
    <div>b</div>
That can result in lots of nesting too
Yang, Bo
@Atry
Because they are monadic expressions
Kahli Burke
@kahliburke
Yeah, I was curious if it was possible to capture that in a single monad
Yang, Bo
@Atry
It performs something like CPS-transformation
Kahli Burke
@kahliburke
Yes, I am passingly familiar with it although I'm certain you have a more detailed understanding given your work. So, trying to ask an expert :)
Seems like OutputMode.ECMAScript6 might offer a solution in the long term but not possible in current browsers, correct?
Yang, Bo
@Atry
Those IIFEs are not necessary for fullOpt even in current browsers because:
  • The code generated by Scala.js will be passed to Closure compiler
  • Closure compiler support ECMAScript2015 input
  • Scala.js can produce ECMAScript2015 output
We need some changes in Scala.js:
  • Don't generate IIFEs if the output mode is ECMAScript2015
  • Switch to ECMAScript2015 output mode in fullOpt, to generate the code for Closure compiler
Kahli Burke
@kahliburke
Thanks for the clarification. Explains why things are much improved in the fullOpt version, this is mainly a development concern for me, the fastOpt process takes a long time and results in 20MB output.
As I write more UI, this scales up quickly
If you have an idea of clever workarounds within Binding.scala, let me know as I would invest some time into it.
Yang, Bo
@Atry
You may try to add a condition for IIFE generation that detects if the output mode is ECMAScript2015. I guess it will be a small change in https://github.com/scala-js/scala-js.
Kahli Burke
@kahliburke
Oh on reading your note again I see I misunderstood you... the IIFEs are currently present in fullOpt but could be dealt with via Closure compiler if Scala.js would produce the ECMAScript2015/ES6 output
That sounds like a good idea, as in development it's not a problem to use a modern browser that supports ECMAScript2015.
Yang, Bo
@Atry
It's irrelevent. Clousure compiler can convert ES2015 to ES5
Kahli Burke
@kahliburke
Ok, but for development workflow we would use fastOpt which does not pass through Closure, correct?
Yang, Bo
@Atry
I guess @sjrd also wants to reduce number of IIFE generation even for ES5.
Kahli Burke
@kahliburke
That would be great too, but for development I could simply enforce ES6 output and make sure devs use a modern browser? So I'd get the benefit of no IIFEs in dev mode, but that code would then work across a wider browser suite once pushed through fullOptJs?
Yang, Bo
@Atry
Yes. Totally disabling IIFE for ES6 is a easier change than delicately reducing IIFEs.