Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal for Enhanced Syntax to Access Request, Folder, and Collection Metadata in Bruno #3817

Open
helloanoop opened this issue Jan 16, 2025 · 1 comment

Comments

@helloanoop
Copy link
Contributor

helloanoop commented Jan 16, 2025

Proposing a standardized syntax for accessing metadata and file attributes associated with requests, folders, and collections in Bruno.

Background

Please note that Bruno supports name of the request to be different from the name of the file.
Same goes for folder name. This is in development and will be merged soon. Below is a video demo of the same

request-folder-names.mp4

PR: #3094

Proposal

With that in mind, here is the proposed syntax for accessing request, folder and collection name.

Getting Request, Folder and Collection Name

This is stored in meta tag in bru lang and is what appears in the request name in the UI
Assume a file at /Users/john/payments-collection/folder/request.json

meta {
  name: Custom Request Name
}
Property Syntax Output
req.name Custom Request Name
req.folderName folder
req.collectionName payments-collection
Method Syntax Output
req.getName() Custom Request Name
req.getFolderName() folder
req.getCollectionName() payments-collection

Getting Request File

Assume a file at /Users/john/payments-collection/folder/request.json

Shorthand Syntax Output
req.file.path.absolute /Users/john/payments-collection/folder/request.json
req.file.path.relative folder/request.json
req.file.name request.json
req.file.basename request
req.file.extname json
req.file.dirname folder
Method Syntax Output
req.getFile().getAbsolutePath() /Users/john/payments-collection/folder/request.json
req.getFile().getRelativePath() folder/request.json
req.getFile().getName() request.json
req.getFile().getBaseName() request
req.getFile().getExtName() json
req.getFile().getDirName() folder

Related Issues / PRs

@nikischin
Copy link
Contributor

nikischin commented Jan 16, 2025

Hi @helloanoop and thank you for the proposal.

For me this seems reasonable, however I don't know all implications it may have.

Just to give one example:
I might have a collection containing a structure like this

SomeFolder

  • getItems
  • getItem

SomeOtherFolder

  • getItems
  • getItem

For the current implementation, if I call bru.setNextRequest("getItem") in SomeOtherFolder/getItems, it will call SomeFolder/getItem.

In my opinion, this is not the expected behavior, as I would expect to prefer requests in the current folder instead of any other ones. Because of this behavior, in the runner, this leads to an endless loop as it always jumps back and forth. This belongs to a separate bug ticket for sure (not sure if I already opened one for this) but with Folder and Request Names not being the same as the file name it could get even a bit more complicated here.

Not trying to say this is getting worse with these proposals, but at least something we should keep in mind.

Generally I am a Fan of the concept of having Request Names and File names separated, and was wondering if this could even allow same Request Names within one collection. Let's say I have two variations of the same API Endpoint I am testing, I could give them a name like setMySampleRequestData (only title) and setMySampleRequestData (all fields), but honestly, as this name would be too long to display in the sidebar anyhow, and just reduces the number of the visible tabs, I could also just name both setMySampleRequestData without a visible difference in the name and have the file names like setMySampleRequestData-1 and setMySampleRequestData-2.

This however, to return to the previous challenge makes me think if we should hand over the file names or maybe even relative file paths to functions like bru.setNextRequest in order not to run into issues like the one mentioned above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants