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
Vladislav Lipatov
@elite174
That's great! Thank you for your answer. I'm asking, because I'm about to rewrite a react project into a scala.js project. I did benchmarking yesterday (I was comparing react and binding.scala), and I discovered that they are almost the same in terms of speed. However, binding.scala "eats" more memory than react, but it's not a big deal for me. I think binding.scala is a great library, because of its simplicity.
Yang, Bo
@Atry
Some of memory issues are due to scala-js/scala-js#2675
Vladislav Lipatov
@elite174
Is the binding.scala a complete library or you are about to add more functions and improvements?
Yang, Bo
@Atry
I don't know how to answer the question.
Is Scala a complete language?
Aron Trauring
@AronT-TLV
@ccamel having a problem-trying to Play or look at your samples in ScalaFiddle. In the former I get a blank page & in the latter I get a message ERROR: Attempted to asign to a readonly variable
René Vangsgaard
@rvangsgaard
@Atry I enjoyed the first two parts of your articles at InfoQ (for reference https://www.infoq.com/articles/more-than-react-part-i). Are part 3 and 4 published already?
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.