Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 20 07:38

    Atry on v11.8.2

    (compare)

  • Nov 20 07:37

    Atry on v11.9.0

    (compare)

  • Nov 20 07:33

    Atry on v11.8.2

    (compare)

  • Nov 20 07:27

    Atry on 219-fix

    (compare)

  • Nov 20 07:27
    Atry closed #219
  • Nov 20 07:27

    Atry on master

    Always update for views and mut… Merge pull request #220 from Th… (compare)

  • Nov 20 07:27
    Atry closed #220
  • Nov 20 07:12
    Atry synchronize #220
  • Nov 20 07:12

    Atry on 219-fix

    Always update for views and mut… (compare)

  • Nov 20 01:33
    Atry reopened #219
  • Nov 20 01:32
    Atry closed #219
  • Oct 09 04:00
    notyy commented #222
  • Oct 09 03:59
    notyy closed #222
  • Oct 09 03:59
    notyy commented #222
  • Oct 08 20:28
    Atry commented #223
  • Oct 08 20:28

    Atry on master

    docs: fix typo Merge pull request #223 from Ja… (compare)

  • Oct 08 20:28
    Atry closed #223
  • Oct 08 20:20
    Jason-Cooke opened #223
  • Oct 07 03:30
    glmars commented #222
  • Oct 06 04:05
    notyy opened #222
杨博 (Yang Bo)
@Atry
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.
Kahli Burke
@kahliburke
Anyway, I think you've inspired some good ideas on where to focus effort. Thanks for taking the time to discuss it, time to start looking at the scala-js codebase to see if that's at all penetrable by mere mortals.
杨博 (Yang Bo)
@Atry
Thank you, too!
Kahli Burke
@kahliburke
Glad we met in the same time slot, talk again later :)
杨博 (Yang Bo)
@Atry
:smile:
Basim Khajwal
@basimkhajwal

Hi, could someone point out what the cause of this error is in the following import com.thoughtworks.binding.Binding.{ Var, Vars }
import com.thoughtworks.binding.dom
import org.scalajs.dom.document

case class Model(name: String, contents: Vars[Double])

@dom
def render = {

val models = Vars(
Model("A Model", VarsDouble)
)

<div>
{
for (model <- models) yield {
<h3>{model.name}</h3>
<ul>
{
for (i <- model.contents) yield {
<li>{i.toString}</li>
}
}
</ul>
}
}
</div>
}

dom.render(document.body, render)

Sorry, forgot to format

The following code is what I'm trying to achieve in my own project (with a more complicated interface but the same error is what I am finding difficult to overcome).

import com.thoughtworks.binding.Binding.{ Var, Vars }
import com.thoughtworks.binding.dom
import org.scalajs.dom.document

case class Model(name: String, contents: Vars[Double])

@dom
def render = {

  val models = Vars(
    Model("A Model", Vars[Double](1,2,3))
  )

  <div>
    {
      for (model <- models) yield {
        <h3>{model.name}</h3>
        <ul>
        {
          for (i <- model.contents) yield {
            <li>{i.toString}</li>
          }
        }
        </ul>
      }
    }
  </div>
}

dom.render(document.body, render)

Running this (https://scalafiddle.io/sf/9eib3hm/0) gives the following error:

ScalaFiddle.scala:16: error: overloaded method value domBindingSeq with alternatives:
  ( text: String )binding.this.Binding.Constants[raw.this.Text] 
    ( node: raw.this.Node )binding.this.Binding.Constants[raw.this.Node] 
      ( seq: Seq[raw.this.Node] )binding.this.Binding.Constants[raw.this.Node] 
        ( bindingSeq: .this.com.thoughtworks.binding.Binding.BindingSeq[raw.this.Node] ).this.com.thoughtworks.binding.Binding.BindingSeq[raw.this.Node]
         cannot be applied to (.this.com.thoughtworks.binding.Binding.BindingSeq[.this.com.thoughtworks.binding.Binding.BindingSeq[raw.this.Node]])
    for (model <- models) yield {
                           ^
    }

Any help would be appreciated

Kahli Burke
@kahliburke
But in general the issue with using for/yield is that it turns into a map operation, when you really want a flatMap for what you're doing. So an alternative way would be to do:
models flatMap { model =>
        <h3>
          {model.name}
        </h3>
        <ul>
          {for (i <- model.contents) yield {
          <li>
            {i.toString}
          </li>
        }}
        </ul>
      }
This is only an issue when you're returning a sequence of xml elements from each element in a Vars or some other collection.
Basim Khajwal
@basimkhajwal
@kahliburke Thanks a lot, I didn't realise the for comprehension was actually using a map operation. In my mind I thought that if it worked for a regular Binding it would also work for a BindingSeq.
Kahli Burke
@kahliburke
@basimkhajwal In scala a for comprehension is syntactic sugar for chaining flatMap, map -> https://docs.scala-lang.org/tutorials/FAQ/yield.html#translating-for-comprehensions
Kahli Burke
@kahliburke
@Atry I'm wondering if you can clarify use of Var.value given the comment * @note This method must not be invoked inside a @dom method body.?
Is that purely about the @dom macro or does that extend to setting Var.value inside a Binding{ .. } block?
杨博 (Yang Bo)
@Atry
A @dom function is just a HTML template, which should be pure without any side effects, so doBinding blocks.
Both .value and .value_= are side effects.
Kahli Burke
@kahliburke
Yes, that's clear about.value causing side effects. But doing Binding { someVar.value = someBInding.bind}.watch would be ok?
杨博 (Yang Bo)
@Atry
It's very dangerous. Don't do that.
Kahli Burke
@kahliburke
Haha
Ok, I'm trying to figure out how to accomplish setting of a Var, say related to a user's choice in UI from some other Binding value that can sometimes change
杨博 (Yang Bo)
@Atry
That may create circular dependencies, and may cause some reentry bugs in Binding.scala's internal implementation.
Kahli Burke
@kahliburke
Yeah that's what I was concerned about too.. One option seemed to put Var.value = inside a Future block
杨博 (Yang Bo)
@Atry

Ok, I'm trying to figure out how to accomplish setting of a Var, say related to a user's choice in UI from some other Binding value that can sometimes change

You can try to not use Var for that case. Use Binding block instead.

Lorenzo Gabriele
@lolgab
Are there plans to support scala native?
杨博 (Yang Bo)
@Atry

Yeah that's what I was concerned about too.. One option seemed to put Var.value = inside a Future block

There is a FutureBinding for remote data. You can use it instead of Vars.

@lolgab It would be not very hard to support scala-native. PR is welcomed.
Kahli Burke
@kahliburke
This isn't for Future data from a call, the Var represents user state in an input element, but some other event happens in a different UI element and I want to respond to that change (via otherComp.bindingProperty.bind) and change the user's selection.
The idea was to use Binding { val store = binding.bind; Future { var.value = store} }.watch to break out of Binding context
杨博 (Yang Bo)
@Atry
It's better to avoid watch...
Kahli Burke
@kahliburke
Yeah it's not my go to approach but I'm trying to figure out how to write a generic input component with Var for its internal state in a way that it can also respond to some external change... seems tricky to do it without var, and how else do I hook up external.bind -> inputelem.value? The other thing I thought of was to completely recreate my input component in response to external change but I was trying to avoid that.
杨博 (Yang Bo)
@Atry
You can create another Binding that merges internal Var and external changes together.
Thinking about the dependency graph. A Var is always the source of the onchange event, not a intermediate node.
Kahli Burke
@kahliburke
Yes the graph makes sense. So my takeaway is that the warning about @dom applies to Binding {} as well, correct? Is the issue around circularity causing 'cycles' where dirty values cause other things to become dirty and we miss rendering properties (like digest cycles in the Angular world), or circularity causing stack overflow or other endless loop problems?
杨博 (Yang Bo)
@Atry
It will never cause stack overflow in Binding.scala. But it will cause some reentry, which Binding.scala did not mean to support.
Kahli Burke
@kahliburke
The idea in putting value set into a Future was to get out of the graph and schedule a new change event to occur in the future.
杨博 (Yang Bo)
@Atry
Creating a Future or a timer is also side effect. Don't do it in Binding block.
Kahli Burke
@kahliburke
Danger of reentry would be missing some change propagation?