4 ms·

While this example looks pretty good now with just that limited functionality, if you continued to use this pattern across a complex UI, your Setup() function i

by RyanZAG 14y ago

While this example looks pretty good now with just that limited functionality, if you continued to use this pattern across a complex UI, your Setup() function is going to be 1000 lines long and likely incomprehensible. I like the idea, but I'm pretty sure there are nicer ways to set that up than an arcane looking IObservable block inside a Setup() function. I guess it's just for demonstration though, and in a real UI he would have those off in their respective controllers and setup in their own methods.

lnanek2 14y ago
Sometimes code does become more like his, however. Like someone else commented already, it's far more common to store the states in a model. Often the way changing one control would then enable a button that depends on it is that it would trigger an invalidate which would cause the rest of the UI to check the model again. I have seen this sort of code then become more like his when the invalidate step became too expensive, and what was invalidated or what was changing had to start getting specified. I admit it has only happened in games for me, though, where you often have super complex UI states and have to manage smooth frame rates.
stephen 14y ago
> your Setup() function is going to be 1000 lines long and likely incomprehensible Have you worked on a system that used these principles, and found them to be inadequate, beyond an off-the-cuff read of this blog post? I ask because I have built a system like this, and if your nightmare 1,000-line Setup() function is true, then my experience is that implementing the same behavior imperatively would be 2,000+ lines of spaghetti code that is an even worse nightmare. For behavior that changes on multiple conditions (just like in the OP), declarative programming is a win. Otherwise you end up coding "oh, wait, now do this" is in 2-3 different places, and invariably forget to keep all of them in sync you're making changes.
- to3m 14y ago
  I've always found such systems intolerably difficult to debug. Is there an option for 1,000 lines of imperative non-spaghetti? I've found that keeping the bulk of UI code in one place is the key to keeping these things manageable. Ideally, each widget's handler should do little more than affect whatever data it needs to affect, then call another function that updates all widgets' states according to the latest data. For stateful sequences of events (e.g., mouse drags) the rx-style approach is a bit more compelling. Imperative code for that stuff is always ugly. But you still seem to have the same problem of debuggability if you use rx, and backing out of a state looks like it might be a bit of a chore. Call me a Philistine, call me a barbarian...

by RyanZAG 14y ago

lnanek2 14y ago

Sometimes code does become more like his, however. Like someone else commented already, it's far more common to store the states in a model. Often the way changing one control would then enable a button that depends on it is that it would trigger an invalidate which would cause the rest of the UI to check the model again. I have seen this sort of code then become more like his when the invalidate step became too expensive, and what was invalidated or what was changing had to start getting specified. I admit it has only happened in games for me, though, where you often have super complex UI states and have to manage smooth frame rates.

stephen 14y ago

> your Setup() function is going to be 1000 lines long and likely incomprehensible Have you worked on a system that used these principles, and found them to be inadequate, beyond an off-the-cuff read of this blog post? I ask because I have built a system like this, and if your nightmare 1,000-line Setup() function is true, then my experience is that implementing the same behavior imperatively would be 2,000+ lines of spaghetti code that is an even worse nightmare. For behavior that changes on multiple conditions (just like in the OP), declarative programming is a win. Otherwise you end up coding "oh, wait, now do this" is in 2-3 different places, and invariably forget to keep all of them in sync you're making changes.

to3m 14y ago
I've always found such systems intolerably difficult to debug. Is there an option for 1,000 lines of imperative non-spaghetti? I've found that keeping the bulk of UI code in one place is the key to keeping these things manageable. Ideally, each widget's handler should do little more than affect whatever data it needs to affect, then call another function that updates all widgets' states according to the latest data. For stateful sequences of events (e.g., mouse drags) the rx-style approach is a bit more compelling. Imperative code for that stuff is always ugly. But you still seem to have the same problem of debuggability if you use rx, and backing out of a state looks like it might be a bit of a chore. Call me a Philistine, call me a barbarian...