0.3 Roadmap?

[ches]

I noticed that you had said on other issues that you wanted to rewrite, and then saw that you made what seems to be a lot of progress on the 0.3.0 branch. For sake of others like me who may wonder about status and what to expect, could you comment on goals of 0.3 and the scope of changes you anticipate? Are there any problems that stalled you, other than time?

Thanks!

[pocorall]

I like this project. But, sadly, it seems not so active. I am playing with scala.rx 0.2.8 with my project (https://github.com/pocorall/reactoid), and found several things to be improved, including something that told fixed in 0.3.

[lihaoyi]

Yeah, I haven't had time to work on front-end web stuff in Scala and so this project has languished. I'll pick it up again when I'm doing front-end work in Scala again, but exactly when that can happen is uncertain

[antonkulaga]

@pocorall I am also using Scala.Rx actively, will be looking forward to version 0.3

[Voltir]

Id say this is one of my favorite libraries in the Scala.js ecosystem - breaks my heart to see it languish. So, to that end id like to help where I can - im no Li Hayoi, but I think I have a pretty good handle on Scala.Rx, at least as far as an end user is concerned. I have started looking over the 0.3 branch and basically I want to see if I can get that to work in my own projects that depend on it.

Im hoping that some of my (upcoming) pull request will at least prompt some discussion and perhaps li haoyi can give me some guidance on what he would like to see in 0.3 -- maybe via the issue tracker?

[lihaoyi]

Yeah it's unfortunate, but I'm only one person working on this 0% of the time. I honestly don't have the capacity to even review code right now, it's been page out of my head for years now and I don't have an active use case that would warrant paging it back in.

If you want changes now, I think your best bet would be to fork it and take over maintenance for the time being. I don't mind re-directing people to your fork from the Scala.js website etc.. Otherwise you'll have to wait until I land a front-end UI job in Scala.js for me to pick up interest again.

Also perhaps you could ping me on gitter and we could talk through what I think 0.3.0 would have, even if I can't implement it or review what your code is doing

[Voltir]

As an update for anyone looking at this issue - I now have commit privileges for this repo and will be taking over general maintenance for the time being

Basically my goal will be to leave the 0.2 branch mostly alone - mostly just do dependency updates as needed. My primary focus will be on bringing the 0.3 branch to light although from what I can tell, its already really good as it achieves most of what Li wanted. I am currently testing it in my own projects and so far the changes to both 0.3 and my code have been very minor.

Anyway, Li Haoyi has indicated that he really doesn't have much by way of free time so I am hoping that maybe one or two people in this chain might be willing to do code review / sanity check on my pull requests... otherwise I make no guarantees that my code will not somehow cause irreparable damage to your application, program, database or even potentially your very well being.

[antonkulaga]

@Voltir I am also interested in 0.3 branch, so I can help sometimes

[lihaoyi]

Here is my brain dump of where I want Scala.Rx to end up, from our discussion on gitter:

Things I like:

• The Var/Rx/Obs triumvirate
• Use-site syntax (Rx{ a() + b() }) is great, way better than monadic for-comprehension style
• Updating multiple Vars before kicking off a single propagation is necessary
• Ability to query the ancestors and descendents is probably useful
• .filter acting funny (i.e. not filtering the first element) is probably hard to avoid

Things I wanted to change:

• "Owner" concept: currently IIRC it is done via dynamic scope, I wanted to make it an statically-resolved implicit. To make it work with Rx{ a() + b() } syntax it needs a macro, which I think 0.3.0 already has
• Nodes should be named automatically by a macro, the same way I do it in FastParse
• Scheduler stuff (debounce, timer, etc.) can go in a separate dependency to avoid a core dependency on Akka, or just be ripped out
• The whole codebase is heavily based on trait-implementation-inheritance, which is probably a mistake; we should use composition more instead (not sure what the best way is)

Things I wanted to rip out:

• All the parallel-propagation stuff; if I wanted to do that again (I'm pretty sure I will) I'd do it in a separate library and find common ground later to extract out later
• All the stuff used to make things thread-safe: SpinSet, various atomics, all the retry-loops etc.
• The whole "Var.update() returns different types depending on implicit propagator" thing
• All the abstracted Reactor/Emitter traits in here can probably die. If we find ourselves sharing common-ground with Monifu/etc. we can pull them out later

I gave @Voltir commit access, since he's a heavy user and will want to improve things. I think we agree on most things. Hopefully with someone maintaining it the library can improve rather than stagnate. I don't mind discussing things, but for now I've lost basically all context and can't even review code, so it'll be up to @Voltir to drive things forward and make decisions. I'll just hit +publishSigned whenever he tells me to.

We can experiment with giving more/other interested parties commit access if we find this isn't working out, but for now feel free to send PRs and now we have an active maintainer that should be able to review/discuss/merge.

Let's see how this goes =D

[antonkulaga]

I would be happy to be able to have several execution contexts. For instance in some cases it is convenient to run all animation-related stuff (sometimes Rx-ses can also be involved in animations) in requestAnimationFrame

[dant3]

+1 for execution context. It is very needed in Android/Fx/Swing apps to communicate with UI thread explicitly for example

[lihaoyi]

Presumably you'll only be communicating with the UI thread via Obss and Vars, and for those you could always write your own adapter to make those do things asynchronously. Asynchronous Rxs wouldn't work, and even right now (the first initialization is always synchronous on current thread).

Writing your own EC-based Obs/Var adapters should be straightforward and doesn't need to sit in "core" entwined with all the other stuff we have in there

[antonkulaga]

@Voltir , @lihaoyi is there any progress with 3.0 branch?

[Voltir]

@tindzk, @mkotsbak, @lihaoyi Im currently "borrowing" very heavily from MetaRx's approach for JS/JVM async code for 0.3.0 and I hope there are no objections with me outright lifting some stuff that seems good.

[tindzk]

@Voltir Sure, go ahead. Our code is actually largely inspired by Monix. Please let us know when you're done. I would be quite curious to see what you have come up with.

[mkotsbak]

Oprator support as I added to MetaRx would be nice.

[lihaoyi]

0.3.0 is out on maven central https://github.com/lihaoyi/scala.rx

[pocorall]

Thank you for your hard working! @lihaoyi