저는 discourse에서 뉴스/정치 토론 포럼을 운영 중입니다. 현재 겪고 있는 문제는 discourse의 기본 정렬 방식이 제 사용 사례에서 완전히 혼란을 야기한다는 점인데, 이는 주제(topic)의 경과 시간이 매우 중요하기 때문입니다. 제 포럼과 같은 경우 Reddit 스타일 정렬이 가장 적합하지만, 이를 달성하는 직접적인 방법이 없다는 것이 제 이해입니다.
Reddit 정렬을 구현하기 위해 bumped_at을 (남용)할 수 있는지 궁금합니다. 예를 들어 다음과 같은 방식으로요:
def topic_hotness(created_at, like_count)
/**
이 함수는 created_at과 like_count를
Reddit에서 사용되는 것과 유사한 수학적 공식을 사용하여
bumped_at 날짜로 변환합니다. bumped_at은
주제의 생성 날짜와 좋아요 수를 고려할 때
상위 10개에 머물러야 하는 시점까지의
날짜로 간주합니다.
*/
end
add_model_callback(Topic, :before_save) do
self.bumped_at = topic_hotness(self.created_at, self.like_count)
end
이것이 작동할까요? 그리고 어떤 기능이 깨질 수 있으며, 이를 어떻게 해결해야 할까요? discourse 코드베이스 어딘가에서 bumped_at이 미래 날짜인 경우 예외가 발생한다는 것을 보았습니다. 공식에 따라 이 방식을 사용하면 bumped_at이 미래 날짜가 될 수 있습니다. 어떤 생각이 있으신가요?
불행히도 현재 discourse의 품질과 비교할 만한 것은 아무것도 없기 때문에 discourse가 제 유일한 선택지입니다. 사실 discourse는 해당 사용 사례에 필요한 거의 모든 기능을 갖추고 있으며, 다만 홈페이지 정렬 기능이 빠져 있을 뿐입니다. 과거에도 비슷한 질문을 몇 번 보았으니, 이 글이 앞으로 더 많은 분들에게 도움이 되기를 바랍니다.
하하. 내 커뮤니티에서 아주 좋은 반응을 얻고 있어서 그렇게 말할 수 있는 거예요. 밖에 나와 있는 레딧 클론들은 시도해 볼 가치조차 없어요.
Solved 플러그인이 이 문제와 어떻게 관련이 있는지 잘 이해가 되지 않습니다. bumped_at(최종 업데이트 시각)을 조작하는 건가요?
이 방식에도 자체적인 문제가 있습니다. 사용자의 참여를 유지하려면 타임라인이 무한 스크롤이어야 합니다. 제 사용자 대부분은 카테고리로 내비게이션하는 것보다 이탈해 버립니다.
다음으로, devo에서 bumped_at을 오버라이드했을 때 어떤 문제가 발생할지 실험해 보고, 그 문제들을 트레이드오프로 받아들일 수 있는지 확인해 볼 생각입니다. 아직 코드를 살펴보지는 않았지만, 마지막 방문 마커가 혼란스러워질 것 같아서 이를 억제해야 할 것 같습니다. 또한 “새 주제 또는 업데이트된 주제” 표시도 엉망이 될 것 같으니, 이것도 오버라이드하거나 억제해야 할 수 있습니다.
다른 분들도 관심이 있을 수 있으니, 이 스레드에서 제 경험을 공유하겠습니다. 여러분이 바로 떠올릴 수 있는 다른 문제가 있는지 알려 주세요.
