Skip to content

Conversation

rjmunro
Copy link

@rjmunro rjmunro commented Oct 5, 2016

As stated in the comment on lines 17-19, path can be a RegExp, or an object featuring a url and an array of methods.

As stated in the comment on lines 17-19, path can be a RegExp, or an object featuring a url and an array of methods.
* Examples for usage.
*/
path?: string | string[];
path?: string | RegExp | (string | RegExp | { url: (string | RegExp); methods: string[]; })[];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you link to the docs/implementation that say that

  • a regexp is supported for url
  • you can mix string, regexp and objects in the array (the comment says you cant)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty obscure, but I did see https://github.com/jfromaniello/express-unless/blob/master/index.js#L51-L61 and https://github.com/jfromaniello/express-unless/blob/master/index.js#L22-L24. Seems kind of a redundant API to support methods in two places.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The docs don't make it clear, but from the implementation, if a path is passed that has a URL property, the same code is recursively called with the path set to that property instead. So the url member of the object can be any kind of object that could be passed unwrapped, including stupid things like { url: { url: { url: /regex/ } } }

Again, because objects are just converted, you can mix them into the array.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case I would say we should define a type alias so we can reference it recursively.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@felixfbecker I wouldn't bother to model the api exactly like that, I'd model the parts people actually need. That functionality may go away if the code is refactored, and IMHO should not be used. It's more likely to be a bug than not.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Type alias / interface is still nicer than inline-interface because it can be referenced.

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

Successfully merging this pull request may close these issues.

3 participants