Skip to content
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

Verify no arguments are given to reactive and render decorators #1819

Open
schloerke opened this issue Jan 14, 2025 · 3 comments
Open

Verify no arguments are given to reactive and render decorators #1819

schloerke opened this issue Jan 14, 2025 · 3 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@schloerke
Copy link
Collaborator

  • Near

    # The CalcAsync subclass will pass in an async function, but it tells the
    # static type checker that it's synchronous. wrap_async() is smart -- if is
    # passed an async function, it will not change it.
    self._fn: CalcFunctionAsync[T] = _utils.wrap_async(fn)
    , we should inspect the fn to verify that it has not arguments. (O(1) when running the app)

  • Near

    # Set value function with extra meta information
    self.fn = AsyncValueFn(_fn)
    , we should inspect the fn to verify that it has no arguments. (O(1) when running the app)

Motivation: Provide clear errors to users who do not enable type checking of their common mistake.

@schloerke schloerke added enhancement New feature or request good first issue Good for newcomers labels Jan 14, 2025
@gadenbuie
Copy link
Collaborator

...that it has no arguments

More specifically, I think we'd want it to have no required arguments

@schloerke
Copy link
Collaborator Author

Fair, but Shiny will never supply any arguments.

I would rather err on the side of no-arguments than no required arguments.


Both approaches are better than the current approach, which is "doing nothing".

@gadenbuie
Copy link
Collaborator

I would rather err on the side of no-arguments than no required arguments.

I think it's good to prevent people from doing obviously wrong things. But I almost always regret disallowing a perfectly okay thing in the name of an easy error message. It's a hard balance. In this case it wouldn't be the worst to need to write a wrapper function or use a lambda, which would get you around the no arguments requirement if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants