Skip to content
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

Allow DeepReadonly to be applied more than once #106

Closed
aaronjensen opened this issue Oct 1, 2019 · 1 comment · Fixed by #107
Closed

Allow DeepReadonly to be applied more than once #106

aaronjensen opened this issue Oct 1, 2019 · 1 comment · Fixed by #107

Comments

@aaronjensen
Copy link
Contributor

Is your feature request related to a real problem or use-case?

I'm building a redux state type from other existing types. For some of the child types, we'll want to use DeepReadonly to make them immutable. Then, at the very top level (the combined state) I want to use DeepReadonly again to ensure that everything is actually immutable.

Unfortunately, this double application causes issues in some instances:

const foo: DeepReadonly<DeepReadonly<{bar: any[]}>> = {bar: ['hi']}
;[...foo.bar] // This errors with:
// Type '_DeepReadonlyObject<_DeepReadonlyArray<any>>' must have a '[Symbol.iterator]()' method that returns an iterator.

Describe a solution including usage in code example

Though the above example is contrived, it's sufficient to demonstrate the issue.

Who does this impact? Who is this for?

All who are combining multiple potentially readonly things into one readonly thing.

Describe alternatives you've considered (optional)

Only applying DeepReadonly at the very top, which is what I'm doing for now, but makes for more work.

Additional context (optional)

N/A

@aaronjensen
Copy link
Contributor Author

It appears that changing T extends any[] to T extends ReadonlyArray<any> fixes my particular issue. I'll open a PR w/ that.

aaronjensen added a commit to aaronjensen/utility-types that referenced this issue Oct 1, 2019
aaronjensen added a commit to aaronjensen/utility-types that referenced this issue Oct 1, 2019
piotrwitek pushed a commit that referenced this issue Oct 4, 2019
* Allow recursively applying DeepReadonly

fixes #106

* Tag things made deepReadonly and do not recurse them again

* Use infer to make DeepReadonly idempotent

* Address feedback
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant