microsoft / microsoft/Forge

CachedVariable for ChildSelectors

Open
#29 1 comment 1 reaction 1 assignee View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
C#
Stars
334
Forks
61
PR merge metrics
No merged PRs in 30d

Description

• Add CachedVariable (name pending) property that caches the result of an expression for use in the ChildSelectors.
	○ A common pattern in ChildSelectors is a switch statement, where you calculate some value and visit different children depending on the result. The issue today is this calculation must be done for each child selector. This feature would allow you to calculate the result once and use it directly multiple times. 
	○ Allows you to evaluate an expression and save the result (non-persisted?).
	○ ChildSelectors then have access to that variable to simplify their ShouldSelect statements.
	○ Consider allowing the variable to be a dynamic object. So could be bool, string, object, etc.. This allows users to set as many properties as they wish.
	○ Consider what using a dynamic object would look like. If we have to wrap it every time with (Session.CachedVariable as string), then the usability goes down. In this case, it may be better to just set it as a string. Users could still use it as a bool or object by converting the string if they desire.
	○ Consider if this should be localized to just the current TreeNode's ChildSelector, or if you can access parent's CachedVariables as well.
	○ Consider if this should be tied to ChildSelector at all. Perhaps just adding a way to persist data in the ForgeStateDictionary from the tree would be cool.
		§ Perhaps they both could happen though. This would be a helper property to make the feature intention clear. If we decide to add more functionality later for setting ForgeState, we can still do that.
	○ Considerations:
		§ Persisted vs non-persisted
		§ Useable from ChildSelector only or everywhere?
		§ Save as String vs Object
		§ Cache result vs expression itself. Specify if you want to cache the expression result, or reevaluate.
		§ Consider defining at the tree level.
		§ Add flag to dictate behavior of CachedVariable. Whether or not to reevaluate each time. Could be unclear what the behavior is by default, make sure to set up the right expectations.
	○ Issue with tree structure
		§ How to enforce that people are calling it at the right time? For example, the expression could GetOutput of a TreeNode that hasn't executed yet.
	○ Issue with node structure
		§ If we decide to persist, not having good discoverability on parent nodes persisted data.
	○ Example Old way:
                "ChildSelector": [
                    {
                        "ShouldSelect": "C#|(await Session.GetLastActionResponseAsync()).Status == \"Failure\"",
                        "Child": "SoC_HS_RebootOnly_Failure"
                    },
                    {
                        "ShouldSelect": "C#|(await Session.GetLastActionResponseAsync()).Status == \"Timeout\"",
                        "Child": "SoC_HS_RebootOnly_Timeout"
                    },
                    {
                        "ShouldSelect": "C#|(await Session.GetLastActionResponseAsync()).Status == \"Success\"",
                        "Child": "SoC_HS_RebootOnly_Success"
                    }
	○ Example New way:
                "ChildSelectorVariable": "C#|(await Session.GetLastActionResponseAsync()).Status",
                "ChildSelector": [
                    {
                        "ShouldSelect": "C#|Session.CachedVariable == \"Failure\"",
                        "Child": "SoC_HS_RebootOnly_Failure"
                    },
                    {
                        "ShouldSelect": "C#|Session.CachedVariable == \"Timeout\"",
                        "Child": "SoC_HS_RebootOnly_Timeout"
                    },
                    {
                        "ShouldSelect": "C#|Session.CachedVariable == \"Success\"",
                        "Child": "SoC_HS_RebootOnly_Success"
                }

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.