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
actions property instead of having it mixed in with the ActorConnRaw properties.
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 actions config object property of actor()
6 Replies
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 actions config object property of actor()personally, i think the minimalism is worth the added complexity, compared to
client.getOrCreate().actions.foo().
other alternatives we considered is a special property to hold the internal methods. eg conn.raw.dispose() or something like that
another option was to prefix the internal properties like conn._dispose, but that feels dirty to me
either way, you'd still need to alias the internal methods – https://github.com/rivet-gg/rivetkit/issues/1080
open to thoughts on above ideasGitHub
feat: alias action names that conflict with internal methods · Iss...
For example: there cannot be an action named dispose since it would conflict with the dispose method on the actor. In this case, we should alias the user's method to _dispose. This requires som...
Yeah that's understandable I guess.
I do separately like the idea of adding
.raw properties at the different levels. More so from an angle of omitting untyped methods people shouldn't use unless they know what they're doing.
e.g. the return type of createClient() can omit all the getX() and create() methods, leaving only dispose() and the inferred actor access properties on the top level object.
Similarly ActorHandle and ActorConn could omit the untyped action() method from the top level.
And once typed events are added, .on() and .once() in ActorConn would be replaced with the typed version at the top level, with the untyped only existing in raw
I'm not too sure how I feel about the aliasing idea.
I'd probably preference trying to solve it by preventing being able to define actions with reserved keys it at the type level, with an additional runtime error if someone does happen to use a reserved key anyway.that's not a bad idea. in that case. it'd probably make sense to limit our internal keywords to be in a sub-object, (like the
client.getOrCreate().raw.dispose(), but need a better name than raw). that'd let us have more flexibility to add new internal keywords without breaking changes in the future and reserve just raw (or whatever).GitHub
feat: raise type & runtime error if action names conflict with nati...
Need to prevent conflict with native methods, such as dispose, on, etc. These methods live on ActorHandle and ActorConn. We should also consider moving all native functionality to a subobject, such...
i closed the old one
any ideas on terminology here?
Awesome 🙌
Not off the top of my head. The
raw name actually kind of clicked for me to be honest. Aligns for me with how web frameworks like Hono and Fastify let you access the raw Request object, and some other ORM's let you do raw queries.
But I get that's maybe not quite equivalent here.
A $ prefix could also help as far as preventing naming conflicts I guess and making it more distinguished from the main properties 🤷♂️
Anyway it's very late for me, will sleep on it and let you know if I think of anything.
Maybe instance 😅