TypeInfo: Should use readonly types over mutable types.
See original GitHub issueThe material-ui components declare their types as mutable when in fact they are treated as immutable by material-ui.
- The issue is present in the latest release.
- I have searched the issues of this repository and believe that this is not a duplicate.
Current Behavior 😯
Values of a readonly type cannot be given to material-ui components.
I’ve only checked this with the Autocomplete
component but I assume there are probably other components affected by this same issue.
Expected Behavior 🤔
Values of a readonly type should be able to be given to material-ui components.
Steps to Reproduce 🕹
Issue demonstrated here codesandbox.io/s/funny-sky-mw1st in the src/App.tsx
file.
The prop options
cannot be assigned a readonly type.
Steps:
- Create a variable of a Readonly type.
- Supply that variable to a material-ui component that is expecting a mutable type.
Context 🔦
I’m trying to have a fully immutable and function code base using the linting rules defined in eslint-plugin-functional.
Your Environment 🌎
Tech | Version |
---|---|
Material-UI core | v4.9.7 |
Material-UI lab | v4.0.0-alpha.46 |
React | v16.13.0 |
TypeScript | v3.8.3 |
Issue Analytics
- State:
- Created 3 years ago
- Reactions:3
- Comments:5 (3 by maintainers)
Top Results From Across the Web
TypeInfo: Should use readonly types over mutable ... - GitHub
The material-ui components declare their types as mutable when in fact they are treated as immutable by material-ui.
Read more >Why typescript allows referencing/assigning a readonly type ...
In existing TypeScript code there is no way to indicate if a particular property is intended to be read-only or mutable. In the...
Read more >Writing high performance F# code - Bartosz Sypytkowski
Writing code that is high level, declarative and fast on .NET platform is not an easy task. In the examples below we'll use...
Read more >tslint-immutable - npm
This rule enforces use of the readonly modifier. The readonly modifier can appear on property signatures in interfaces, property declarations in ...
Read more >Microsoft/TypeScript - Gitter
Is there some way to use a type predicate to fix this error? Ideally, the type predicate's return type would be something like...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I get the desire to make this more strict and in the end this might as well not break anything. It’s just that I want to avoid different typing approaches across the code base which means we would update types for components that are considered stable. Looking at how much value this provides even a single issue report isn’t worth the trouble for us.
But who knows. Maybe this gets traction. Thanks for the quality issue anyway. Always appreciated 👍
This would throw now, no?