Forum Discussion Platform

A forum is not just a list of comments under a post. Real discussions often contain replies to replies, collapsed branches, highlighted answers, moderation states, and unread activity inside specific branches. A common mistake is saving every reply in one flat array and only sorting it by creation date. This makes the first version easier, but it becomes painful when you need nested threads, reply targeting, moderation actions, and deep links to a specific comment.

Problematic approach:

          export interface Reply {
            id: string;
            threadId: string;
            authorId: string;
            body: string;
            createdAt: string;
          }

          replies: Reply[] = [];

          getThreadReplies(threadId: string): Reply[] {
            return this.replies
              .filter((reply) => reply.threadId === threadId)
              .sort((a, b) => a.createdAt.localeCompare(b.createdAt));
          }

This structure does not know which reply belongs to which parent. The UI can show a chronological conversation, but it cannot represent real threaded discussion behavior.

Better approach:

          export interface ForumReply {
            id: string;
            threadId: string;
            parentId: string | null;
            authorId: string;
            body: string;
            score: number;
            status: "visible" | "hidden" | "deleted";
            createdAt: string;
            updatedAt: string;
          }

          export interface ReplyNode extends ForumReply {
            children: ReplyNode[];
          }

          function buildReplyTree(replies: ForumReply[]): ReplyNode[] {
            const nodesById = new Map<string, ReplyNode>();
            const roots: ReplyNode[] = [];

            replies.forEach((reply) => {
              nodesById.set(reply.id, {
                ...reply,
                children: []
              });
            });

            nodesById.forEach((node) => {
              if (!node.parentId) {
                roots.push(node);
                return;
              }

              const parent = nodesById.get(node.parentId);

              if (parent) {
                parent.children.push(node);
              }
            });

            return roots;
          }

Pay attention to: Store parentId explicitly. This gives you nested replies, branch-level moderation, comment permalinks, collapsible sections, and better control over how conversations are displayed.

Recursive reply components are natural for forum interfaces, but they can become expensive when threads grow. If every branch renders fully, a popular thread with hundreds of replies can become slow. Another mistake is forgetting trackBy, which forces Angular to recreate DOM elements unnecessarily after voting, editing, or loading new replies.

Problematic template:

          <app-reply
            *ngFor="let reply of replies"
            [reply]="reply"
          ></app-reply>

Problematic recursive component:

          <article class="reply">
            <p>{{ reply.body }}</p>

            <app-reply
              *ngFor="let child of reply.children"
              [reply]="child"
            ></app-reply>
          </article>

This version renders everything immediately. There is also no clear limit, no collapsed state, and no optimized identity tracking.

Better approach:

          trackReplyById(index: number, reply: ReplyNode): string {
            return reply.id;
          }

Improved template:

          <app-reply
            *ngFor="let reply of replies; trackBy: trackReplyById"
            [reply]="reply"
            [depth]="0"
          ></app-reply>

Safer recursive reply component:

          <article class="reply" [class.reply--nested]="depth > 0">
            <header>
              <strong>{{ reply.authorName }}</strong>
              <span>{{ reply.createdAt | date: "short" }}</span>
            </header>

            <p>{{ reply.body }}</p>

            <button
              type="button"
              *ngIf="reply.children.length"
              (click)="isExpanded = !isExpanded"
            >
              {{ isExpanded ? "Hide replies" : "Show replies" }}
            </button>

            <section *ngIf="isExpanded">
              <app-reply
                *ngFor="let child of reply.children; trackBy: trackReplyById"
                [reply]="child"
                [depth]="depth + 1"
              ></app-reply>
            </section>
          </article>

Pay attention to: Large forum threads need controlled rendering. Use trackBy, collapsed branches, pagination or lazy loading for long reply chains, and OnPush change detection where appropriate.

Voting looks simple: click upvote, increase the score. But a forum voting system needs rules. A user should not upvote the same post ten times, switching from upvote to downvote should adjust the score correctly, and failed requests should not leave the UI in a fake state. A weak implementation often changes only the visible number.

Problematic code:

          upvote(reply: ForumReply): void {
            reply.score += 1;
          }

          downvote(reply: ForumReply): void {
            reply.score -= 1;
          }

This does not store the current user's vote. It also bypasses backend validation and cannot recover if the request fails.

Better model:

          export interface VoteState {
            targetId: string;
            targetType: "thread" | "reply";
            userVote: 1 | -1 | 0;
            score: number;
            isSaving: boolean;
          }

Better Angular service logic:

          voteOnReply(replyId: string, nextVote: 1 | -1 | 0): Observable<VoteState> {
            return this.http.post<VoteState>(`/api/replies/${replyId}/vote`, {
              vote: nextVote
            });
          }

Component-side optimistic update with rollback:

          updateVote(reply: ForumReply, nextVote: 1 | -1 | 0): void {
            const previousVote = reply.userVote;
            const previousScore = reply.score;

            reply.score = calculateNextScore({
              currentScore: reply.score,
              previousVote,
              nextVote
            });

            reply.userVote = nextVote;
            reply.isVoteSaving = true;

            this.forumService.voteOnReply(reply.id, nextVote).subscribe({
              next: (savedVote) => {
                reply.score = savedVote.score;
                reply.userVote = savedVote.userVote;
                reply.isVoteSaving = false;
              },
              error: () => {
                reply.score = previousScore;
                reply.userVote = previousVote;
                reply.isVoteSaving = false;
                this.snackBar.open("Vote was not saved. Try again.", "Close");
              }
            });
          }

Pay attention to: Voting should be treated as user-specific state, not just a number. Track the current user's vote, disable repeated clicks while saving, validate votes on the backend, and handle rollback clearly.

Role-based access control is one of the core parts of a forum platform. A frequent mistake is hiding moderator buttons with *ngIf and assuming that the feature is protected. This only changes the interface. It does not protect routes, API calls, or direct requests from someone who manually triggers the moderation endpoint.

Problematic template-only protection:

          <button
            *ngIf="currentUser.role === 'moderator'"
            mat-button
            color="warn"
            (click)="deleteThread(thread.id)"
          >
            Delete thread
          </button>

This improves the UI, but it is not real security. A regular user could still try to call the delete endpoint if the backend does not enforce permissions.

Better route guard:

          export const moderatorGuard: CanActivateFn = () => {
            const authService = inject(AuthService);
            const router = inject(Router);

            return authService.currentUser$.pipe(
              map((user) => {
                if (user?.roles.includes("moderator")) {
                  return true;
                }

                return router.createUrlTree(["/forbidden"]);
              })
            );
          };

Route configuration:

          {
            path: "moderation/reports",
            component: ReportsQueueComponent,
            canActivate: [moderatorGuard]
          }

Backend-side requirement:

          DELETE /api/threads/:threadId

          Required permission:
          moderator:threads:delete

Pay attention to: UI visibility is only the first layer. Protect moderator pages with guards, protect API calls on the backend, and keep permission names explicit enough to distinguish locking, hiding, deleting, restoring, and reviewing reports.

Forum notifications are usually reactive: new replies, mentions, vote milestones, report updates, or moderator decisions. In Angular, it is easy to subscribe to streams in a component and forget to unsubscribe when the user leaves the page. After several route changes, the same notification may appear multiple times because old subscriptions are still alive.

Problematic code:

          export class ThreadComponent implements OnInit {
            notifications: ForumNotification[] = [];

            ngOnInit(): void {
              this.notificationService.notifications$.subscribe((notification) => {
                this.notifications.unshift(notification);
              });
            }
          }

This subscription has no cleanup. If the component is destroyed and created again, another subscription is added.

Better approach with async pipe:

          export class HeaderNotificationsComponent {
            notifications$ = this.notificationService.notifications$;

            constructor(private notificationService: NotificationService) {}
          }

Template:

          <button mat-icon-button [matBadge]="(unreadCount$ | async) || 0">
            <mat-icon>notifications</mat-icon>
          </button>

          <mat-nav-list>
            <a
              mat-list-item
              *ngFor="let notification of notifications$ | async"
              [routerLink]="notification.link"
            >
              {{ notification.message }}
            </a>
          </mat-nav-list>

Alternative cleanup with destroy signal:

          private destroy$ = new Subject<void>();

          ngOnInit(): void {
            this.threadUpdates$
              .pipe(takeUntil(this.destroy$))
              .subscribe((update) => {
                this.applyThreadUpdate(update);
              });
          }

          ngOnDestroy(): void {
            this.destroy$.next();
            this.destroy$.complete();
          }

Pay attention to: Prefer async pipe for UI streams. When manual subscriptions are necessary, clean them up. Forum platforms have many long-lived streams, so subscription discipline matters.