ThoughtWorksInc/Binding.scala

Bardur Arantsson

@BardurArantsson

Apr 26 2016 10:26

I do, I think. I want Busy to the basis for displaying a "Busy" indicator, so it has to be reified somehow.

(Note that I'm not using the @dom support; I don't have any time to rewrite the UI bits, but the logic behind it could plausibly be rewritting using Binding.scala.)

杨博 (Yang Bo)

@Atry

Apr 26 2016 10:29

OK. You can have Busy as a local state variable, like val answer = Var[Option[String]](None) in https://thoughtworksinc.github.io/Binding.scala/#3 . But you still do not need a universal place that dispatches all events according to your global state.

You could simply handle events in local scope, like the live DEMO did

@BardurArantsson , if you avoid the global state machine, then you will find out that your event handler itself knows what the state is, because it is just there.

杨博 (Yang Bo)

@Atry

Apr 26 2016 10:36

For example:

val currentLocalState: Binding[S] = whatEverItComes
currentLocalState.each match {
  case SomeSpecificState =>
    <button onclick={ event: Event => getNextState(event, SomeSpecificState) }>A button for SomeSpecificState </button>
  case AnotherSpecificState =>
    <button onclick={ event: Event => getNextState(event, AnotherSpecificState) }>A button for AnotherSpecificState </button>
}

So the problem is about how you handle your events. Registering a global event handler or allowing every component register its own evnet handler.

Bardur Arantsson

@BardurArantsson

Apr 26 2016 16:54

Maybe I'm still not just understanding what you're saying. I see just fine how to do this for state which is "triggered" by some user action (or direct method call, whatever), this is the AuthenticationState which is 'triggered' by a Login action + some ajax callbacks, but the issue I'm having is more to do with the state that's "derived" from that, namely the AuthorizationState (e.g. which roles does the user currently have), which is derived from changes in the AthenticationState and the current AuthorizationState.

Anyway, I've given up for now. No time left for experimentation :). Thanks for the help.

杨博 (Yang Bo)

@Atry

Apr 26 2016 18:12

You problem it that your AuthorizationState state is redundant, which make your code depend on mutable state. Also the state is dangerous and error-prone regardless whether you use Binding.scala or not.

For ajax events, you could simple wrap a JavaScript's Promise or a scala's Future to a Binding via JsPromiseBinding or FutureBinding and create derived binding expression from the it. I cannot see why you need an internal mutable state.