-
Notifications
You must be signed in to change notification settings - Fork 19
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
Compile-time detection of @component
functions with inconsistent state
#37
Comments
I think this is a really good idea. For solara 2.0 we plan to remove a lot of footguns (warn and inform the users when they do something wrong), and this is certainly one of them. There are rare situations where this is ok (you can imagine having something conditional, but not changing - like depending on a environment variable). For that reason, we probably want an opt-out. I tend to put it into solara first, because most users are not aware of reacton, and then we can make the error message + hint specific for solara. Do you think we need to skip this in |
My gut reaction would be to specify in the pyproject [tool.solara] section which flags are adjusted in production mode. But since that would require more effort, I say we measure the performance impact of compile-time checks across a large application, and if the slowdown is ~5% or less, we leave it in. It will catch people doing "quick fixes" without disabling the production flag I agree about the rare cases where conditional hooks are acceptable. I have a DEBUG flag that turns 'use_thread' calls into 'use_effect' because the former chokes the vscode debugger. But even in that case, I would say users must move the conditional check outside the component. So they call a function that resolves which hook should apply. That's what I ended up doing anyway, so I could reuse the same logic across many components. Or they can pass a list of accepted conditional variables to the decorator, but I want to force as rigid of a hooks layout as possible to prevent footguns |
Closing in favor of widgetti/solara#706 |
Consider the following simple component:
After clicking the button, we get the following error:
In this case, it is clear how to fix the issue. But if the condition to trigger conditional hooks rarely appears, debugging is especially difficult.
I wrote the following function which attempts to detect these cases at compile time:
Running this on the sample component provided a much more helpful error (again, at compile time instead of after a conditional toggle!):
I am curious what other cases should be detected and whether you think this function can be adopted into reacton or solara more generally.
use_*
inside anif
orfor
blockreturn
beforeuse_*
use_*
outside a render context (this would be a bit harder, but still possible by tracingast.Call
usage)In my case, I wrapped
solara.component
to call this function first and found a few other conditional hook bugs in my existing components.The text was updated successfully, but these errors were encountered: