GenieFramework / Stipple.jl

The reactive UI library for interactive data applications with pure Julia.
MIT License
324 stars 27 forks source link

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

Open PGimenez opened 3 months ago

PGimenez commented 3 months ago

@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.

essenciary commented 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:

essenciary commented 3 months ago

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 commented 3 months ago

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

essenciary commented 3 months ago

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 commented 3 months ago

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.