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

0.8.0 Feature List #35

Closed
3 tasks done
ibraheemdev opened this issue Jul 28, 2023 · 7 comments
Closed
3 tasks done

0.8.0 Feature List #35

ibraheemdev opened this issue Jul 28, 2023 · 7 comments
Labels
feature New feature or request

Comments

@ibraheemdev
Copy link
Owner

ibraheemdev commented Jul 28, 2023

@ibraheemdev ibraheemdev added the feature New feature or request label Jul 28, 2023
@jplatte
Copy link

jplatte commented Jul 28, 2023

I think I read a discussion about the new syntax before, this will include escaping { and } with {{ and }} just like in Rust's format! strings, right?

@ibraheemdev
Copy link
Owner Author

@jplatte yes. Catch-all routes will also be specified within the { } as /foo/{*wildcard}.

@ibraheemdev ibraheemdev changed the title 0.8.0 Breaking Changes 0.8.0 Feature List Aug 3, 2023
@ibraheemdev
Copy link
Owner Author

With {} parameters, we also run into more interesting conflicts. For example, given /{foo}.{bar} and /{foo}b{bar}, what does /ab.cd match? Both are /{ab}.{cd} and {a}b{.cd} are matches, but without a user-given priority the choice is unclear, so the routes should be considered conflicting.

There are two rules that I can see working for conflicts:

  1. Only allow a single specialized pattern per route segment. e.g. /{foo} and /{foo}.{bar} is fine, but adding /{foo}b{bar} causes a conflict.
  2. Allow multiple specialized patterns as long as they contain a different number of parameters. e.g. /{foo}, /{foo}.{bar}, /{foo}.{bar}.{baz} are fine, but adding /{foo}-{bar} causes a conflict. Specializations with a larger number of parameters take priority, e.g. /foo.bar.baz matches /{foo}.{bar}.{baz}, not /{foo}.{bar.baz}.

I'm leaning towards option 1 for simplicity's sake, and I'm not sure how much value option 2 would add.

@jplatte
Copy link

jplatte commented Dec 30, 2023

Hey @ibraheemdev, could you use any help with this? Looks like we'll want to ship axum 0.8 sooner rather than later (maybe around end of Q1'24, but that's entirely my personal guess) and it would be great to have the new matchit with different routing syntax included.

@ibraheemdev
Copy link
Owner Author

ibraheemdev commented Jan 4, 2024

@jplatte Thanks for the reminder. I have most of the work finished locally, just need to clean some things up. It should be done by then, if not I'll try to have a 0.8 release with the new syntax that's still restricted to the old conflict rules to avoid delaying the inevitable breaking change further.

@Totodore
Copy link
Contributor

Totodore commented Mar 10, 2024

Hey @ibraheemdev, #49 will be part of this version? Or do you plan to release it later? It is a feature that I would really need for my lib socketioxide.
Thanks for your work :).

@ibraheemdev
Copy link
Owner Author

0.8 has been released! See the release notes for details.

@Totodore we can get #49 merged with a minor version bump now once it's ready that the major changes are out of the way.

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

No branches or pull requests

3 participants