Why is yew_router_route_parser both a compile-time and runtime dependency

[jplatte]

Hi! I've been looking into contributing to yew_router again and wanted to add span information for route parsing errors. However, it's not that easy since adding syn as a dependency to yew_router_route_parser would probably unnecessarily bloat yew_router.

Is there any documentation / could you explain how the parsing library is used at compile time and runtime respectively?

[hgzimmerman]

If I recall correctly, the general pattern used is that the macro captures the route strings from attributes and passes them to the yew_router_route_parser's parser, which then generates tokens.

These tokens are then consumed at runtime to build the datastructures that actually handle matching routes.
The yew_router_route_parser lib is used by both the router for its tokens and the macro for its parsing ability (as well as the tokens).

Conceptually, it is possible to just have the parser exist for use in the macro, and emit tokens the router crate has defined, but up until now they use the same tokens.

[jplatte]

Conceptually, it is possible to just have the parser exist for use in the macro, and emit tokens the router crate has defined, but up until now they use the same tokens.

Is this something you would like to move towards in the future?

[hgzimmerman]

Actually I misspoke. I'm entirely wrong about the section you quoted.

The parser is absolutely needed by the main yew_router crate, as it does the heavy lifting for actually parsing strings from URL paths.

You do absolutely have a point about the macro needing the parser crate as a dependency. That shouldn't be needed.

I did an incomplete look around the project and saw that the macro crate mostly (only??) uses FieldNamingScheme from the parser crate. As far as I can tell, that should probably just live in the macro crate, or if that isn't possible, just be duplicated since its just a plain untagged enum.

Edit: If it is possible to actually remove the parser as a dependency from the macro crate, there shouldn't be a reason not to merge the parser into the yew_router crate, leaving just yew_router and yew_router_macro as the crates that constitute the router feature.

[jplatte]

Cool. Is the "dissolving" of the parser crate something you'd like to do yourself? If not, I could look into it, but I'm currently relatively busy with other projects, so can't say when I would get to it.