sycamore
sycamore copied to clipboard
Router improvements
Router bugs/improvements:
- [x] #125
- [x] #123
- [x] #122
- [x] #121
- [x] #124
- [x] #129
- [ ] #130
A couple things I noticed:
- The ability to have a loading state is great! Looking through your implementation in the docs, the relationship between the loading effect and the loading text is a little unclear. I'm not critiquing here, just wondering if that is the Sycamore standard. Is it possible to use if/else or matching in an async situation like this?
- It looks like the routing reruns when clicking a link to the current page. I'm guessing that might be resolved by using plain
<a>tags, but what are your thoughts there?
- The ability to have a loading state is great! Looking through your implementation in the docs, the relationship between the loading effect and the loading text is a little unclear. I'm not critiquing here, just wondering if that is the Sycamore standard. Is it possible to use if/else or matching in an async situation like this?
This is just because I need to set the inner html rather than inserting the generated html as plain text. Right now, the only way to do so is via NodeRef. Eventually, I would like to pre-compile the markdown to html so we don't need to ship the markdown parser in the wasm. There should also eventually be something like React's dangerouslySetInnerHtml.
- It looks like the routing reruns when clicking a link to the current page. I'm guessing that might be resolved by using plain
<a>tags, but what are your thoughts there?
This can probably be easily fixed be extracting this...
https://github.com/sycamore-rs/sycamore/blob/ffc1f4561d3c0e20e1a0a9b655d26f47f5aef4bf/packages/sycamore-router/src/router.rs#L84-L90
...into a create_selector which will only trigger a change if the new value is different from the old value. I'll be happy to accept a PR if you want to do it :)
I believe native browser behavior is to ignore same-page link clicks, so this problem would go away once the first task is done.
I believe native browser behavior is to ignore same-page link clicks, so this problem would go away once the first task is done.
That's not my experience. The browser only ignores same-page link clicks if the url has an anchor at the end (so ./#). In any case, doesn't hurt to add a check.
This is possibly just something that needs to be made more clear in the docs but it's not obvious and possibly not ideal that a Router Component must have exactly one node it is routing for. The panic that occurs if you have more than one node cost me about an hour of debugging before I realized why it was throwing there. The example in the tutorial/book has a single node but it doesn't mention that as a requirement of the router so it was confusing.
This is possibly just something that needs to be made more clear in the docs but it's not obvious and possibly not ideal that a Router Component must have exactly one node it is routing for. The panic that occurs if you have more than one node cost me about an hour of debugging before I realized why it was throwing there. The example in the tutorial/book has a single node but it doesn't mention that as a requirement of the router so it was confusing.
Yes you're right but I believe a better solution would be to actually fix the issue and allow Router to take multiple children rather than adding an additional note. I'll be sure to fix this for the next release
Cool, I thought about trying to submit a patch but I'm too new to the sycamore code and don't have enough time in the day :-)