Meaningful conversation happens when everyone in the room has heard each other’s thoughts, and a flat, linear timeline has always been the best way to make that possible on Discourse. But flat doesn’t fit every community. In larger, faster-moving forums, thousands of replies on a single timeline make it impossible for anyone to keep up. That’s why we’ve been cautiously experimenting with a fully nested reply view this year, and we think it’s a great fit for communities that have outgrown the flat format.
What started as an experimental plugin, shifted to a project shipping directly in Discourse. Here is a peek at what a nested topic looks like at the moment:
The site settings to enable this feature are available in the admin interface. Navigate to the “Nested Replies” section to control the feature, default sort modes, max depth, and more.
Roadmap
At the time of writing, it’s early days for nested replies. The roadmap is not fully fleshed out. A few things we know we will do:
Better mobile experience
Rethink the topic timeline for nested view. At the moment there is no timeline on topics while in nested replies mode
Add at least one new ordering mode for posts with age decay, similar to our “Hot” for topic lists.
Limitations
When nesting is enabled for a category, pre-existing topics stay in flat mode. Each topic can individually toggled from the admin wrench, but there is currently no way to convert an existing category to nested mode.
We’d love your feedback
We need your feedback and experience using this feature to help inform it’s development. If this looks like a good fit for your community, give it a go, and tell us what you and your users think!
OMG YES. excellent timing too. i am migrating a forum to a new server with 2-container tonight and i can’t wait to turn this one for the new one when regular season and our sports pools begin in a couple weeks. this should be a good test use-case too.
it will be so cool to have the options of both flat and embedded discussion - thank you for this @markvanlan and Team.
Just to note: when there are new replies in multiple branches of the tree, it looks like the single-thread view only showed me one at a time. I had to revisit several times, with the unread count going down by one each time.
Yes I do agree with you. This is a limitation for now, and something we will absolutely keep thinking about.
The big reason why I chose not to convert historical topics in a category when it is enabled, is that users are likely going to interact differently. In flat mode, the various Reply buttons don’t matter as much. The post is going at the bottom of the topic. I’m not sure users always intentionally press the “right one” that would translate to the nested view.
Basically I worry that admins will enable it for historical topics and then suddenly the conversation is unreadable. We’ll keep thinking about it. The easiest change I can think of is when the category setting is toggled, we have a modal popup saying “do you want to apply this to existing topics?”
/* add text to Reply button for the original post (aka Topic) */
#post_1 nav.post-controls {
.actions {
button.reply {
span.d-button-label:after {
// Adding this content after Reply
content: " to this Topic";
}
}
}
}
/* add text to Reply button for all subsequent posts (I'm calling them comments) */
nav.post-controls {
.actions {
button.reply {
span.d-button-label:after {
// Adding this content after Reply
content: " to this comment";
}
}
}
}
/* add text to blue Reply (to Topic) button appearing at the end of the page */
#topic-footer-buttons {
.topic-footer-main-buttons {
button.btn-primary.create {
span.d-button-label:after {
// Adding this content after Reply
content: " to main Topic";
}
}
}
}
If it were my community I would test in isolation first. On the other hand we would get more valueable feedback faster by you enabling for your whole community . Jokes aside, I do think testing in isolation is probably smart but there is no destructive data migrations here. It can be enabled and disabled safely. No decision you make here will lock you in either direction.
I guess I sorta accidently answered this part! Enabling nesting simply creates a nested_topic record for each topic in the DB and kicks off a job to calculate reply counts down the ancestry tree. Disabling nesting removes that nested_topic record and you’re back to flat, no issue.
Is there a reason that this is only able to be toggled by staff instead of normal users? When I had seen it was coming to Meta I figured that it would have been added to the post type menu but the toggle is hidden behind the staff wrench icon.
We don’t want this to be a user’s decision or preference. It’s up to the administers to decide how their site should function. The two paradigms are very different and users shouldn’t be interacting so differently on the same content. That’s our current thought at least.
Ad blocks do not work well in this structure, and converting topics often triggers a bug where screen items disappear, leaving only the title editable.
Nice feature! However I’m curious about the Top / New / Old sort more than the nested layout itself. I’ve shipped similar sort controls in my mobile app (a Discourse client) and would love to support this natively than my current method although it works as I’ll show below.
Looking at the source, I can see GET /n/{slug}/{topic_id}.json?sort={top|new|old}&page={n} returns the topic in nested view sorted by the chosen mode. My question: is there any appetite to expose just the sort through the existing /t/{slug}/{topic_id}.json endpoint (e.g. ?sort=top) so flat-view clients can benefit too?
If sort were available on flat view, third-party clients could opt in without adopting the nested view rendering model.
I realize the nested view’s data shape (root posts + lazy children) is what makes server-side sort tractable, and that flat view paginates differently. If a full flat-sort isn’t realistic for performance reasons, even an optional ?sort=top&limit=N would be enough to drive a “highlights” view.
. Jokes aside, I do think testing in isolation is probably smart but there is no destructive data migrations here. It can be enabled and disabled safely. No decision you make here will lock you in either direction.
