-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(core): expose UnknownActorRef #4929
feat(core): expose UnknownActorRef #4929
Conversation
🦋 Changeset detectedLatest commit: 54195ec The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
regardless; if this (or the other suggestion) makes sense, I'll go in and make the change and/or fix the type tests. |
Thank you for this! It seems like TS is complaining in some of the test files (you can run cc. @Andarist |
@davidkpiano I don't quite understand why the 3rd But I'm wary of attempting to change anything else without further review/feedback |
See #4931 for the "other problem" I mentioned above. |
There may be some overlap with #4932 |
@davidkpiano Yeah. I'll wait until #4932 is merged then retry on top of it. |
@boneskull It's merged; please merge |
looking |
9c0d042
to
d3e2a7b
Compare
@davidkpiano OK, I rebased, but changed my strategy. Please read updated issue description |
d3e2a7b
to
8c1226b
Compare
8c1226b
to
cdbaab6
Compare
`AnyActorRef` is problematic for some use cases, because the result of the `AnyActorRef['getSnapshot']` function is of type `any`. However, changing `AnyActorRef` to use a narrow type in `ActorRef`'s first type argument, `TSnapshot`, breaks conditional types which perform inference based on `TSnapshot`. This change introduces `UnknownActorRef`, which is like `AnyActorRef`, but is not intended to be inferred from in future conditional types. A consumer can use `UnknownActorRef` like so: ```ts const actor: UnknownActorRef = getSomeActor(); // inferred as `Snapshot<unknown>` const snapshot = actor.getSnapshot(); // do things w/ snapshot ``` `AnyActorRef` would return `any` from `actor.getSnapshot()`, which make it unsuitable for this use-case in a strictly-typed environment.
cdbaab6
to
a1ca784
Compare
@davidkpiano I've added a changeset for this. I'm calling it "patch" since it doesn't affect any functionality. Happy to change it |
AnyActorRef
is problematic for some use cases, because the result of theAnyActorRef['getSnapshot']
function is of typeany
.However, changing
AnyActorRef
to use a narrow type inActorRef
's first type argument,TSnapshot
, breaks conditional types which perform inference based onTSnapshot
.This change introduces
UnknownActorRef
, which is likeAnyActorRef
, but is not intended to be inferred from in future conditional types. A consumer can useUnknownActorRef
like so:AnyActorRef
would returnany
fromactor.getSnapshot()
, which make it unsuitable for this use-case in a strictly-typed environment.