Introduce convenience method for get commands

[waldekmastykarz]

Currently, when using get commands, you need to specify which item you want to retrieve, either by its URL, ID, name, etc. In some cases you know the identifier upfront, but often you need to run the corresponding list command first to get the identifier and then run the get command with the right ID.

What if we could simplify this experience by introducing a convenience mode for get commands that would combine the list and get functionality in a single command? For example, imagine you'd run spo site get --interactive. Since there is no URL specified, the spo site get command will first retrieve all sites using spo site list. Then, it will provide you with a prompt to select the site that you'd like to get. After selecting a site from the list, the CLI would execute the spo site get command with the selected site.

The convenience switch could be triggered either explicitly through a separate option like --interactive, or implicitly, when no identifier has been specified in a get command.

What do you think @pnp/office-365-cli-maintainers?

[garrytrinder]

Interesting observation @waldekmastykarz

I think that this would be good default behaviour of a command rather than introducing a specific switch to invoke such behaviour.

In the example you gave for spo site list, I would see the behaviour of what you propose as being something like the below

$ o365 spo site get
1) Landing - https://contoso.sharepoint.com
2) Benefits - https://contoso.sharepoint.com/sites/benefits 
3) News - https://contoso.sharepoint.com/sites/news
Select site: 1
... <output>

[waldekmastykarz]

How about we try to implement it in one command to see how the changes would fit the code base and the UX and take it from there? I think spo site get could be a first good candidate for this, don't you think?

[garrytrinder]

Agreed 😊

[appieschot]

Yes definitely makes sense to me, can't really recall any cli implementations doing things like that, so find it hard to compare for 'best practices'. But 👍 from me.

[phillipharding]

Agree this could be a nice feature to have, but just a thought though, when there are a large number of "things" to select from, sites for example, when there are large number of sites the selection process might be more frustrating than productive?

Could there be some simple pre-filtering of the list of "things", sites is easier to reason around this so maybe options to pre-filter like;

1. Site Template
2. Created/Modified within the last X days
3. Created/Modified between X and Y
4. URL's/Title's beginning with/containing "XYZ"

[phillipharding]

Makes sense @waldekmastykarz

If we assume that * means 0 or more of any character, this would neatly translate to a RegEx allowing the wildcard to appear anywhere in the supplied url

suppliedUrl = "*project-1*";
const pattern = `^${suppliedUrl.replace(/\*/gi, ".*")}$`;
// ::> ^.*project-1.*$
const r = new RegExp(pattern, "gi");
...
r.lastIndex=0; 
isMatched = r.test(site.AbsoluteUrl);
...

[waldekmastykarz]

Yes and no. What if the string in between contains special RegEx characters like .? Then, they'd need to be properly escaped first. I suspect there might be other edge cases as well. So for starters, I think it would be easier to use the regular string methods, like startsWith, endsWith or indexOf() > -1 and switch to RegEx later after we confirmed that the concept works as intended and there is a demand for it.

[waldekmastykarz]

If we agree to start with the basic setup I proposed, then I can write a spec for it and we can get going 💪

[phillipharding]

agreed, sounds like a plan 👍

[waldekmastykarz]

Appreciate your help @phillipharding! ❤️