feat: allow state and derived declarations inside class constructors #11455
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.
This is a POC to test the feasability of allowing
$state
and$derived
inside the constructor. Some cases still missing, and validation needs to adjusted to allowthis.x = $state(0)
inside the constructor but only at the top level of it.Uncanney-valley-wise I think it's fine. TypeScript for example didn't have the ability to know that something was definitely initialized unless you either directly declared it or did so in the constructor (it did not follow method invocations inside the constructor) and it was honestly fine. I think the rule of only allowing it inside the constructor at the top level (i.e. not nested in an if block) is understandable and intuitive.
I'll proceed with this once we agreed on whether or not we want to do this.
closes #11116
closes #11339
Before submitting the PR, please make sure you do the following
feat:
,fix:
,chore:
, ordocs:
.Tests and linting
pnpm test
and lint the project withpnpm lint