Listoka / bittoka

4 stars 1 forks source link

Better Post Seed and MainPage Pagination #224

Closed robbyphillips closed 5 years ago

robbyphillips commented 5 years ago

The post seed script now makes a lot of posts that are, in general, much longer than we had before. There is also a chance that the random post will use codeblock and blockquote styles. This is configurable, and it might be worth adding random bits of other formatting like inline styles at a later time.

Additionally, we now have pagination on the main post list views with a 'More' button to get more posts. Unfortunately, this introduces 2 known problems:

  1. The tag filter does not have a consistent experience. Currently, clicking the more button will reset the filter list and make the query, appending the unfiltered results to the bottom of the list. A better fix might be to add a query parameter that passes the selected tags to the server, but then we would have to make another query if any of those tags are unselected.
  2. The account page currently just grabs all posts that a user has created and filters them out client side by whether a post is currently a draft or not. The better solution will be to move the ability to get draft posts to its own route and make two separate queries.

Also, pagination still needs to be implemented on the profile page.

robbyphillips commented 5 years ago

main changes:

The biggest change in this branch is upgrading the GET /api/posts route to be able to handle several filtering and sort control query parameters:

next actions:

In order to prevent duplication of work (and code), I suggest that we factor out a PostListContainer component that can be used in the 3 places that we currently display lists of posts.

All of these use cases are very similar, and with a few small tweaks, we can have a reusable post-list component that has a well-featured sorting toolbar

other notes:

Post model and API stabilized for now. In the future we should look at removing the 'voters' and 'purchasers' arrays on the model, and instead just update a count as needed when we hit other api routes.

Initial experimentation in this branch was aimed at removing all arrays of objectId from the post model, but using aggregation pipelines to count the number of transactions (calculate votes) proved to be far too expensive. If we are sorting thousands of posts with hundreds of vote transactions each, we need a faster way to built that sort query.

As such, I think we will need to maintain counters on the post model by incrementing a count field whenever we log a transaction. Currently, we do this for comments, but not for purchase or vote transactions.