Skip to content

Conversation

@grgbkr
Copy link
Contributor

@grgbkr grgbkr commented Apr 7, 2022

Also makes the "replicache" peer dependency optional (using peerDependenciesMeta) so npm doesn't automatically install "replicache" when "replicache-react" is intalled.

@grgbkr grgbkr requested a review from arv April 7, 2022 17:09
@grgbkr grgbkr changed the title feat: Update useSubscribe to accept Replicache or Pick<Replicache, 'subscribe'> so it can accepts ReflectClient feat: Update useSubscribe to accept Replicache or Pick<Replicache, 'subscribe'> so it can accept ReflectClient Apr 7, 2022
src/index.ts Outdated

export function useSubscribe<R extends ReadonlyJSONValue>(
rep: Replicache | null | undefined,
rep: Replicache | Subscribeable | null | undefined,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need both Replicache and Subscribeable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was debating this. I think it makes it more obvious to customers that they can pass Replicache here... it still not obvious that they can pass ReflectClient.

I think something like:
subscribable: Replicache | ReflectClient | null | undefined
might me more obvious.

},
"peerDependenciesMeta": {
"replicache": {
"optional": true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting.

"peerDependencies": {
"react": ">=16.0 <18.0",
"react-dom": ">=16.0 <18.0",
"replicache": ">=4.0.1 <10.0 || >7.0.0-beta <7.0.0 || >8.0.0-beta <8.0.0 || >9.0.0-beta <9.0.0"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we know why did this package need replicache as a dependency in the first place? It seems like since we are not constructing it, all we should need is the type, and only then at dev time... So it seems like this should have worked with replicache as a devDependency and nothing else.

Copy link
Contributor Author

@grgbkr grgbkr Apr 7, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could have always been an optional peer dependency (in older versions of npm all peer dependencies were optional). But we still need the peer dependency to specify what versions of replicache this is compatible with.

});
}

export type Subscribeable = Pick<Replicache, 'subscribe'>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I was thinking was actually describing the subscribe interface. But now that I see maybe why you didn't want to do that - the subscribe interface is large and detailed. It could also fall behind head of either Replicache or Reflect.

What if instead we have this package just directly depend on Replicache and Reflect and have the argument be Replicache|Reflect.

I think that is fine, it's not going to add to the compile size, or even the install size for our users -- it just means when we work on this we install both packages.

@arv
Copy link
Contributor

arv commented Nov 22, 2022

#38 supersedes this.

@arv arv closed this Nov 22, 2022
@arv arv deleted the grgbkr/subscribeable branch November 22, 2022 09:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

4 participants