Customizing misago

stevejeon
Jan. 22, 2018
chat_bubble_outline 2
  • link
    Members 5 posts
    Jan. 22, 2018, 3:31 a.m.
    link

    Wow! I must admit this project looks fantastic. Good job @rafalp ! Two thumbs up.

    As a django developer, I've been planning to create a domain-specific forum for users with a friend of mine, who can handle frontend jobs with react. We decided to use your project as basis for development, and it could help us a lot.

    The problem is though, we need a little customization.

    Requirements:
    1. Tags on posts
    2. Customize user ranking algorithm a little bit, which I presume, should not be that difficult
    3. Add trending or recommended reads category, to filter quality posts, possibly with numbers of likes with consideration for time since post_created. Reference material from reddit ranking algorithm
    4. Use websocket to send push notifications
    5. Use jsonwebtoken
    6. Custom dashboard for users, with some graphs and charts
    7. Not eminent, but possibly in the future, support react native to build mobile apps

    Questions:
    1. After reading your post on future plans for frontend rewrite for SPA support, plus some nice features such as activity feeds, we could not decide how to use the project. pip install the package to get the most out of future releases, but with difficulty customizing vs fork the repo and customize locally, but without supports from future releases. Which do you recommend? I never customized 3rd party library with the first method, so I'm not really sure if it will be difficult to reuse and override misago to customize this way.
    2. Since I do backend API server work mostly, I'm used to working REST framework. Since you set the goal to migrate project to be a SPA framework, possibly after a complete frontend rewrite, any future plans to use restframework more thoroughly for backend apis? This could mean completely separating front and back, for example removing templates from django to focus more on backend api endpoints for frontend.
    3. I'm trying to go thorough all of the codes line by line, before using the framework(I plan to spend some time on it) but somethings are difficult to pick up. Could you briefly explain to me, in which order I should read the code to better understand the core of projects? Please bear in mind, I'm not that used to using templates and so on to build a fully-functioning websites with django. I normally only do the API work, and leave the rest to frontend engineer for html, css, javascript.

    Thanks!

  • link
    Project Lead
    Jan. 22, 2018, 11:04 a.m.
    link

    Thanks for questions!

    1. Despite our json api staying mostly the same, Frontend rewrite is great undertaking that will likely take many months to deliver, so I would fork off the 0.14.x branch. There's also the 0.15.x branch but it's still incomplete, and I wouldn't worry about it much, as changes introduced by it wont be that big. Master is where the frontend's rewrite backend work lives, and I wouldn't really use it until release is drafted from it eventually.

    2. Misago is not SPA framework, and never will be. Its also not library - its complete solution/application. This sounds like dicussing semantics, but pointing this out felt important to me 😉. Django templates serve important purpose - they provide backend-rendered fallback for clients that don't support JS to still be able to consume site's content. Bulk of them will remain after new frontend launches, but they all will see great reduction and simplification of their contents. Currently our html templates overlap greatly with react components. That way we can render Django's template in backend, send it to client, and then in tiny bit of time later react.js kicks in and swaps parts of page for its own components. This approach looked like good idea when I was starting (its sometimes called hybrid approach and is also what twitter uses), but in long run it turns out being confusing to those seeking to customize how Misago looks as well as costful to maintain. Here's old template for threads list. It relies on inclusion of some additional, complex templates like this one. And here's new one. It renders greatly simplified threads list.

    3. With projects of this scope you'll end with large codebase. There's no way about it than exploring it yourself. I know this reads like an excuse, but its really not. Good way about it would be navigating to selecting page, then looking up in the urls.py which view serves this page, then reading it's code to see how it checks permissions, where the data comes from, what steps are being taken before passing it to template, what other services and utils are being used, etc ect. At least this is the approach I'm using when learning new codebases.

    If anything, there's always this forum for you to ask questions and get answers.

  • link
    Members 5 posts
    Jan. 30, 2018, 3:41 a.m.
    link

    Thanks for the reply. Well noted.

    I shall explore the code according to your recommendatations. :)