Allow for Feeback Provider integrations

[deadlydog]

It has been suggested that some of the tips could be helpful as Feedback Providers. Here are the docs on making a feedback provider. Feedback providers are written in C# and typically require writing some logic to determine if the feedback provider should be triggered or not. I haven't done anything with Feedback Providers yet, but from a cursory look at the docs, it seems we would need the tip author to add a property to the tip that essentially contains the C# logic that would need to run to determine if the tip is relevant to the PowerShell code being executed or not.

So when defining the tip you would have an additional FeedbackProviderSuccessTrigger property, that might look something like this:

$tip = [tiPS.PowerShellTip]::new()
$tip.CreatedDate = [DateTime]::Parse('2023-09-05')
$tip.Title = 'When checking for $null, put $null on the left'
$tip.TipText = @' ... '@
... # All of the other tip properties
$tip.FeedbackProviderSuccessTrigger = @'
// This is C# code, not PowerShell.

// Trigger on success
if (target == FeedbackTrigger.Success)
{
    // Parse the AST to find if there are instances of $null on the left side of an equality operator.
    ...

    // If no alias was found return null
    if(actions.Count == 0)
    {
        return null;
    }

    // If aliases are found, set the header to a description and return a new FeedbackItem.
    header = "Put the $null operator on the left";
    // Copy actions to _candidates for the predictor
    _candidates = actions;

    return new FeedbackItem(header, actions);
}
'@

That code/string would then need to be parsed and compiled dynamically by C#, which can be quite complicated and error prone.

This seems awfully cumbersome, especially when we want to encourage community members to contribute tips. The main purpose of tiPS is to deliver PowerShell tips to you in your terminal. While feedback providers may at first seem like they serve that same purpose, I would argue they go beyond that and their actual purpose is to catch problems in your code that you are writing and help you correct them. So while feedback providers may deliver "tips" (i.e. helpful messages) to the user through the terminal, I feel the better solution would be to create a new dedicated feedback provider module specifically for that purpose, rather than trying to generalize tiPS and make it do a bunch of different things. Also, probably 80% of the tips in tiPS do not make sense to put in a Feedback Provider, so it really feels like more of an edge case for tiPS, rather than part of it's core functionality.

So after writing this out, my thoughts are that someone could create a new dedicated feedback provider module, and simply use the tips in tiPS as the source of inspiration for many of their feedback providers. That would also allow the feedback providers to provide more contextual and relevant information to the user, rather than just dumping the generic $tip.TipText message in the user's terminal.

If others see an easier/better way for the integration that makes more sense and still provides a good end-user experience, I'd love to hear it. I'm open to any other feedback on this issue as well. Thanks!