question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

TypeInfo: Should use readonly types over mutable types.

See original GitHub issue

The 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:

  1. Create a variable of a Readonly type.
  2. 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:closed
  • Created 3 years ago
  • Reactions:3
  • Comments:5 (3 by maintainers)

github_iconTop GitHub Comments

1reaction
eps1loncommented, Mar 25, 2020

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 👍

1reaction
eps1loncommented, Mar 25, 2020

This would throw now, no?

const values: AutoCompleteProps['values'] = []
values.push(1)
Read more comments on GitHub >

github_iconTop 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 >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found