-
Notifications
You must be signed in to change notification settings - Fork 157
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
Support implementing Route
on struct
s
#244
Comments
Also, this technically wouldn't need to move Sycamore to v0.7.0:
Quoted from Semantic Versioning spec item 4. |
As I look at the code in further detail, I'm seeing that this would require significant changes to the routing model, and would only be suitable as a longer-term feature. |
For anyone else encountering this problem, I advise you generate an @lukechu10 if you think this more flexible routing model is worth pursuing in the longer-term for albeit a very niche use-case (framework building), please re-open this issue! Otherwise, the solution above will be sufficient for now I think (for me at least). |
I think the best way to solve this issue is to provide a way to opt-out of the Router attaching a click handler. |
That may be good long-term, but I don't think that's the crux of the issue anymore. As described here, the principle issue appears to be that Sycamore executes Perseus' routing logic properly, but then doesn't continue on to run the closure provided to the |
I'm now trying to remove the magic from Perseus, and I've found myself back at this problem! The issue is that I need to be able to get three Perseus properties (the render config, the templates, and the locales) into the logic the It would be really useful if Sycamore could support taking the |
Currently, Sycamore explicitly states that the
Route
trait is forenum
s, and as such its methodmatch_route
doesn't take theself
parameter. However, there are use-cases (such as Perseus) for which routes may be stored in astruct
, and can only be accessed through theself
parameter. I've explored global variables and contexts as possible solutions to this problem, but the former ends up requiring generation of core types and the latter becomes quickly infeasible due to the nature of reactive scopes.Hence, I would propose that the
Route
trait's methods take theself
parameter so that they can be feasibly implemented onstruct
s as well asenum
s. In theory, I would think this should be relatively simple, especially because the rest of the user-facing interface should be able to stay exactly the same, though some changes would be needed to the derive macro forRoute
.The text was updated successfully, but these errors were encountered: