-
-
Notifications
You must be signed in to change notification settings - Fork 29
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
Consider drop of readonly modifiers #65
Comments
hello @Nodonisko 👋 thanks for the suggestion, and I will definitely consider it, in the meantime, have you tried this https://mobily.github.io/ts-belt/docs/getting-started/config#immutable-vs-mutable? |
@mobily Cool I didn't know about that config! I will try it :) |
and the moment it supports arrays only, but I think adding support for objects doesn't require much effort |
@Nodonisko does that work as intended on your end? |
@mobily It's better, but as you mentioned without object support there are still places where it throws a lot. |
I think I can help you with this one, but I have troubles to understand how to contribute. For example for Array, there are two files:
In |
@mobily Adding a mutability option for objects would be a great help! At my company we're also trying to introduce Thanks for the great work! |
to add my two cents: it's best if function arguments are immutable, but return values not. This allows for seamless integration with libraries which are imprecise in their types and use mutable types in function arguments, event though they do not mutate them |
readonly
is constant source of pain, because everytime where code fromts-belt
come to contact with normal JS code it throws type error. It happens us a lot because we are using it in legacy codebase a even if you do thing like simpleA.map
you need always wrap result inF.toMutable
.If I decide to refactor our code to work with it, I need to place
readonly
literally everywhere. That will break TS in our tests because of our fixtures which are mutable. Same problem is that everywhere where code come to touch with 3rd party libraries I will throw some errors aboutreadonly
again.And last and probably strongest argument is this nice thread on Twitter with some great examples why it's even not that safe >>> https://twitter.com/MichaelArnaldi/status/1601535981949456385
I know this is will produce big change (but shouldn't be breaking) and final resolution is on you @mobily but please consider dropping it for v4.
The text was updated successfully, but these errors were encountered: