Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 17:57
    JimmyDead starred ReactiveX/RxGo
  • 13:12
    aweris starred ReactiveX/RxGo
  • 10:10
    rainbowMorelhahahah starred ReactiveX/RxGo
  • Jun 29 13:10
    dependabot[bot] closed #371
  • Jun 29 13:10
    dependabot[bot] commented #371
  • Jun 29 13:10

    dependabot[bot] on go_modules

    (compare)

  • Jun 29 13:10
    dependabot[bot] review_requested #373
  • Jun 29 13:10
    dependabot[bot] labeled #373
  • Jun 29 13:10
    dependabot[bot] labeled #373
  • Jun 29 13:10
    dependabot[bot] opened #373
  • Jun 29 13:10

    dependabot[bot] on go_modules

    Bump github.com/stretchr/testif… (compare)

  • Jun 28 08:21
    dayaftereh labeled #372
  • Jun 28 08:21
    dayaftereh assigned #372
  • Jun 28 08:21
    dayaftereh opened #372
  • Jun 27 20:43
    gevann starred ReactiveX/RxGo
  • Jun 27 17:17
    dayaftereh commented #342
  • Jun 26 11:38
    PepperBean starred ReactiveX/RxGo
  • Jun 26 06:54
    martinjirku starred ReactiveX/RxGo
  • Jun 24 13:10

    dependabot[bot] on go_modules

    (compare)

  • Jun 24 13:10
    dependabot[bot] closed #370
Artur Krysiak
@venth
Yep, and which branch we will develop and make stable. For instance when there will be new operator, shall it be implemented separately for v1 and v2? Wouldn’t be better to have just one branch?
Avelino
@avelino
@teivah You can open issues of upcoming migrations and deployment to version 2, to give visibility of next steps, break N issue, step by step to implement
v1 and v2 branch because semver (go module 1.11)
https://github.com/golang/go/wiki/Modules
Video content https://youtu.be/aeF3l-zmPsY
Teiva Harsanyi
@teivah
@avelino Alright!
Avelino
@avelino
Thanks man
Teiva Harsanyi
@teivah
what do you guys think about this assertion API: ReactiveX/RxGo#109
Avelino
@avelino
Hey @teivah , very very good work
9 new PR nice
Teiva Harsanyi
@teivah
@avelino thanks :)
Teiva Harsanyi
@teivah
@avelino Alright, goimports everywhere!
Avelino
@avelino
:D
Teiva Harsanyi
@teivah
yeah, we may have some conflicts...
most of my PR starts from the same branch
but once it is merged, we may have conflicts with the others because obv, they are not sync with upstream..
Avelino
@avelino
retro dependence :(
Teiva Harsanyi
@teivah
@avelino I fetched everything from upstream ;)
Artur Krysiak
@venth
Looks interesting:
https://github.com/google/wire/blob/master/README.md
Teiva Harsanyi
@teivah
I need also to integrate what we have in observer_mock.go in the assertion API (ReactiveX/RxGo#109) and makes something more generic
Teiva Harsanyi
@teivah
btw, @avelino what about posting a message in RxGo (official)/Lobby to inform people to come here?
if they did not follow the Github issue
Avelino
@avelino
send msg on channel @teivah pls
Teiva Harsanyi
@teivah
done ;)
I'm not a ReactiveX member so I don't known if people are going to listen to me but ok :)
Avelino
@avelino
thanks, I change channel title
Teiva Harsanyi
@teivah
my opinion about the future v2 of RxGo: https://github.com/ReactiveX/RxGo/issues/99#issuecomment-443816758
Artur Krysiak
@venth
@teivah
For the double subscription. In case of v2 second subscription would receive same elements of just sequence as the first?
Teiva Harsanyi
@teivah
well, to be discussed maybe but in RxJava for example if you create an observable from an array, the second subscription is going to receive the same elements as the first one
here we just lose the messages as it is sent in a channel and retrieved during the first subscription
(and there's no way to retry it for the time being)
Artur Krysiak
@venth
If we will create function create that would receive function as argument then we could overcome the channel issue
this function would get emitter as the argument and will be responsible for emitting sequence elements
Teiva Harsanyi
@teivah
you mean as an end-user or as a maintainer of RxGo?
Artur Krysiak
@venth
Either. Such a function ease implementation of plenty of operators
Like empty - just emit complete
Teiva Harsanyi
@teivah
yes agreed
Artur Krysiak
@venth
error emit error
abd so forth
Teiva Harsanyi
@teivah
but I'm just pointing out that the current behavior is not similar to what we have in the other Rx implementations
Artur Krysiak
@venth
That’s right. Current behavior doesn’t comply to other implementations
Teiva Harsanyi
@teivah
I know the philosophy is to be based as most as possible on Idiomatic Go code
yet, for this very use-case I don't really get why we should have something different in RxGo
just my opinion obviously
Artur Krysiak
@venth
I come along with you.
Teiva Harsanyi
@teivah
and obviously, if we change that in the v2, it has to be highlighted to make sure end-users understand that the behavior is different
Artur Krysiak
@venth
+1
Teiva Harsanyi
@teivah
We need to start thinking about how to handle hot observable: values are emitted regardless whether there is an actual subscription, multicasting (one item caught by several observer)