-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
allow the el option to accept an HTMLElement instance
#1712
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
Conversation
This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.
🔍 Inspect: https://vercel.com/docsify-core/docsify-preview/GFgr7UN6pNmBGZEaRQrskSY52E5t
✅ Preview: https://docsify-preview-git-element-value-for-el-option-docsify-core.vercel.app
|
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 c8141f7:
|
This aligns it with what the docs were already saying erroneously, plus this is useful in cases when people have refs to an element already (embedding Docsify in a custom element shadow root, or in a React component that has a ref to the target element, etc).
408a4e0 to
00a8731
Compare
I realized that dom.getNode() has similar logic as what I implemented here. Using that would make this PR shorter.
- use dom.getNode instead
Uh oh!
There was an error while loading. Please reload this page.
Summary
The
eldocs saywhich wasn't true. This change updates the code to match the docs.
Additionally this allows Docsify to be embedded in custom elements or components systems like React/Vue/Solid/etc where normally people have a reference to an element.
What kind of change does this PR introduce?
Bugfix?
Feature?
For any code change,
Does this PR introduce a breaking change? (check one)
Related issue, if any:
Tested in the following browsers: