You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Setting target="_self" reloads the entire app when navigating #304
target="_self" is the default vale for links, so it should not be necessary to specify it. However, when specified, entire page is reloaded when clicking on an A link.
This behavior is problematic, for example, when A is passed to a third party library to render links, as is the case with solid-markdown.
Ultimately users need a way to identify anchors that should be handled by the router (without a page refresh) from those that don't - ie because they're handled by some other back-end service outside the App.
The router currently has 3 ways (I think) to determine if it should ignore an anchor...
if the <a> does not have a link attribute then the router ignores it. <A> does that for you by returning <a link .../>.
if the <a> has a target then the router ignores it.
if the <a> has particular rel attributes (download or external) then the router ignores it.
It seems like you are running into 2. There will be apps out there that use that method to get the router to ignore some anchors though - so not sure what the impact would be to change it now.
Even the new approach (since Oct 2022) of <A> automatically adding the link attribute has limitations.
For example you might create your own <FancyA> component (perhaps in a library) that internally renders an <A>. That is all great ...until you want <FancyA> to not be handled by the router. You then need to fallback to options 2 or 3 above with <FancyA target="_self"> having the least impact.
Activity
Brendan-csel commentedon Oct 24, 2023
There is some history here I think.
Ultimately users need a way to identify anchors that should be handled by the router (without a page refresh) from those that don't - ie because they're handled by some other back-end service outside the App.
The router currently has 3 ways (I think) to determine if it should ignore an anchor...
<a>does not have alinkattribute then the router ignores it.<A>does that for you by returning<a link .../>.<a>has atargetthen the router ignores it.<a>has particularrelattributes (downloadorexternal) then the router ignores it.It seems like you are running into 2. There will be apps out there that use that method to get the router to ignore some anchors though - so not sure what the impact would be to change it now.
aryzing commentedon Oct 24, 2023
Do you mean
<a>or<A>? Seems that<a>is by default outside the router's control no? Isn't that the goal of having a router-aware<A>?Brendan-csel commentedon Oct 24, 2023
<A>just renders an<a link>in the DOM. The router listens for clicks on all<a>s and figures out if it should handle them (or not).Relevant code in routing.ts
Brendan-csel commentedon Oct 24, 2023
Even the new approach (since Oct 2022) of
<A>automatically adding thelinkattribute has limitations.For example you might create your own
<FancyA>component (perhaps in a library) that internally renders an<A>. That is all great ...until you want<FancyA>to not be handled by the router. You then need to fallback to options 2 or 3 above with<FancyA target="_self">having the least impact.aryzing commentedon Oct 24, 2023
Understood, seems it's working as intended, will close then. Thanks for clarifying @Brendan-csel