ShardKey
Defined in: src/cluster/sharding/ShardKey.ts:22
Named, type-tagged identity for a sharded entity type — the sharding
counterpart to SingletonKey. Ties the typeName string and the
message type together so start(), entityRefFor() and startProxy() hand
back a correctly-typed ActorRef without the caller repeating either.
class UserActor extends PersistentActor<UserCommand, UserEvent, UserState> { static readonly shard = ShardKey.of<UserCommand>('user', (command) => command.userId);}
const users = cluster.sharding.start(UserActor);const user = cluster.sharding.entityRefFor(UserActor, 'user-42');The explicit type argument is load-bearing: without it the key infers
ShardKey<unknown> and every ref taken from it degrades to
ActorRef<unknown>.
Type Parameters
Section titled “Type Parameters”TCommand
Section titled “TCommand”TCommand = unknown
Constructors
Section titled “Constructors”Constructor
Section titled “Constructor”new ShardKey<
TCommand>(typeName,extractEntityId?):ShardKey<TCommand>
Defined in: src/cluster/sharding/ShardKey.ts:26
Parameters
Section titled “Parameters”typeName
Section titled “typeName”string
extractEntityId?
Section titled “extractEntityId?”(command) => string
How a command names its entity.
It rides along on the key so the declaring class is the single source of
truth for both halves of “what this entity type is” — but it is NOT part
of the identity, and equals ignores it. A node that only looks
entities up (entityRefFor, startProxy) never routes by extraction, so
it can name the same type with a key that omits the extractor entirely.
An extractEntityId passed in options wins over this one.
Returns
Section titled “Returns”ShardKey<TCommand>
Properties
Section titled “Properties”_command
Section titled “_command”
readonly_command:TCommand
Defined in: src/cluster/sharding/ShardKey.ts:24
Phantom field — retains TCommand so inference round-trips through the key.
extractEntityId?
Section titled “extractEntityId?”
readonlyoptionalextractEntityId?: (command) =>string
Defined in: src/cluster/sharding/ShardKey.ts:38
How a command names its entity.
It rides along on the key so the declaring class is the single source of
truth for both halves of “what this entity type is” — but it is NOT part
of the identity, and equals ignores it. A node that only looks
entities up (entityRefFor, startProxy) never routes by extraction, so
it can name the same type with a key that omits the extractor entirely.
An extractEntityId passed in options wins over this one.
Parameters
Section titled “Parameters”command
Section titled “command”TCommand
Returns
Section titled “Returns”string
typeName
Section titled “typeName”
readonlytypeName:string
Defined in: src/cluster/sharding/ShardKey.ts:27
Methods
Section titled “Methods”equals()
Section titled “equals()”equals(
other):boolean
Defined in: src/cluster/sharding/ShardKey.ts:52
Parameters
Section titled “Parameters”ShardKey<TCommand>
Returns
Section titled “Returns”boolean
toString()
Section titled “toString()”toString():
string
Defined in: src/cluster/sharding/ShardKey.ts:53
Returns
Section titled “Returns”string
staticof<TCommand>(typeName,extractEntityId?):ShardKey<TCommand>
Defined in: src/cluster/sharding/ShardKey.ts:41
Type Parameters
Section titled “Type Parameters”TCommand
Section titled “TCommand”TCommand
Parameters
Section titled “Parameters”typeName
Section titled “typeName”string
extractEntityId?
Section titled “extractEntityId?”(command) => string
Returns
Section titled “Returns”ShardKey<TCommand>