Gauging interest: MayExecute for commands

Context: With WPF, I did my best to bake in support for a custom ICommand-extending interface: interface IPermissionCommand : ICommand { bool MayExecute(); }

If MayExecute evaluates to false upon the command attaching to the button, the button’s visibility is locked to Collapsed - enforced in VisibilityProperty’s coercion handler. This was born from the existence of user permissions in the software I help develop; it was easier in the long term to turn it into a standard for commands rather than create individual properties for visibility bindings. It’s a big bother to get it right from outside of the framework, though, especially with MenuItems.

Anyway, I’m just wondering if there’s any interest in such a concept from Avalonia devs + users. If so, I can champion a pull request. If not, I won’t 🙂

[grokys]

From what I understand, this is essentially to allow changing the visibility state as well as the enabled state from a command?

I have needed to do that a few times myself, but usually I’ve found one of the following strategies works:

• Often I want to hide e.g. the button when the bound command is CanExecute() == false. This can be done pretty easily using styles in Avalonia, e.g. <Style Selector="Button.autohide:disabled><Setter Property="IsVisible" Value="False"/></Style>
• If I want a three-state visible/disabled/hidden button, then I can set the command to null in the view model, and bound the IsVisible property to make the button only visible when the command is non-null, e.g. <Button IsVisible="{Binding !!MyCommand}>.

Do the techniques above not address your use-cases?

I wouldn’t be adverse to adding e.g. a ICommandEx interface with a ShouldShow property on it (which is what I think you’re suggesting, but with different naming), but I’d have a few reservations:

• I usually use ReactiveUI’s ReactiveCommand rather than rolling my own ICommand implementation. This wouldn’t know anything about this new interface, meaning I’d have to roll my own ICommand implementation. That would probably mean that I personally wouldn’t really use it.
• Your description of the problem sounds very focused on your business logic. Does it really need to be part of the framework? Remember that once you add a feature, even if it’s used by a tiny minority, it’s very hard to take it away without making people angry!
• What other state could/should be put into this new interface? For example I often want to change the caption on the button depending on logic in the view model. Should we but a Caption property on this new interface? If so where do we stop? What is the boundary between framework and business logic?

There’s also of course naming: MayExecute vs CanExecute isn’t really very descriptive, which is why I suggested ShouldSHow but we can bikeshed that when we decide it’s needed 😉

[bhood-zorus]

@grokys

just using CanExecute

This ignores the purpose of the proposal. MayExecute offers a separation of concerns.

binding to !!MyCommand

That’s a cool trick. Given the first two of the three bullet points underneath, it could be totally sufficient; it also looks more idiomatic.

BTW, I happen to think May vs Can is perfectly descriptive. Just because you can do something doesn’t mean you’re actually allowed to do it.