Suggestion: Nest action methods under `actions` property of `ActorConn`
This would be a fairly significant breaking change, but I'm questioning if it's worth nesting the callable actions methods under a dedicated
From a DX perspective it's slightly more overhead having all of these method properties mixed in with the actual actions.
But it also feels fragile to let users define actions that will override the other connection properties. I'm not entirely sure what's available at runtime but right now it just overloads the two properties from actions and the class.
If not, it might at least be worth seeing if it's possible to prevent the reserved keys of ActorConnRaw from being used in the
actionsActorConnRawFrom a DX perspective it's slightly more overhead having all of these method properties mixed in with the actual actions.
But it also feels fragile to let users define actions that will override the other connection properties. I'm not entirely sure what's available at runtime but right now it just overloads the two properties from actions and the class.
If not, it might at least be worth seeing if it's possible to prevent the reserved keys of ActorConnRaw from being used in the
actionsactor()
Build and scale stateful backends. Rivet Actors is a library for long-lived processes with durable state, realtime, and scalability. Easily self-hostable and works with your infrastructure.
1,419Members
Resources
Similar Threads
Was this page helpful?
