profile
viewpoint
Josep M Sobrepere josepot @AdaptiveConsulting Barcelona

josepot/grid-styletr 5

Responsive React grid system built with styletron-react

AnnaKanska/stock-tracker-react-redux 1

Application allows you to select a specific stock and see information pertaining to it.

josepot/angularjs-book 1

Examples and Code snippets from the AngularJS O'Reilly book

josepot/AoC-2018 1

Advent of Code 2018

josepot/hn-react-redux 1

WIP submission for https://hnpwa.com

PR closed ReactiveX/rxjs

Fix/share replay ref count sync PR: blocked

Description: Bug fix: shareReplay with refCount sync sources shouldn't restart

Related issue (if exists): It addresses #5548

+22 -13

1 comment

2 changed files

josepot

pr closed time in 25 minutes

pull request commentre-rxjs/react-rxjs

feat: observables from connect* should complete

FTR: once this is merged I'm going to make a complete re-write of the tests. Having the kind of tests that we got until now it did make some sense while we were constantly making re-factors and API changes, but now the API has reached a point of maturity that I'm confident that we should only write tests against the public API. Also, the tests will now become a lot more descriptive.

josepot

comment created time in 6 hours

issue closedre-rxjs/react-rxjs

Create lower-level bindings that are "ECMAScript Observable" compliant

I've been thinking about this and I felt in love with the idea of creating a lower-level library that's not coupled to RxJS and that exposes a subset of the current Re-RxJS API, concretely it would expose:

  • connectObservable
  • connectFactoryObservable
  • shareLatest
  • SUSPENSE

Those bindings would be compatible with any implementation of the ECMAScript Observable spec, then Re-RxJS could use that library internally to provide the same API that it currently has.

Its API would also have a setObservable method that would receive an Observable implementation that it's compliant with the ECMAScript Observable spec.

Thoughts?

closed time in 6 hours

josepot

issue commentre-rxjs/react-rxjs

Create lower-level bindings that are "ECMAScript Observable" compliant

I'm going to close this issue in favor of a different one that will be about facilitating interoperability with other Observable libraries.

The thing is that right after I opened this issue, I did send a private message to Nicholas Jamieson (the RxJS maintainer, I'm not tagging him because I don't want to spam) and he sent me a TON of great resources, the best one is by far this post from his blog, for real @voliva @bhavesh-desai-scratch you should read it, it's pure gold.

josepot

comment created time in 6 hours

startedchrisguttandin/subscribable-things

started time in 6 hours

push eventre-rxjs/react-rxjs

Josep M Sobrepere

commit sha c2c159fdf4150ff32b1e1d61c7a1bcb627425878

feat: observables from connect* should complete

view details

push time in 6 hours

PR opened re-rxjs/react-rxjs

Reviewers
feat: observables from connect* should complete

I was thinking about the docs and how to explain why the observables returned from connectObservable and connectFactoryObservable do not complete and the more I tried to make sense of it, the less sense it made... Then I realized that we were in fact exposing an implementation detail of the underlying "react-observable" and that in many cases that could be very annoying for the consumers. So, this PR addresses that issue and now I'm finally happy with the API. :smile:

+100 -77

0 comment

13 changed files

pr created time in 6 hours

create barnchre-rxjs/react-rxjs

branch : feat/complete-connected-observables

created branch time in 6 hours

delete branch josepot/rxjs

delete branch : chore/groupby-remove-redundant-variable

delete time in 8 hours

pull request commentReactiveX/rxjs

fix: revert #5458

There was an existing test that attempted to test what's tested by the new test

I don't think so. Because the issue that this PR is solving only happens when the source completes synchronously upon subscription. AFAIK the current test:

'should not restart due to unsubscriptions if refCount is true when the source has completed

doesn't complete synchronously on its first subscription.

cartant

comment created time in 8 hours

Pull request review commentReactiveX/rxjs

fix: revert #5458

 describe('shareReplay operator', () => {     expectSubscriptions(source.subscriptions).toBe(sourceSubs);   }); +  it('should not restart a synchronous source due to unsubscriptions if refCount is true when the source has completed', () => {+    // The test above this one doesn't actually test completely synchronous

I'm 99.9% sure that the test above doesn't have anything to do with the issue that this revert is trying to fix, because the issue with that revert only happens when refCount is set to true. So, I'm pretty sure that the test above does its job correctly.

cartant

comment created time in 8 hours

pull request commentReactiveX/rxjs

fix: revert #5458

FYI @cartant @benlesh #5550 also adds the test and it prevents a possible edge-case that I explained in this comment.

cartant

comment created time in 9 hours

PR opened ReactiveX/rxjs

Fix/share replay ref count sync

Description: Bug fix: shareReplay with refCount sync sources shouldn't restart

Related issue (if exists): It addresses #5548

+22 -13

0 comment

2 changed files

pr created time in 9 hours

issue openedReactiveX/rxjs

shareReplay with refCount restarts with synchronous sources

Bug Report

Current Behavior shareReplay with refCount restarts with synchronous sources

Reproduction

  • REPL or Repo link:

I can't use stackblitz because since the latest release doesn't have #5521 then that bug masks the other one, but with the current code on master, this would happen:

const foo$ = from([1, 2, 3, 4, 5]).pipe(
  shareReplay({ refCount: true, bufferSize: 1})
)

foo$.subscribe(x => {
  console.log(x);
})
// 1
// 2
// 3
// 4
// 5

foo$.subscribe(x => {
  console.log(x);
})
// 1
// 2
// 3
// 4
// 5

Expected behavior The second subscribe should only emit 5

Possible Solution In this line also checked that the subscription isn't closed:

if (subscription && !subscription.closed && useRefCount && refCount === 0) {

Additional context See this comment from @leggechr and the comments afterwords.

created time in 9 hours

create barnchjosepot/rxjs

branch : fix/shareReplay-refCount-sync

created branch time in 9 hours

pull request commentReactiveX/rxjs

chore(shareReplay): remove redundant variable `isComplete`

Ups! @leggechr I found the issue!

Consider the following code:

        subscription = source.subscribe({
          next(value: T) {
            subject!.next(value);
          },
          error(err: any) {
            hasError = true;
            subject!.error(err);
          },
          complete() {
            subscription = undefined;
            subject!.complete();
          }
        });
      }

if the source completes synchronously upon subscription, for instance:

of(1).pipe(
  shareReplay({ refCount: true, bufferSize: 1 })
)

then the subscription is set first to undefined and then it's set to the "closed" subscription :facepalm: That's it.

josepot

comment created time in 10 hours

pull request commentReactiveX/rxjs

chore(shareReplay): remove redundant variable `isComplete`

I could be wrong, but I can only think of one edge-case where this change would alter the behavior, and if that's what happened, then I think that this change actually fixed a bug... I could be wrong, though :sweat_smile:. This is the only thing that I can come up with that could alter the previous behavior:

With the previous code: If the refCount drops to zero and the source hasn't completed, then the first thing that happens is the unsubscription from the source. If that tear-down logic causes for the source to complete while it's being unsubscribed from... :exploding_head: then that would set the flag isComplete to true... So, the next time that a new subscriber comes, then there is a new subscription to the source, however the flag isComplete is still set to true... But that wouldn't be accurate, right? So, in this hypothetical case, if the refCount drops to zero again but the new subscription against source hasn't completed, since the flag is saying that it did complete, then it won't unsubscribe from the source.

This is the only change of behavior that I can come up with, and if that's the case, then I think that the new code is fixing a bug?

I'm sure that I must be missing something, though.

josepot

comment created time in 13 hours

pull request commentReactiveX/rxjs

chore(shareReplay): remove redundant variable `isComplete`

Hi @leggechr, I'm very sorry that this PR changed the behavior. I think that I know what's happening, my bad!

I'm a bit busy right now, but in a few hours I will get to this. I will add a new test for this use case and I will fix the code. Again, I'm very sorry that I broke this :pray:. I actually thought that this was the expected behavior.

josepot

comment created time in 14 hours

delete branch re-rxjs/eslint-plugin-react-rxjs

delete branch : feat/no-connect-in-components

delete time in a day

push eventre-rxjs/eslint-plugin-react-rxjs

Josep M Sobrepere

commit sha 2ba4c25a2f205e5f1db84b4601fb0d690e284885

connect-in-components -> no-connect-in-components

view details

push time in a day

startedlukeed/astray

started time in a day

issue closedre-rxjs/react-rxjs

ESLint rule to prevent `connectObservable` and `connectFactoryObservable` being used inside components

I think that a common pitfall that new-comers will experience is that they may inadvertently use connectObservable/connectFactoryObservable from inside a functional component.

I think that we should create a ESLint rule so that developers don't fall for that mistake. Any volunteers? cough @voliva cough

I think that as a first implementation something that just checks that the connector functions are being called from the "root scope" (not inside a function) should be enough? :thinking:

Also, I think that the ESLint rule should be an error, not a warning.

closed time in a day

josepot

issue commentre-rxjs/react-rxjs

ESLint rule to prevent `connectObservable` and `connectFactoryObservable` being used inside components

I'm closing this issue, let's continue the conversation in that PR/repo. Once again, thanks a lot @voliva !

josepot

comment created time in a day

issue commentre-rxjs/react-rxjs

ESLint rule to prevent `connectObservable` and `connectFactoryObservable` being used inside components

It's so weird that you weren't able to push the code... Anyways, I have made the repo public, then I have put the commit-history of your personal repo into that one, and then I've opened this PR.

josepot

comment created time in a day

issue commentre-rxjs/react-rxjs

ESLint rule to prevent `connectObservable` and `connectFactoryObservable` being used inside components

It looks awesome, my only reservation is with the name of the rule... I think that instead of connect-in-components it should be named no-connect-in-components. I think that name is a bit more consistent with other standard eslint-rules, e.g. no-await-in-loop, no-console, no-import-assign, etc

josepot

comment created time in a day

create barnchre-rxjs/eslint-plugin-react-rxjs

branch : main

created branch time in a day

issue commentre-rxjs/react-rxjs

ESLint rule to prevent `connectObservable` and `connectFactoryObservable` being used inside components

This is awesome! Thanks a lot @voliva !

I tried pushing the code so far to the re-rxjs organization but I couldn't

:thinking: I can see that you created a private-repo under the org:

image

but you can't push to it? Weird... I will look into the settings to make sure that you can do these things.

josepot

comment created time in a day

issue commenttc39/proposal-observable

Moving to an API with AbortSignal

@benjamingr

I can happily link to the summit discussion and James' PR if you want more info.

Yes, please. If it's not going to take too much of your time, I would be very interested. Thank you!

Node does not implement the timer spec (web timers) and its timers are not spec compliant and behave differently from web timers (both in edge cases and in "obvious" stuff - for example the return value of setInterval is a number in browsers but an object in Node, browser timers can take a string and Node's can't etc).

Sorry, I guess that I didn't explain myself very well. I knew that. What I meant to say is that Node is more than ECMAScript. At least in the sense that Node's "goal" was to bring to the server the same way of leveraging JS that we got in the web, and for doing that it put the event-loop at the forefront (I could be wrong, but I think that ECMAScript has no references to the event-loop... And yes, I know that these days Node also supports Worker Threads :slightly_smiling_face:). But hopefully you get what I'm trying to say. At least in the way that I see it: Node is more than ECMAScript and it "takes inspiration" from the Web, and that's ok, it's its nature.

Node supporting AbortController is about there being (one) supported unified way to cancel asynchronous actions in code. This means I can for example convert my promises code to RxJS or my async iterator code to RxJS and not have to change the way cancellation works throughout. It also lets me mix-and-match RxJS code (as an example) in a non-Rx code base in a clean-ish way.

I think that this is amazing :heart_eyes: and I'm very curious to learn more about it. In fact, I think that this is so incredibly awesome that I hope that TC39 tries to find a way to bring this unified way to cancel async actions to ECMAScript :pray:

Ups! I just re-read @benlesh first message and it seems that this is exactly what he was asking for :facepalm::

a proposal around creating a standard cancellation semantic should be prioritized (probably over this proposal)

I'm so sorry... I read the title, I looked at the code-snipped and I guess that I skipped the most important part. I'm so sorry. I will see myself out of here, and will let you continue the conversation. Sorry for the noise.

benlesh

comment created time in a day

startedcartant/rxjs-interop

started time in a day

startedsindresorhus/ponyfill

started time in a day

created tagre-rxjs/react-rxjs

tagv3.0.0-alpha.1

React bindings for RxJS

created time in a day

release re-rxjs/react-rxjs

v3.0.0-alpha.1

released time in a day

created tagre-rxjs/react-rxjs

tagRe-RxJS.v0.2.0-alpha.1

React bindings for RxJS

created time in a day

created tagre-rxjs/react-rxjs

tagRe-RxJS.v0.2.0-alpha.2

React bindings for RxJS

created time in a day

created tagre-rxjs/react-rxjs

tagRe-RxJS.v0.2.0-alpha.3

React bindings for RxJS

created time in a day

created tagre-rxjs/react-rxjs

tagRe-RxJS.v0.2.0-alpha.4

React bindings for RxJS

created time in a day

created tagre-rxjs/react-rxjs

tagRe-RxJS.v0.2.0-alpha.5

React bindings for RxJS

created time in a day

created tagre-rxjs/react-rxjs

tagRe-RxJS.v0.2.0-alpha.6

React bindings for RxJS

created time in a day

created tagre-rxjs/react-rxjs

tagRe-RxJS.v0.2.0-alpha.0

React bindings for RxJS

created time in a day

push eventre-rxjs/react-rxjs

Josep M Sobrepere

commit sha 6917761574b77f8fd34a89fab9278f32d5eb0141

Re-RxJs -> React-RxJS fix broken links

view details

push time in 2 days

push eventre-rxjs/re-rxjs

Josep M Sobrepere

commit sha e689b573c07d050e5aef05ab9ba118e5cc112f78

Re-RxJs -> React-RxJS

view details

push time in 2 days

issue closedjarlah/react-rxjs

Would you consider allowing the Re-RxJS team to use this package name?

Hi @jarlah !

My name is Josep and I'm the creator of Re-RxJS. Re-RxJS is the result of lots of hours invested into trying to come up with a set of react-rxjs bindings that take full advantage of React latest features (hooks, Suspense and Concurrent Mode). However, we haven't published our first stable release yet.

Re-RxJS takes a different approach than React-RxJS does, because by default our bindings do not put flux-like stores at the forefront. It's still possible to use them, of course, but we don't wan't to have them as first-class citizens of these bindings. Another important difference is the fact that we are able to fully leverage React-Suspense and React Concurrent Mode features like useTransition.

Also, as of today, Re-RxJS is the only set of bindings that -while using state that lives outside of React- are able to work without causing tearing issues on CM.

We have not announced the library yet, but we are planning to do that soon, as soon as we publish our first stable release :slightly_smiling_face:.

The thing is that we are not very happy with the name re-rxjs :grimacing: and the name that we really wished we had is react-rxjs. Looking at the npm-stats, I've noticed the low number in the "weekly download" section and I have also noticed that the latest release was 8 months ago. So, I was wondering if you would be so kind to let us publish our first stable version on the react-rxjs package :pray:. We would do that using version 3.0.0, and of course: we wouldn't unpublish any of the versions that have been published so far. Also, if version 2 needed further patches or minor updates we would be more than happy to let you handle those, of course. And lastly -regardless of what your answer is to this inquiry- I would love to get feedback from you on Re-RxJS and to have you as a contributor.

Thanks,

Josep

closed time in 2 days

josepot

issue commentjarlah/react-rxjs

Would you consider allowing the Re-RxJS team to use this package name?

for me, I really don't care. I would never ever use my own project for anything. You know when you have worked for ages, and you look back and wish you didn't look back? This project is something I would see if I looked back. I regret implementing it, and publishing it.

But help me out here, what could I call it instead? react-flux-rxjs? Something like that ? I have no idea how I would rename my npm package, and I would really not waste any of my energy on finding out how I could. I would even resist to run some commands for it. The simplest for me would just be to delete the thing from npmjs.

Hi Jarl,

First of: Thanks a lot for getting back to me so quickly and for being so cooperative. For real, thank you so much!

Also, I'm very-sorry if my comment came across as me being judgmental. I don't think that you did anything wrong. Also, it wouldn't be fair to judge a project that got started 3 years ago with today's eyes.

Thanks,

Josep

josepot

comment created time in 2 days

issue commenttc39/proposal-observable

Moving to an API with AbortSignal

It's very much an unfortunate name

@ljharb could you please elaborate a little bit more on this? I'm worried that maybe I'm not understanding your concerns due to the fact that English is not my first language. At first I thought that perhaps it was because the term "abort" had some sort of "insensitive" or "inconsidered" connotations and maybe I wasn't aware of that. So, I ran it through alexjs.com and it didn't give me any warnings. So, now I'm really wondering why do you find it to be such an unfortunate name.

i think it's a bad idea for node to land it

Do you think that it's a bad idea that they land it under that name, or you also have reservations with the behavior of that API?

I'm sure that I must be missing a lot of context, so please forgive me if what I'm about to say is not accurate.

The only thing that does worry me about @benlesh proposal is the fact that currently the AbortSignal API is part of the DOM spec. I'm of the opinion that it makes a lot of sense for NodeJS to adopt it, because from the point of view of Node it's ok to borrow APIs from the DOM (e.g: setTimeout, setInterval).

However, I think that if we want for the Observable proposal to work with AbortSignal (FTR: I would love that!), then I suppose that would require to first submit a proposal-abort-signal (or something with a different name but the same behavior) to TC39?

benlesh

comment created time in 2 days

issue openedre-rxjs/re-rxjs

Create lower-level bindings that are "ECMAScript Observable" compliant

I've been thinking about this and I felt in love with the idea of creating a lower-level library that's not coupled to RxJS and that exposes a subset of the current Re-RxJS API, concretely it would expose:

  • connectObservable
  • connectFactoryObservable
  • shareLatest
  • SUSPENSE

Those bindings would be compatible with any implementation of the ECMAScript Observable spec, then Re-RxJS could use that library internally to provide the same API that it currently has.

created time in 2 days

issue openedre-rxjs/re-rxjs

ESLint rule to prevent `connectObservable` and `connectFactoryObservable` being used inside components

I think that a common pitfall that new-comers will experience is that they may inadvertently use connectObservable/connectFactoryObservable from inside a functional component.

I think that we should create a ESLint rule so that developers don't fall for that mistake. Any volunteers? cough @voliva cough

I think that as a first implementation something that just checks that the connector functions are being called from the "root scope" (not inside a function) should be enough? :thinking:

Also, I think that the ESLint rule should be an error, not a warning.

created time in 2 days

delete branch josepot/rxjs

delete branch : bug-fix/share-replay

delete time in 2 days

issue openedjarlah/react-rxjs

Would you consider allowing the Re-RxJS team to use this package name?

Hi @jarlah !

My name is Josep and I'm the creator of Re-RxJS.

We've put a lot of work into creating a set of react-rxjs bindings that take full advantage of React latest features (hooks, Suspense and Concurrent Mode), and we are about to publish our first stable release.

Re-RxJS takes a different approach than React-RxJS, because by default our bindings do not rely on a central store. Another important difference is the fact that we are able to fully leverage React-Suspense and CM.

Also, as of today, Re-RxJS is the only set of bindings that -while using state that lives outside of React- are able to work without causing tearing issues on CM..

We have not announced the library yet, but we are planning to do that soon, as soon as we publish our first stable release :slightly_smiling_face:.

The thing is that we are not very happy with the name re-rxjs :grimacing: and and the name that we really wished we had is react-rxjs. Looking at the npm-stats, I've noticed the low number in the "weekly download" section. So, I was wondering if you would be so kind to let us publish our first stable version on the react-rxjs package :pray:. We would do that using version 3.0.0, and of course: we wouldn't unpublish any of the versions that have been published so far. Also, if version 2 needed further patches or minor updates we would be more than happy to let you handle those, of course. And lastly -regardless of what answer is to this inquiry- I would love to get feedback from you on Re-RxJS and to have you as a contributor.

Thanks,

Josep

created time in 3 days

created tagre-rxjs/re-rxjs

tagv0.2.0-alpha.6

React bindings for RxJS

created time in 3 days

release re-rxjs/re-rxjs

v0.2.0-alpha.6

released time in 3 days

delete branch re-rxjs/re-rxjs

delete branch : v0.2.0-alpha.6

delete time in 3 days

push eventre-rxjs/re-rxjs

Josep M Sobrepere

commit sha 077b7af4f6adc6e6a3b4942954a7e96176292873

fix(types): prevent shareLatest from leaking BehaviorObservable

view details

Josep M Sobrepere

commit sha 12e38d2cb3ed678d9a8e8c7aa085e9e89739dbb2

chore: cleanup code

view details

Josep M Sobrepere

commit sha 0460b9164f08964da1fcf055a92bf009bb5296c4

docs: Improve README and JSDocs

view details

Josep M Sobrepere

commit sha d84dfd0b413ecd65881e6355262259ae5003f388

v0.2.0-alpha.6

view details

push time in 3 days

PR merged re-rxjs/re-rxjs

Reviewers
V0.2.0 alpha.6

I'm creating this release because:

  • shareLatest was leaking the internal BehaviorObservable type
  • When I published alpha.5 I forgot to update a reference in the README to distinctShareReplay and AFAIK the only way to update the docs on npm is to publish a patch... So, I took this chance to further improve the README and the JSDocs.
+57 -38

0 comment

7 changed files

josepot

pr closed time in 3 days

PR opened re-rxjs/re-rxjs

Reviewers
V0.2.0 alpha.6

I'm creating this release because:

  • shareLatest was leaking the internal BehaviorObservable type
  • When I published alpha.5 I forgot to update a reference in the README to distinctShareReplay and AFAIK the only way to update the docs on npm is to publish a patch... So, I took this chance to further improve the README and the JSDocs.
+57 -38

0 comment

7 changed files

pr created time in 3 days

create barnchre-rxjs/re-rxjs

branch : v0.2.0-alpha.6

created branch time in 3 days

issue closedre-rxjs/re-rxjs

v0.2.0

I think that we've almost at a point where I would feel good releasing v0.2.0 of this library.

Things that I would like to discuss before v0.2.0 is released:

  • I've got used to the name distinctShareReplay, but I hate it. I think that it's a horrible name... I'm actually considering the idea of coining a term for the kind of Observable that it generates (like BehaviorObservable or ReactObservable or WHATEVER) and then renaming the operator to something like asReactObservable or asBehaviorObservable.

I'm also starting to wonder whether this operator should be exposed in the first place... But I think that it should. Because we know from experience that if we don't expose it, then most of the users of this library will have to create their own custom shareReplay, and the worst part is that it's not even possible to create the custom shareReplay that would work best with this library by using any of the overloads of the current RxJS shareReplay... So, yeah, I think that it should be exposed, but not with that name... Also, maybe we should only export the "customShareReplay" behavior without the distinct? and then we could simply call it shareLatest? :thinking: Or maybe we could just name it shareLatest and that's it (with the distinct behavior still on it)?

I won't release v0.2.0 until I'm not happy with this.

There are 2 other things that I would like to happen before we release v0.2.0:

  1. use docosaurus to generate a site for https://re-rxjs.org or for https://rerxjs.org (I bought both domains). Ideally I would like to have in that site similar to the one that recoil.js has, at least with the following sections:
  • Introduction
  • Basic Tutorial
  • API Reference
  1. A blog-post announcing the release of this library.

I've been working on those 2 items, but I will need help... I will create separate issues for those 2. Oh, the docs-site would live under a completely different repo.

closed time in 3 days

josepot

issue commentre-rxjs/re-rxjs

v0.2.0

I'm closing this because I'm really happy with the latest alpha release. I will create separate issues for the other stuff. Also, I will try to make those issues more organized (and less chaotic).

josepot

comment created time in 3 days

push eventre-rxjs/re-rxjs

Josep M Sobrepere

commit sha d5e7848aafe407b1522010fccdb7a7a1b8c10b48

fix(README): update old reference to distinctShareReplay

view details

push time in 3 days

created tagre-rxjs/re-rxjs

tagv0.2.0-alpha.5

React bindings for RxJS

created time in 3 days

release re-rxjs/re-rxjs

v0.2.0-alpha.5

released time in 3 days

push eventre-rxjs/re-rxjs

Josep M Sobrepere

commit sha 2f37cf6c2d3eaaf11698d9c2e8a0e07e39287aeb

v0.2.0-alpha.5

view details

push time in 3 days

push eventre-rxjs/re-rxjs

Josep M Sobrepere

commit sha 455b511999db26710cd1775e50684b080abb4d8f

feat(shareLatest): removing distinctShareReplay in favor of shareLatest

view details

push time in 3 days

PR merged re-rxjs/re-rxjs

Reviewers
feat(shareLatest): removing distinctShareReplay in favor of shareLatest

I'm so so so so so happy about these changes that I can't wait to get them merged! :heart_eyes:

These refactor addresses what we've discussed on #41 . I think that we finally managed to get this right. Thanks a lot @voliva for the feedback and the help!

FTR: our tests are pretty bad for documenting the behavior of the API and that's something that we should improve ASAP. However, they are great for addressing refactors like this one.

+142 -226

2 comments

21 changed files

josepot

pr closed time in 3 days

push eventre-rxjs/re-rxjs

Josep M Sobrepere

commit sha 7b53b2157ac3cb21f547ca821dfd7259e29eaa21

feat(shareLatest): removing distinctShareReplay in favor of shareLatest

view details

push time in 3 days

Pull request review commentre-rxjs/re-rxjs

feat(shareLatest): removing distinctShareReplay in favor of shareLatest

 import { ConnectorOptions, defaultConnectorOptions } from "./options"  * observable.  *  * @param observable Source observable to be used by the hook.- * @param options ConnectorOptions:- *  - unsubscribeGraceTime (= 200): Amount of time in ms that the shared- *    observable should wait before unsubscribing from the source observable- *    when there are no new subscribers.- *  - compare (= Object.is): Equality function.+ * @param unsubscribeGraceTime (= 200): Amount of time in ms that the shared+ *        observable should wait before unsubscribing from the source observable+ *        when there are no new subscribers.  */ export function connectObservable<T>(   observable: Observable<T>,-  options?: ConnectorOptions<T>,+  unsubscribeGraceTime = 200, ) {-  const _options = {-    ...defaultConnectorOptions,-    ...options,-  }-  const sharedObservable$ = distinctShareReplay(_options.compare)(-    concat(observable, NEVER),-  )-+  const sharedObservable$ = shareLatest<T>(false)(concat(observable, NEVER))

yes, indeed! thanks!

josepot

comment created time in 3 days

push eventre-rxjs/re-rxjs

Josep M Sobrepere

commit sha bb83721d790d26c863b640ae84a8a27f46d87171

feat(shareLatest): removing distinctShareReplay in favor of shareLatest

view details

push time in 3 days

pull request commentre-rxjs/re-rxjs

feat(shareLatest): removing distinctShareReplay in favor of shareLatest

And on top of that: have a look at the new bundle-size :heart_eyes: !!! Yes! this is it! This should be the final API for v0.2.0, yes! finally!

josepot

comment created time in 4 days

push eventre-rxjs/re-rxjs

Josep M Sobrepere

commit sha 035a4dce619ebe79baa93bd54304059afba36441

feat(shareLatest): removing distinctShareReplay in favor of shareLatest

view details

push time in 4 days

PR opened re-rxjs/re-rxjs

Reviewers
feat(shareLatest): exposing shareLatest

I'm so so so so so happy about these changes that I can't wait to get them merged! :heart_eyes:

These refactor addresses what we've discussed on #41 . I think that finally we managed to get this right. Thanks a lot @voliva for the feedback and the help!

FTR: our tests are pretty bad for documenting the behavior of the API and that's something that we should improve ASAP. However, they are great for addressing refactors like this one.

+133 -219

0 comment

21 changed files

pr created time in 4 days

create barnchre-rxjs/re-rxjs

branch : feat/shareLatest-refactor

created branch time in 4 days

issue commentre-rxjs/re-rxjs

v0.2.0

I've been thinking a lot about this and I think that I've finally realized what the issue is here. I will try to summarize it:

  • The distinctUntilChanged behavior should not be baked into the current distinctUntilChanged
  • connectObservable and connectFactoryObservable should not take the compareFn option at all.
  • The internal react-enhancer can (and should) apply a distinctUntilChanged(Object.is) in order to prevent unnecessary React.setState calls.
  • An enhancer that we could name shareLatest could (and I think that should) be exposed, and its behavior would be the equivalent of:
const shareLatest = <T>() => (
  source$: Observable<T>,
): Observable<T> =>
  source$.pipe(
    multicast(() => new ReplaySubject<T>(1)),
    refCount(),
  )

I'm working on that... I can't wait to get that done!

josepot

comment created time in 4 days

delete branch josepot/rxjs-etc

delete branch : feat/sortedMergeMap

delete time in 4 days

issue openedre-rxjs/re-rxjs

v0.2.0

I think that we've almost at a point where I would feel good releasing v0.2.0 of this library.

Things that I would like to discuss before v0.2.0 is released:

  • I've got used to the name distinctShareReplay, but I hate it. I think that it's a horrible name... I'm actually considering the idea of coining a term for the kind of Observable that it generates (like BehaviorObservable or ReactObservable or WHATEVER) and then renaming the operator to something like asReactObservable or asBehaviorObservable.

I'm also starting to wonder whether this operator should be exposed in the first place... But I think that it should. Because we know from experience that if we don't expose it, then most of the users of this library will have to create their own custom shareReplay, and the worst part is that it's not even possible to create the custom shareReplay that would work best with this library by using any of the overloads of the current RxJS shareReplay... So, yeah, I think that it should be exposed, but not under this name... Also, maybe we should only export the "customShareReplay" behavior without the distinct? and then we could simply call it shareLatest? :thinking: Or maybe we could just name it shareLatest and that's it (with the distinct behavior still on it)?

I won't release v0.2.0 until I'm not happy with this.

There are 2 other things that I would like to happen before we release v0.2.0:

  1. use docosaurus to generate a site for https://re-rxjs.org or for https://rerxjs.org (I bought both domains). Ideally I would like to have in that site similar to the one that recoil.js has, at least with the following sections:
  • Introduction
  • Basic Tutorial
  • API Reference
  1. A blog-post announcing the release of this library.

I've been working on those 2 items, but I will need help... I will create separate issues for those 2. Oh, the docs-site would live under a completely different repo.

created time in 4 days

release re-rxjs/re-rxjs

v0.2.0-alpha.4

released time in 4 days

created tagre-rxjs/re-rxjs

tagv0.2.0-alpha.4

React bindings for RxJS

created time in 4 days

push eventre-rxjs/re-rxjs

Josep M Sobrepere

commit sha 8ebcea5b6d17ad51e93710d63fdfbf7797470f21

v0.2.0-alpha.4

view details

push time in 4 days

push eventre-rxjs/re-rxjs

Josep M Sobrepere

commit sha baf625c4c39d33b0c9465ad08b1384d0e028186f

Upgrade dev-dependencies

view details

push time in 4 days

issue closedre-rxjs/re-rxjs

Use TS Doc on public API

Use JSDoc for public API methods. Great for discoverability with editors that support the syntax

closed time in 4 days

bhavesh-desai-scratch

issue commentre-rxjs/re-rxjs

Use TS Doc on public API

Addressed in #40

bhavesh-desai-scratch

comment created time in 4 days

PR merged re-rxjs/re-rxjs

Reviewers
docs: add TSDoc to public API
+102 -14

1 comment

9 changed files

voliva

pr closed time in 4 days

push eventre-rxjs/re-rxjs

Víctor Oliva

commit sha 1a94226d4a50b25838e6c1f879d13bc2a7b397d8

docs: add TSDoc to public API

view details

push time in 4 days

Pull request review commentre-rxjs/re-rxjs

docs: add TSDoc to public API

 import { BehaviorObservable } from "./BehaviorObservable" import { SUSPENSE } from "./SUSPENSE" import { useObservable } from "./useObservable" +/**+ * Accepts: A factory function that returns an Observable.+ *+ * Returns [1, 2]+ * 1. A React Hook function with the same parameters as the factory function.+ *  This hook will yield the latest update from the observable returned from+ *  the factory function.+ * 2. A shared replayable version of the observable generated by the factory+ *  function that can be used for composing other streams that depend on it.+ *  This observable is disposed when its refCount goes down to zero.+ *+ * @param getObservable Factory of observables. The arguments of this function+ *  will be the ones used in the hook.+ * @param options ConnectorOptions:+ *  - unsubscribeGraceTime (= 200): Amount of time in ms that the shared+ *    observable should wait before unsubscribing from the source observable+ *    when there are no new subscribers.+ *  - compare (= Object.is): Equality function.+ */ export function connectFactoryObservable<   A extends (number | string | boolean | null)[],   O >(   getObservable: (...args: A) => Observable<O>,-  _options?: ConnectorOptions<O>,+  options?: ConnectorOptions<O>,

nice! thanks!

voliva

comment created time in 4 days

PR closed cartant/rxjs-etc

feat(concatEagerMap): add operator

As discussed in the "Allow concurrency in concatMap" issue of RxJS, this could be a nice operator to have. ~I'm not happy with the name that I came up with, so I'm more than open to suggestions.~* Also, the tests are not very complete... I'm more than willing to add more. Just let me know what other things should be tested and I will add the tests.

(* I just renamed it from sortedMergeMap to concatEagerMap based on this. I'm still open to suggestions, though)

+422 -0

4 comments

2 changed files

josepot

pr closed time in 5 days

pull request commentcartant/rxjs-etc

feat(concatEagerMap): add operator

Thanks a lot for the detailed answer.

I'm closing this in favor of your implementation. The main reason why I wrote it using new Observable is because I thought that could possibly make the transition to core, but after reading your answer I do realize that this was an unnecessary premature optimization.

Also, about whether concatMap should accept the concurrent parameter: another reason not to change its current signature is that -generally speaking- operators should do "one thing and do it well". So, yep, I can see how it would be a lot less confusing to have the normal concatMap behave in the way that it currently does, and then have its "eager" version for when this behavior is needed.

Thanks a lot for taking the time to give me such a detailed answer.

josepot

comment created time in 5 days

pull request commentcartant/rxjs-etc

feat(concatEagerMap): add operator

nice! Thanks for sharing that. I like the name of your operator a lot better :sweat_smile:

That's cool! TIL about materialize :heart_eyes: !!

I don't mind closing this PR in favor of your implementation, of course.

Your implementation is lot clearer and declarative, which makes it less prone to bugs, and a lot easier to understand and maintain. My implementation, on the other hand, is a lot more imperative/complicated. However, mine uses less operators. Do you think that can make a difference in terms of performance?

Lastly, I can help myself from insisting (for the last time, I promise) on the idea that if we take into account what's the behavior that's expected from concat -rather than thinking about how it's currently implemented-, then I think that it would make sense to allow for concatMap to receive the concurrent parameter. I mean, considering that:

concatMapEager()   => concatMapEager(Infinity)`
concatMapEager(1) => concatMap()`

Wouldn't it make sense that

concatMap() => concatMapEager(1)
concatMap(Infinity) => concatMapEager()

?

josepot

comment created time in 6 days

issue commentReactiveX/rxjs

Allow concurrency in `concatMap`

@jakovljevic-mladen yes, that's almost exactly what we are talking about.

The only difference is that concatEager does not take as a parameter the maximum number of input Observables being subscribed to concurrently, while the operator that we are describing it does.

Yesterday night I took some time to carefully implement a version of this operator for JS. Today I've added a few tests and I've opened this PR against rxjs-etc. That operator has Infinity as the default number of concurrently opened subscriptions, which means that by default it behaves like the java concatEager operator. However, if changed that number to 1, then it would behave exactly like concatMap... Meaning that the operator enables the behavior that @JosephSilber is looking for.

JosephSilber

comment created time in 6 days

push eventjosepot/rxjs-etc

Josep M Sobrepere

commit sha 6fb86cbf5425f0445de517b99f6bbb3efb5e53c7

feat(concatEagerMap): add operator

view details

push time in 6 days

PR opened cartant/rxjs-etc

feat(sortedMergeMap): add operator

As discussed in the "Allow concurrency in concatMap" issue of RxJS, this could be a nice operator to have. I'm not happy with the name that I came up with, so I'm more than open to suggestions. Also, the tests are not very complete... I'm more than willing to add more. Just let me know what other things should be tested and I will add the tests.

+422 -0

0 comment

2 changed files

pr created time in 6 days

push eventjosepot/rxjs-etc

Josep M Sobrepere

commit sha a339d0e224e1dbba2367a7e3984b949817d3e737

feat(sortedMergeMap): add operator

view details

push time in 6 days

create barnchjosepot/rxjs-etc

branch : feat/sortedMergeMap

created branch time in 6 days

push eventjosepot/rxjs-utils

Josep M Sobrepere

commit sha a54f66426cfa0b94e51e7bb0bbfde0e976f51a95

v0.15.2 fix concurrentConcat* implementations

view details

push time in 6 days

push eventjosepot/rxjs-utils

Josep M Sobrepere

commit sha 9a97fe8e5f4958ef76ec1e628588fadeddafcb32

v0.15.2 fix concurrentConcat* implementations

view details

push time in 6 days

push eventre-rxjs/re-rxjs

Víctor Oliva

commit sha ad1f6ccbea9507db115b8261620a6a6b028de64a

test: updates on connectObservable, suspense

view details

push time in 6 days

PR merged re-rxjs/re-rxjs

Reviewers
test: updates on connectObservable, suspense

This PR covers the rest of test improvements identified in #20

For the "it works in suspense" what I did is in connectObservable cover the part where it integrates with react (by using exclusively SUSPENSE), and then all the "sugar operators" are tested in isolation.

IMPORTANT -> I made a change to switchMapSuspended which I think it makes it a bit smarter. I ran into that when thinking on tests for that operator.

As it's currently in main branch, if a new update comes from the source stream before the inner stream has published anything, that inner stream will get cancelled, a new SUSPENSE will be emitted and a new subscription to the inner stream will be made.

I think it would make sense for switchMapSuspended for only emitting one single SUSPENSE while there are no new data. I guess it doesn't hurt for it to emit more than one (or does it?), so I put this feature in a separate commit if we decide we don't want this behaviour and the commit can be dropped. Maybe you want it in another PR?

+207 -39

1 comment

4 changed files

voliva

pr closed time in 6 days

startedcartant/rxjs-etc

started time in 6 days

fork josepot/rxjs-etc

Observables and operators for RxJS

fork in 6 days

push eventjosepot/rxjs-utils

Josep M Sobrepere

commit sha 24f0dba88cdcce9f4f6cf6ce246ad55e5cda966a

v0.15.1 fix concurrentConcat* implementations

view details

push time in 6 days

more