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

Why is this.path set to undefined instead of path? #122

Open
IamLizu opened this issue Sep 25, 2024 · 10 comments · May be fixed by #123
Open

Why is this.path set to undefined instead of path? #122

IamLizu opened this issue Sep 25, 2024 · 10 comments · May be fixed by #123
Labels

Comments

@IamLizu
Copy link
Member

IamLizu commented Sep 25, 2024

Can someone please help me understand why this.path is set to undefined?

this.path = undefined

I had checked the router Layer, and the path was undefined in almost every route, that shouldn't be the case, right?

While I don't know the reason of it being set to undefined initially, I can suggest it should be set to path. I have noticed that the path on Layer is no longer undefined if we set,

this.path = path;

Instead, it gets correct path such as /users or whatever the path actually is.

@IamLizu IamLizu linked a pull request Sep 25, 2024 that will close this issue
@IamLizu
Copy link
Member Author

IamLizu commented Sep 25, 2024

Related expressjs/express#5961

@carpasse
Copy link
Contributor

It seems that this.path is being set to undefined because we can't determine what path the Layer is matched against until runtime.

Let me explain my thought process: Layers are added to the Router instance when the use and route methods are executed.

The Router.prototype.run method only accepts a string as path, but Router.prototype.use can accept either a string or an array of strings. You can refer to the Express documentation for more details.

We can't know which of the possible path values was matched until the layer is actually matched at runtime, as seen here.

To address the issue discussed in express#5961, perhaps we could add an extra property to the Layer instance, such as paths or pathPatterns. This would make it possible to list all routes or a router.

@pillarjs/express-tc, can we get your input on this matter?

@IamLizu
Copy link
Member Author

IamLizu commented Oct 5, 2024

Thank you for the explanation @carpasse.

I still have some confusion, for example, the actual matching against a request's path happens at runtime. However, if we set the Layer's path property when the Layer is created, will it create any issue?

Edit: Since the path is from request is being passed to matchLayer which is checking and setting the path to Layer in runtime, it might add a little cost but perhaps its negligible? On the other hand, instead of adding a new property, maybe we could set path during Layer creation which helps debugging.

PS: I really have very little idea, I am trying to get a better understanding.

Edit: I wonder whether any other part depends on this.path being undefined. I will try to dig in.

@carpasse
Copy link
Contributor

carpasse commented Oct 7, 2024

@IamLizu I believe the path argument passed to the Layer constructor represents either a list of handler paths (as an array) or a single string. To improve clarity, It may be best to rename that constructor parameter to something like pathPatterns or layerPaths, as I think it better reflects its purpose.

Additionally, the path property is expected to hold the matched portion of the runtime path based on the patterns passed to the constructor.

  • This path is a substring match of the runtime path, not directly one of the paths passed to the constructor. Reference 3
  • The path property cannot be defined until it has been matched against a runtime path. Reference 4
  • After the match, it is effectively defined as layerPath, and then used to trim off the matched portion from the runtime path. Reference 5

@carpasse
Copy link
Contributor

carpasse commented Oct 7, 2024

cc @wesleytodd as repo captain

@wesleytodd
Copy link
Member

Yep pretty much what @carpasse has said. One thing I might ask is "what is the goal of the question"? Did you have an outcome you are looking to achieve, or is this more about exploration and learning? If the goal is listing all the routes (as is referenced near the top) then there are a bunch of discussions on that that might provide more context. But before spending time (I still have nearly 300 issues I am trying to catch up on), can I ask for a more clear explanation of the goal?

@IamLizu
Copy link
Member Author

IamLizu commented Nov 23, 2024

Thanks @carpasse for the explanation. I will read thoroughly and get back you if I still have questions.

@wesleytodd actually the outcome is nothing else than listing the routes. It appears setting the path to this.path instead of undefined helps easily listing the routes.

@mxngls
Copy link

mxngls commented Jan 8, 2025

I wanted to chime in on the discussion to provide a bit more context on why something proposed by @IamLizu might be needed. Wesley's package express-openapi seems to work properly for express version 4, but not version 5. As far as I can tell mostly for the same reasons @carpasse explained above (though the first error I received while trying to use the package myself with an express app using version 5, was actually a complaint about the undefined fast_slash property).

I tried to reverse-engineer the package and fix the issue myself. It actually works pretty well, except for the fact that there is no way of obtaining paths for registered middleware (nested routers for instance!).

To come back to Wesley's original question, the goal of adding some kind of static path property would be to allow to generate OpenAPI docs in a reliable way. The actual grunt work that might be necessary to get rid of wildcards or other things mangling the path string(s) in a way that's incompatible with the OpenAPI spec might then simply be left to the user. This, at least in theory, doesn't create much additional work to maintain and provides users with an ergonomic way of obtaining paths for routers.

@wesleytodd
Copy link
Member

Ah yes, one of my goals over the next weeks is to update that open api package. I was just slammed with other things through the end of last year. @mxngls if you are interested in helping with that work I might be able to give a few pointers. Honestly I think express/router itself should have some better apis for this kind of thing so that third parties dont have so much work to do for compatibility in as we make future changes. So might be we could work on landing that kind of stuff here as well to help.

@mxngls
Copy link

mxngls commented Jan 9, 2025

Thank you for your swift response @wesleytodd. Actually I already came up with a solution, that works quite well. I might have time to publish the refactored package over the weekend. I think to get rid of regular expressions for paths was a good decision overall. The work that was necessary to correctly parse these paths with regular expressions seems incredible convoluted and quite error prone.

I intend to make the first version only compatible to Express version 5 and upwards for the same reasons. What is still left to do is to transform the paths as used by Express to something that is accurate to the OpenAPI specification. I don't think this will prove to be too cumbersome, as we only need to adjust the syntax for regular and optional parameters. Wildcard parameters are not conform to the spec anyway. I would love to ping you again and if possible get some input from your side. The package itself is written in Typescript and considerable leaner than the original express-openapi package written in Javascript. But I think it would be better to move that talk into a separate discussion as it's not really an issue.

Lastly I fully agree regarding your comments on adding some proper APIs to Express so that obtaining router paths is not as arduous as it is right now.

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

Successfully merging a pull request may close this issue.

4 participants