Open PGimenez opened 3 months ago
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:
@bind
macro is already used and @io
and @state
are nowhere clearer (and much less explicit about what they're doing) 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`.
We could also add aliases as @input
and @output
- I think these would be clearer.
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.
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.
@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,
@in
should 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.