Bug: tear-offs don't trigger computed()
#334
Conversation
|
I think this is working as expected. Computed needs to return a value but with a tear off it returns a function. When would you need to provide a tear off like that? |
|
My understanding was that using a tearoff would be equivalent to an explicit call - after all, the input to
I am obviously wrong about the "equivalence" part of that assumption, but if the criterion for supporting these is literal need, that point is irrelevant anyway. In that case, however, some type of hint about the unsupported use case would be highly appreciated - ideally an assertion causing the call to fail or an analysis error. That way, others could be spared from first having to realize this is not an issue with the computation content, which in my case was what I initially focused on attempting to debug. The fact that this currently does not result in an error, but just a lack of signal updates, also feels like it could easily just go unnoticed and end up in deployed code. (looks like |
|
I think it would be a great addition to signals_lint for sure. The reason it needs to be called is that is when the dependencies are discovered and connected to other signals. With a tear off it just says that it will run but not actually computed. There are times you do want a computed to return a function but your example is a good case to add a lint for. Also to double check you can always test the JS equivalent to see if it is a bug or actual issue too: |
|
Hah I have to admit it is quite the feeling when you open the codebase of a package written in an entirely different language but feeling right at home because the APIs are completely identical ❤️ |
|
That was the goal 💙 |
Added a test case illustrating the issue.