Avoid return in constructors #2041
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Map, List and Set classes are exported. See Lines 60 to 64 in d644440 So unfortunately, I don't think that we should remove support for this. |
|
Hello @jdeniau |
|
@alexvictoor I did merge this on the 6.x branch |
This was referenced Feb 22, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello!
Happy new year 2025!
This PR removes most "return" in constructors. The only one left is in Record.js.
I have started to work on TypeScript JSDoc comments and noticed that return in constructor would make the migration of the codebase really difficult.
Also my personal opinion is that removing return in constructors increase readability.
Anyway, this PR is a prerequisite for a second PR that will come next which introduce JSDoc TypeScript comments in the codebase.
I have tried to reduce as much as possible the impact on the API but there are still some small breaking changes:
Map, List, Set are now functions. They are not classes anymore. The related classes are MapImpl, ListImpl and SetImpl. Thoses new classes are not exported so IMHO the impact for ImmutableJS users is limited.
The only issue is illustrated by the following code fragment: