Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
    Glen Marchesani
    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 ;-)
    I have long standing commercial applications committed to it
    Ján Nosál
    @OlivierBlanvillain I can't find the info about this, I wonder, is server side rendering possible?
    Olivier Blanvillain
    @JanNosal Not in the current state, alought looking at what other libraries are doing it might be theoritically possible...