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
I wonder if there would hv another solution of those <a> links .
let users put the whole things there like I posted above seems messy .
I prefer to let users just write the relative path like what there do in _navbar.md and we parse the router( not sure whether it is accessible now). maybe there should be an array instead of the long string.
yeah thats a good point, though currently writing markdown relative to root I guess. . , would it make more sense to be relative to _navbar.md?
nah, if the hook were relative to _navbar.md , why not just set in _navbar.md directly. 😅
but it is actually relative to _navbar.md in some way, cuz the hook can provde the context (${nav}), what they set in _navbar.md.
I thought the dynamic nav meant user can change it at each selection/page. therefore , we should expose more context for this hook. unfortunately, we render the nav and content separately. so, I hv no idea about what this hook should be right now.
At least, it has more flexibilities of the nav to users. if possible, we can hv a try for this hook and get the feedback from users.
I found that the navbar have the translation issues that it wont be replaced (no options now) when the language changed.
maybe we can use the hook to solve it also.
For what it is worth, I'd also be interested in seeing this feature added. I ran across this issue with my Docsify-This.net project and trying to re-write URL links in the Navbar to work with remote Docsify sites. I use hook.afterEach to do this for main Markdown content but discovered no way to do the same with the Navbar.
Activity
Koooooo-7 commentedon Jun 27, 2020
nice idea ! user will hv more operability of the nav.
I check it like this, it actually worked.:+1:
I wonder if there would hv another solution of those
<a>links .let users put the whole things there like I posted above seems messy .
I prefer to let users just write the
relative pathlike what there do in_navbar.mdand we parse the router( not sure whether it is accessible now). maybe there should be an array instead of the long string.pseudo code
besides that, if user wanna the deep level nav, it would be more complicated.
anikethsaha commentedon Jun 27, 2020
yeah thats a good point, though currently writing markdown relative to root I guess. . , would it make more sense to be relative to
_navbar.md?Koooooo-7 commentedon Jun 27, 2020
nah, if the hook were relative to
_navbar.md, why not just set in_navbar.mddirectly. 😅but it is actually relative to
_navbar.mdin some way, cuz the hook can provde the context (${nav}), what they set in_navbar.md.I thought the
dynamic navmeant user can change it at each selection/page. therefore , we should expose more context for this hook. unfortunately, we render the nav and content separately. so, I hv no idea about what this hook should be right now.At least, it has more flexibilities of the nav to users. if possible, we can hv a try for this hook and get the feedback from users.
anikethsaha commentedon Jun 27, 2020
this is actually a kind of better way for plugins to change the navbar content instead of doing hacky js code.
Koooooo-7 commentedon Aug 21, 2020
I found that the navbar have the translation issues that it wont be replaced (no options now) when the language changed.
maybe we can use the hook to solve it also.
paulhibbitts commentedon Aug 31, 2022
For what it is worth, I'd also be interested in seeing this feature added. I ran across this issue with my Docsify-This.net project and trying to re-write URL links in the Navbar to work with remote Docsify sites. I use hook.afterEach to do this for main Markdown content but discovered no way to do the same with the Navbar.