Looks promising! Want to include before/after screenshots to this thread, based on the description in #4965?

I can confirm that this works for our API, where everything is nested below v1/. There are some CSS issues, but they are independent of the nesting.

I'll try to add screenshots tonight

Before (nothing happend when clicking on the todo menu):

After (tree partially deployed):

After (menu fully collpased)

Thanks for the PR. I've tested on the API scheme like shown at the end of this comment.

Documentation display works fine (I'm not able to see documentation content on the DRF 3.6.2). However there are two issues I can see:

• Sidebar displays only two levels and the second level looks exactly as a top level.
  Collapsed view:
  
  Expanded view:
  
• There are duplicated anchors and as a result the do not work as expected. Probably we should build anchors using a full "path". Like:
  • #admin-api-v2beta-documents-list
  • #api-v1-documents-list
  • #api-v2-documents-list, etc

<Document "http://localhost:8000/api/">
    admin: {
        api: {
            v2beta: {
                documents: {
                    list([offset], [limit], [tags], [id], [title], [order], [search], [search_operator])
                    read(id)
                }
                images: {
                    list([offset], [limit], [width], [height], [id], [tags], [title], [order], [search], [search_operator])
                    read(id)
                }
                pages: {
                    list([offset], [limit], [title], [search_description], [seo_title], [latest_revision_created_at], [show_in_menus], [id], [first_published_at], [slug], [child_of], [descendant_of], [order], [search], [search_operator])
                    read(id)
                }
            }
        }
    }
    api: {
        v1: {
            documents: {
                list()
                read(id)
            }
            images: {
                list()
                read(id)
            }
            pages: {
                list()
                read(id)
            }
        }
        v2: {
            documents: {
                list([offset], [limit], [tags], [id], [title], [order], [search], [search_operator])
                read(id)
            }
            images: {
                list([offset], [limit], [width], [height], [id], [tags], [title], [order], [search], [search_operator])
                read(id)
            }
            pages: {
                list([offset], [limit], [title], [search_description], [seo_title], [show_in_menus], [id], [first_published_at], [slug], [child_of], [descendant_of], [order], [search], [search_operator])
                read(id)
            }
        }
    }

Took a first pass review over this, but I'm going to need to come back to it at a later time, since it's quite a large footprint.

Thanks for this PR. I've had similar issue and the code helped a lot!

However, I have a suggestion for the _recursive_*.html templates. Instead of:

{% if section.links.items %}
    ...
{% else %}
    {% include ... with items=section.items ... %}
{% endif %}

Consider doing this:

{% if section.links.items %}
    ...
{% endif %}
{% include ... with items=section.data.items ... %}

In my case, I have a viewset with a nested route that essentially looks like this:

class UserViewSet(ListModelMixin, RetrieveModelMixin, ..., GenericViewSet):
    ...
    @detail_route(methods=["post", "delete"])
    def follow(self, request, *args, **kwargs):
        ...

(I have a hacked SchemaGenerator.get_links to mess with the follow's Link._fields, since I use non-standard serializers there... but it doesn't matter here.)

The problem is, at the same odict level there are both links (user.list, user.retreive) and sub-documents (user.follow with links user.follow.create and user.follow.delete), so with the current implementation "Follow" doesn't show up at all. While I'm not exactly sure it's a good idea or if this is acceptable with CoreAPI schemas or I'm doing it all wrong, coreapi-cli works just fine, and with the template changes above all the nested routes show up as they should.

Just noticed one thing. I haven't checked the HTML spec, but it seems that code like data-toggle="collapse" data-target="#users/follow-dropdown" is problematic, and IDs should only use dashes. At the very least, it fails with "Error: Syntax error, unrecognized expression: #users/follow-dropdown" for me on Firefox 52 (although it could be that I've misunderstood the patch when I've copied the changes - sorry if it's the case!)

Maybe it would be smarter to have prefixes as lists or tuples rather than strings. add filter works on those just well, and this way split_keys won't be required, as all manipulations would be possible using join or for loop.

Thanks for the input here. We've gone with #5334 in the end.