Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
    It looks like you are right. Thanks. Still don't know what to do with it but at least I know why it happens.
    @esarbe Tkanks... I founded monadic-html nice codebase (RX implementation is so neat) but not sure if I'll put it into my current project. Proof of concept shows that sometimes trivial problem could stop progress for really long time. :(
    Raphael Bosshard
    It's a low-level library, not a complete framework, so depending on your needs, that might be true.
    What are you trying to do, if I may ask?
    Rohan Sircar
    Is it possible to create SPAs with this library? What could be used for routing URLs?
    Rohan Sircar
    Scrolling back up I found this for routing - https://gist.github.com/bbarker/0014690c261b80c00c62d75e3f51744b
    Glen Marchesani
    one issue we have run into is
        case Product(self, other) =>
          var go = false
          var v1: Any = null
          var v2: Any = null
          val c1 = run(self)  { a => v1 = a; if(go) effect((v1, v2)) }
          val c2 = run(other) { b => v2 = b; if(go) effect((v1, v2)) }
          go = true
          effect((v1, v2))
          Cancelable { () => c1.cancel; c2.cancel }
    we have uninitialized Var's and when we product them this causes an npe.
    hmm let me check the latest code (I know it is now called Zip) to see if that changed
    no effectively the same code
    @OlivierBlanvillain are you open to an MR that makes that waits on emitting anything from the product til both sides have a value ?
    I would say as a heavy user of monadic html with multiple developers on it requiring "empty" values for the model object you are pushing through is onerous...
    It just bleeds to lots of places.
    Glen Marchesani
    Or requires you to have lots of Rx[Option[A]] when what you really want is Rx[A]
    seems to me if you fix a few places and allow empty / uninitialized Rx's then that onerous part goes away
    and your various filter methods don't need default values
    I really don't want my developer's having to make decisions about default values when they are really on the UI side. and they are just adding a default value that is never used
    From what I can tell the default values on filter and other methods are simply because monadic html wants you to have all your Var's populated with a value.
    anywho curious to hear your thought @OlivierBlanvillain
    and also if you are open to an MR on that fix to product
    the fix would be a go self and a go other that get set when the self and other run's first see a value
    Olivier Blanvillain

    From what I can tell the default values on filter and other methods are simply because monadic html wants you to have all your Var's populated with a value.

    Yes, you nailed it. That's a core design decision with lots of implication, I don't think this is something that you could change just on Product. I understand the resistance against Rx[Option[A]], but I think that's really the way to go here.

    However, I would be curious to see what code led you to NPE, that shouldn't happen unless you wrote low-level code. Regardless of what led you there, it would be nice to have the library warn you as early as possible that you created an empty Rx, instead of throwing in Product.
    Glen Marchesani
    yes @OlivierBlanvillain we did something like new Var(None, _ => ())
    to create the empty Var's
    fwiw I have a fork exploring having empty Var's
    so these are the new signatures
      def collect[B](f: PartialFunction[A, B]): Rx[B]
      def dropIf[B >: A](f: B => Boolean): Rx[B]
      def keepIf[B >: A](f: B => Boolean): Rx[B]
    fwiw so far I haven't run into much of anything
    it does mean on the UI side your process is more about "how does the UI look with nothing" versus "modeling some empty data so the UI has something"
    from our use of this in anger the former is much easier to work with
    Glen Marchesani
    the latter has been the source of lots of painful corner cases popping up as any dev has to make reasonable choices about defaults
    where the problem is now moved to the people that style the app to say "hey this thing that takes some time to get initialized needs to get styled properly before it gets intiialized"
    and in that case if we want we can always supply something in the case where there is no value. i.e. we can supply a default empty view which is MUCH MUCH easier to do since that is the UI person doing that at the point
    instead of what we find one layer affecting the other layer in unpredicted ways
    software isn't in a vacuum
    I am curious to see how this fork works out, happy to post it once I get it working fully
    with this fork we have discussed something where you can take an Rx and supply a default if the Rx is empty
    Glen Marchesani
    @OlivierBlanvillain so far it is pretty clean, I have it integrated with the main app
    300K+ lines of code
    and the majority of work was cleaning up cruft and hacks around having "empty" values hanging around the model
    Glen Marchesani
    the product will go through QA testing shortly
    Anton Kulaga
    Is this library totally dead? I mean is anybody working on 2.13 & Scalajs 1.1x version?
    Olivier Blanvillain
    @antonkulaga It's not dead, it's done ;)
    PR welcome for Scala.js 1.x
    Glen Marchesani
    I have a fork I use for my commercial applications
    2.12 and 2.13 and the various scala js versions
    and to be clear this project is far from done for me ;-)