-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
feature: support customized sidebar item name from content #1825
base: develop
Are you sure you want to change the base?
feature: support customized sidebar item name from content #1825
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 03fda8b:
|
… markdown content
22580b7
to
eb5f939
Compare
src/core/render/compiler.js
Outdated
nextToc.slug = url; | ||
_self.toc.push(nextToc); | ||
|
||
return `<h${level} id="${slug}"><a href="${url}" data-id="${slug}" class="anchor"><span>${str}</span></a></h${level}>`; | ||
return `<h${level} id="${slug}"><a href="${url}" data-id="${slug}" class="anchor"><span>${title}</span></a></h${level}>`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't tried the patch, but looking at this I would think that the sidebar text would also be used in the rendered page, but I don't think this is correct. We want the sidebar text in the sidebar but not in the page.
Have you tried this? :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I have not tried the changes, because I do not have a working frontend development environment. (I'm just a backend dev giving this a try).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, where can I find the automated tests for this file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
create a _sidebar.md https://docsify.js.org/#/more-pages?id=sidebar
I pushed some changes, but it does not work as expected :( ## How would I write an "hello, world" example? :sidebar="hello world?" could it be that the config values read by |
I've added quoted string support to the getAndRemoveConfig function and updated the tests. But I'm touching more code than I feel comfortable. and it is kinda hard to know if things are working as expected without a working dev environment; it would be most helpful if somebody could review the changes. |
Any chance anyone of the reviewers is going to review this? |
Because the provided `str` argument has been html-escaped, with backslashes stripped, we can unfortunately not support escaped characters in quoted strings.
Code has been tested and is working as intended, with the sole caveat that:
Changes can be seen in action in Docsify > Guide > Helpers documentation. |
bump |
Hi, Cheers, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @Jacco-V , Custom sidecar item name is a good purpose.
Personally, I m considering what is the good mark
to define a config content , whether we should use the "
here or not . therefore I may not approve this immediately.
For the instance, based on this PR , using the mark
to include content means this mark
can not be used. i.e.
If using "
as the mark ( :sidebar="content"
), we can not use the "
such as :sidebar="the include " content "
like you mentioned.
Instead, if we change the mark
to :sidebar={#"any content {in here}"}
like:
str = str
.replace(
/(?:^|\s):([\w-]+:?)=?([\w-%]+|{#.*})?/g,
function (m, key, value) {
if (key.indexOf(':') === -1) {
config[key] = (value && value.replace(/{#|}$/g, '')) || true;
return '';
}
return m;
}
)
.replace(/^('|")|('|")$/g, '')
.trim();
The point is what the mark
should be the common rule/guidline for those exist/future config and it should not be very common use in user content.
Any ideas?
@Koooooo-7 Yes, I can see what you mean. Architecturally speaking, it would be best if the If this was the case, we could fully support quoted strings, including escape characters. This would mean you get clean code and the benefit of a using a syntax everybody knows.
However, I'm not sure it is possible to do this, without significant changes to the code base. Having said that, from an architectural point of view, it would still be the best option. Another option would be to replace the regular-expression based 'parsing' with an actual parser, which would be able to handle escape charters even in the html formatted The other option could be as you propose: go for a different set of In the end, it is not up to me to choose which option is best suited for this project: I'm not one of the project members; I'm just a back-end guy who contributed a pull-request. |
@Jacco-V Thx for your input ! |
I haven't tested this PR, but perhaps we can work with the escaped character limitations using one of the following approaches:
FWIW, I would also change the "Customize..." sidebar labels to the following:
These labels align with the other sidebar labels under the "Helpers". As an added bonus, it removes the "customise vs customize" localization issue. I know that's not the goal of this PR, but hey, while we're here... :) |
@jhildenbiddle How you doing ~ About the The |
@jhildenbiddle This is a possibility, and it could be an intermediate solution, but it would also be another incarnation of 'sidestepping the problem', although with a better solution than introducing custom However, by sidestepping the problem, you continue building on non-robust legacy choice and will need to add increasingly complex regular expression(s) to hammer the non-ideal setup into a working solution. So, I agree with @Koooooo-7: Going the |
@Jacco-V, @Koooooo-7 -- No arguments from me about the issues with building upon problematic legacy code. My comment was intended only to propose a way to make the stated drawback of this PR -- the inability to support escaped characters in quoted-string config-values -- less of an issue so that we can deliver a solution sooner. If someone wants to take a crack at doing things the "better" way, I'm all for it. |
Add support for setting a customized sidebar item name from the documentation markdown content
See also issue: #1821
Summary
This feature add support for specifying custom sidebar item names (especially for long titles) in the documentation markdown files, so that a the custom (typically shortened) item name is used in the sidebar:
## How would I write an "hello, world" example? :sidebar="hello world?"
What kind of change does this PR introduce?
Feature
For any code change,
Does this PR introduce a breaking change? (check one)
If yes, please describe the impact and migration path for existing applications:
Related issue, if any:
Tested in the following browsers: