[Feature request] embed docsify on third party site

[dur41d]

Docsify is great but I find I can only use it in a dedicated website. It would be more flexible if docsify can be embedded on other sites. Although it's possible in theory but in practice I found that it doesn't work well.

For example: I wanted to use docsify to generate the documentation on this site:

https://uis-azr-test-fusionapi-eus1.portal.azure-api.net/user-guide-2

When I embedded docsify into the html if found that it completely changed the layout of my website. I think one of the reasons is that it modified the nav of the website.

I ended up using flatdoc which doesn't have the same features but it's less intrusive on the host website.

[trusktr]

This would be great to make this easier (f.e. not overriding existing <nav>)

[trusktr]

With the refactors that I recently did to move Docsify into its own file that has no side-effect of automatically loading Docsify into the DOM (see src/core/Docsify.js), I can imagine a simple way to do this initially as a non-breaking change (no custom element in this case), so I'll put it in 4.x.

Basically, we just tell Rollup to compile an additional bundle using src/core/Docsify.js as the entry point. In this case, the user can place a script tag pointing to this new bundle and manually instantiate new Docsify, while the previous bundle will still exist so all existing sites work the same way.

Users of the new bundle will be able to do this:

new Docsify({
 el: '#somewhere',
})

This will be very handy for integrating into existing websites while keeping them single-page apps, for example.

[pauldraper]

Any hope for this?

[pauldraper]

There are a number of issues with using docsify as a component.

For example, it registers global handlers when setting up routing.

That is, teardown will be a problem. (And I think it might even interfere with existing <a> on the page.)

[trusktr]

Let's list the things we need to fix right now to get this is good enough shape with minimal changes (bigger changes for later):

• fix <nav> issue. ability to specify the nav element #1525 will fix this.
• Ensure Docsify instances can be cleaned up (teardown route handlers, link click handlers, etc). Handled by Add a dispose() method to Docsify to clean up the instance #1719

it registers global handlers when setting up routing.

@pauldraper Can you expand on this? Would you like Docsify to perform routing internally without modifying the URL path (because the outer application is doing that)? Or you still want the same behavior, but with ability to teardown when switching away from a docsify-containing view?

[pauldraper]

Modifying the URL path is fine (for me at least).

But I do need to teardown listeners, or at least not cause a memory leak by double registering them.

I haven't looked at the implementation.

[paulhibbitts]

This is now possible with https://Docsify-This.net which is open source and can be further customized including hosting your own instance, so closing this issue.

[onionhammer]

Docsify-this, unless I'm misunderstanding what "docsify-this" does (generate a complete public website based on public markdown files), feels somewhat like the opposite of what this issue is requesting?