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

Add new default macro to declare read-write variables #285

Open
PGimenez opened this issue Aug 1, 2024 · 5 comments
Open

Add new default macro to declare read-write variables #285

PGimenez opened this issue Aug 1, 2024 · 5 comments
Labels
enhancement New feature or request

Comments

@PGimenez
Copy link
Member

PGimenez commented Aug 1, 2024

@essenciary @hhaensel

Right now we have @in and @out to declare read-write and read-only variables. Many times I've declared an @out variable by mistake and then wondered why the UI component it was bound to wasn't working. I assume this could happen to other people as well.

I'd like to have a different macro that would declare read-write variables and is named something other than @in, to avoid having to think whether the variable is read-only/read-write. Something like @io, @bind, @state.

And now that I think about it, given its name, @inshould only take values from the browser to the backend and not the other way around. But this would be a breaking change for people's apps so let's not do that.

@PGimenez PGimenez added the enhancement New feature or request label Aug 1, 2024
@essenciary
Copy link
Member

essenciary commented Aug 1, 2024

The @in and @out are safety features. They protect against people exposing data unwillingly. So explicit exposing of data is a good safety feature. It's much better to limit data output and realize and fix it, than unwillingly expose your data onto the client. It's similar to how in programming languages functions are private by default. If you can't access it, change the visibility.

As such:

  • the change of alias will no longer make it explicit that the data is exposed on the internet, making the users vulnerable to serious data leaks
  • as this is a safety feature, it makes no sense to have just input, that would be an artificial limitation and would require yet another macro for input+output. It makes no sense to have a variable that takes input but can not output (again, the key point is protection against accidentally accepting data from the outside world)
  • so far I haven't heard this issue from anybody else
  • the @bind macro is already used and @io and @state are nowhere clearer (and much less explicit about what they're doing)

@essenciary
Copy link
Member

What about a different solution, like better errors/debugging? Ex in dev, if we try to access a variable that is not exposed, show a message: "Looks like you might be attempting to update the x var. The variable is declared as @out and won't accept new values. Make sure to change it to @in if you want to change its value`.

@essenciary
Copy link
Member

We could also add aliases as @input and @output - I think these would be clearer.

@essenciary
Copy link
Member

essenciary commented Aug 1, 2024

I want to stress that this is software for building data apps, targeting users and enterprises with highly sensitive data. We must 1000% err on the side of safety.

@PGimenez
Copy link
Member Author

PGimenez commented Aug 5, 2024

Ok I see, I understand now why we need both in/out. I agree with showing better error messages, that'd completely solve this issue.

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

No branches or pull requests

2 participants