Regex: Consistency in named group, or add function

[alevinetx]

Is your feature request related to a problem? Please describe.

When the Intent recognized trigger is used with named groups in the regex, eg (?<groupName[a-z]), the named groups are accessible to assign to properties via @groupName.

However, there doesn't appear to be any other way to access named groups, like in user input validation groups or a built-in regex parser via an expression.

Describe the solution you'd like

Providing consistent behavior in regex groups, wherever used (input, validators, etc), would improve usability in data manipulation.
Also, having a built-in regex parser to use in expressions would aid in cases where the data is not being fed from an input/validator.

Describe alternatives you've considered

• Rewriting input cycles to use triggers and orchestrate them in to inputs isn't a very clean idea
• Custom actions are currently only available on ejected runtimes, which is only C# right now
• Writing my own parser to use as an expression isn't easily portable, and would need to be added on every project

Additional context

[tonyanziano]

@jwiley84 making sure this is on your radar. Please provide an update if possible.

[dmvtech]

Hi @alevinetx Thank you for the feedback. We are looking into this and will update you soon.

[alevinetx]

I was thinking about the implementation as an available function, and trying to understand how I would use it and find a balance of flexibility, composition, and coupling.

If the regex parser is an inlined function, an idea: =regexParser([pattern], [source string], someFunction(...)) where someFunction() has a scoped access to any named groups in [pattern].

However, if having to use it as a discrete step is needed, then

• the UI config screen should provide for the pattern, the source, and then N value -> property settings (user.regex-dog.name = @dogName). This is similar to the current 2 step process of a regex trigger followed by setting properties from =@nameGroup1 values; or
• the pattern could contain the destination as the group name, and the parsed values would be placed there
  -- pattern = (?<user.regex-dog.name>[a-zA-Z]*)\s ....

I'm leaning towards the discrete step, using the first option, as the best answer to the desired balance + scalability