-
Notifications
You must be signed in to change notification settings - Fork 112
rpc-api parameters should use consistent readonly modifier #978
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
Conversation
🦋 Changeset detectedLatest commit: afe8469 The changes in this PR will be included in the next version bump. This PR includes changesets to release 41 packages
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 |
BundleMonUnchanged files (130)
No change in files bundle size Final result: ✅ View report in BundleMon website ➡️ |
|
Love it. I spot checked the API and added a couple more.
Can you say more about why you would prefer mutable returns? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something along the lines of Postel's law/robustness principle. E.g. if I get an array of addresses back, why shouldn't I be allowed to mutably concat another array of addresses to it. Essentially, if you're return is const, you are being prescriptive in what your users can do with it. This only makes sense if you're exposing internals for efficiency instead of handing back a fresh copy. So the more explicit principle would be: Mutable returns because it gives the user more freedom, unless there's a reason not to (e.g. the user has to pay in performance). |
|
And separately, most TypeScript code is terrible and not correctly readonly aware, so if you return readonly arrays and people have to forward these returns to functions that forgot to make their input arrays readonly, you always force your users to cast away constness, which makes using your SDK more annoying. (I would not have gone to the trouble of opening a PR like this in other TS projects, because for the most part, unlike you guys, nobody cares about writing proper code.) |
|
Interesting. If you want to continue to pull on this thread, can you open an issue to continue the discussion? In general, I worry that allowing mutations in responses will destroy their integrity, because so many of these responses have cross-field dependencies (eg. just mutating the I also get the point about trying to forward a |
|
🔎💬 Inkeep AI search and chat service is syncing content for source 'Solana Kit Docs' |
Made parameters in rpc-api consistently
readonlyso I can pass readonly arrays as expected.You guys should separately make up your mind whether responses should be readonly or not, because right now it's a wild mix where:
some arrays are returned mutable
while others are readonly
and while all response objects consistently use
Readonly<...>, arrays within themsometimes do
and sometimes don't
I think readonly params and mutable returns are likely the cleanest approach.