What are you trying to do, if I may ask?
Scrolling back up I found this for routing - https://gist.github.com/bbarker/0014690c261b80c00c62d75e3f51744b
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.
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
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.
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
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
300K+ lines of code
and the majority of work was cleaning up cruft and hacks around having "empty" values hanging around the model
PR welcome for Scala.js 1.x
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
