You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## Summary:
See the [slack discussion] for more details. TL;DR:
- The `readonly` modifier in TypeScript simply removes mutating operations like
`Array.push` and `obj.foo = 1` property assignment from a type.
- As such, it's best to think of it as an application of the [Interface
Segregation Principle].
- That implies that `readonly` types are most appropriate in function parameters.
There, they act as a promise that the function won't mutate its arguments.
- They may also be appropriate in return types **if** the function returns a
frozen object or array, because frozen objects actually disallow mutation at
runtime.
- In general, readonly types are **not** appropriate in the return types of
functions, because they unnecessarily restrict the caller from mutating an
object to which no one else holds a reference.
- That means readonly types are probably **not** appropriate for shared data types
which may be used in _either_ parameters or return values.
- We weren't using readonly types consistently in `data-schema.ts` to begin with.
We used them for arrays, but not for tuples or objects.
- For the sake of consistency, and to allow our `data-schema` types to be reused
easily in different contexts, this PR replaces `ReadonlyArray` with `Array` in
`data-schema.ts` and fixes the type errors that cascade out of that.
[slack discussion]: https://khanacademy.slack.com/archives/C01AZ9H8TTQ/p1744325813358959
[Interface Segregation Principle]: https://en.wikipedia.org/wiki/Interface_segregation_principle
Issue: LEMS-XXXX
## Test plan:
`pnpm tsc`
Author: benchristel
Reviewers: jeremywiebe, benchristel, handeyeco
Required Reviewers:
Approved By: jeremywiebe
Checks: ✅ 8 checks were successful
Pull Request URL: #2398
0 commit comments