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.
Given this code snippet:
If we transpile to the following snippet, it won't work. Because outside the codeblock defining
amutable, it's just a normal value, without value property:What if we expose a setter from the defining place? It still doesn't work as expected. The block
setA(a+1)results in incrementing forever. Because it referenceaand mutatea, and every block referencingareruns whenais mutated.How about we expose a setter as well? It works. Because
setA(getA() + 1);doesn't referenceaanymore!In order to make mutable more transpiling-friendly, changes API a little bit. Then converts
atomutator$$a.value.But this brings another question: When should we transpile
atomutator$$a.value, and when should we leave it as is?We can't transpile all of them to
mutator$$[NAME].value, because they are not reactive anymore.My intuition is that if a codeblock mutates the mutatble, then transpile it, otherwise don't. But what if a block mutates and references a mutable:
This will not work as expected either. So I guess we should discourage this usage? Because you can always split them up: