Hierarchical Folders - Javascript Hack (advanced, unstable)

A complete and utter hack that can break at any time, but I’m using it for personal projects and thought I’d share. NOTE: Re-ordering folders is currently broken!

This allows for hierarchical folders by re-ordering the website as it renders, and the folders’ hierarchy can be controller through a table named “Folder Hierarchy” on that document.

(Not the most user friendly, but this is a proof-of-concept)

  1. Install a javascript injection plugin for Chrome. E.g.: “User JavaScript and CSS”
    a. Setup Arrive-js as a library: https://cdnjs.cloudflare.com/ajax/libs/arrive/2.4.1/arrive.js
  2. Setup javascript: https://gist.github.com/gjroelofs/554474a20482f00d2c3c666d3ec50b85
    a. Test whether everything is setup correctly by going to this document and verifying that there is a hierarchical section that looks like this:


Then you can either copy the table from that document, or set it up yourself:

  1. EITHER:

    1. Copy table from this document into your own (ctrl-C / ctrl-V, then click “Paste Options” and select “Columns Only”). The only columns you’ll use in this table are Section and Parent. The rest ensure that the table is ordered & displayed such that it’s easy to overview.
    2. Create table named Folder Hierarchy - (Or Copy from the example Document below)
      a. Setup columns: Section (text), Parent (Select List), Children (text).
      b. Use option formula [Folder Hierarchy].Filter(CurrentValue != thisRow) for Parent .
      c. Use formula [Folder Hierarchy].Filter(CurrentValue.Parent=thisRow) for Children
  2. Setup rows with sections you want to parent. Section denoting the section name as displayed in the hierarchy.

Known issues:

  • Reordering Sections is broken.
  • Need to clean up global variable declarations.


  • Rewritten initialization ordering so it is ensured to happen after API callback, avoiding ordering issue. Added in DEBUG option for displaying logs.

:flushed:wow looks awesome!

For god sake make this a real feature.
Monolithic docs can be done, but the organization is sooooooo limited with only one folder and your usability starts to crack.
Now “coda pack” is crawling and Microservices is a little clunky right now, but is the best way to go.

Please, let us make at least a second level of folders (aka subfolders). This can improve so much the structure of the docs.

And we need folders for store a collection of docs too, now with cross docs we need control the multiple docs that we are constructing for admin privileges and so on.

It’s being talked about at great length and we’re getting there.

If you check out our feature updates, I think you’ll see that we’re working on these items non-stop.


I believe this is the kind of thing that’s been in the Roadmap for long, but Coda don’t actually have a roadmap that I can lookup :clown_face:

And I really can’t know that just looking the updates, i have to go all the way down to find a direct mention to folders.

But thanks, I was just looking that someone confirm that this is not being forgot :+1:

In defence of @BenLee and Coda, the problem is that the team needs to find a single solution in a system that is so flexible that many competing, and sometimes incompatible, requests pop up from the community.

My hacks and musings (see wiki page-as-row thread) are also just efforts to see how I should be using Coda.

1 Like

Coda is a conceptual and factual revolution.

It has offer us so many advantages that we bet on it as the winner of the work management wars.

When I compare it with node, for instance, I identify a lot of advantages on Coda camp. However, I do identify two main advantages:

  1. Hierarchical elements. Not folders and sections, but a hierarchy. if the basic element of Coda is a document, a document has a TOC. And a TOC has nested headings, not only two levels of headings

  2. Full-fledged mobile client. With notion I can do almost whatever I want with an iPad. However, and although a coda “app” in a phone is nice, I cannot modify it with an iPad

As I said before, I’m not sure if there is a limitation by design about folders and sections. I don’t know Coda back-office or architecture. If there is no architectural limitation, then I don’t understand why you codans let notion maintain such meaningful advantage

1 Like

The other problem as well is that having hierarchical sections would naturally massively expand the size of a document, which may be something that was never anticipated by Coda (or at least anticipated at this stage).

I’ve spent the better part of this week testing (and scrapping) Coda architectures for receiving the migration of a large hierarchy from a competing app. Suffice it to say, I can’t wait for Coda to solve the hierarchy problem! :smiley:

Some freshly squeezed :tangerine: thoughts on hierarchy:

-Bulk selection.
-KB shortcuts.
-By level (expand to level 3, or collapse to level 2).
-By selection (expand THIS level 3, or collapse THIS level 2).
-KB shortcuts.
Conditional Formatting.
-“If level 2, then…”
-“If child of level 3, then…”
Efficient use of screen space. Using current grouping functionality to create hierarchy consumes massive amounts of horizontal screen space. (Coupled with non-frozen row/header columns, this quickly becomes unworkable because the user loses navigational markers.)

2) CODA DNA. Ideally, the modular hierarchy experience will become a part of Coda’s UX DNA, applicable to as many Coda objects as possible, like canvas, rows/groups, rich text columns, tables of content, side bar menu, and many other objects yet to be invented.

3) STRUCTURAL. As the visual hierarchy is modified, the data structure is also modified to reflect changing parent/child relationships (especially for the automatically generated source tables of objects like table rows/groups or columns).