@tony.kay @wilkerlucio say I want to use pagination in comments of blog post as we discussed yesterday. Assume the subquery params problem has been resolved, I still can't think of anyway to compose queries from Comments to Paginated Comment List up to Blog component

the Pagination pattern works well for top level lists, but I can't find an obvious way for nested lists like Comments

@myguidingstar just from the top of my head, what I would do is something like GraphQL does, have some context around the paginated resource (another component), which tracks the page status (next page, all items, current page...), but never tried, seems an interesting experiment

the problem is Blog and Comment have their place in both client db and server while Pagination is only client side. That's why I find composing queries for them cumbersome

you can re-structure your server as well

instead of having just {:post/comments [:comment/id :comment/text ...]}, make something more structured, like:

{:post/paginated-comments [:page/next-page-token :page/total-items :page/current-page {:page/items [:comment/id :comment/text ...]}]

@myguidingstar it could be you’re relying on parameters in queries more than I would. I tend to use state for pagination, not queries.

@tony.kay I don't get it. Can you give a little more details?

Like the pagination example in the book

use :ui/page and such as attributes on the UI component, and write mutations that manage the pages.

I just think it would be great if Fulcro support pagination first class 😄

so app developers don't have to care too much about the details

@myguidingstar There are so many ways of doing pagination and caching. It doesn’t really make sense to put it in the main library I don’t think…it is already pushing it in some areas. An add-on library would be nice, though, for some common ways of doing it 🙂

I mean, one way of “doing it” is just to load “all”, and then paginate in the UI component itself with sort, drop, and take.

another is to do a sliding window of storage on the client (for large lists)

another is the “show what I have so far, and load more when I get to the bottom of scrolling”

etc etc

pagination could easily be a library the size of Fulcro

😄

I can recommend the approach from the book we use that too and it has served us well. If you use nice idents per :ui/page then you can also do easy caching

@mitchelkuijpers is your paginated list living in top level of app state (like Blog) or nested (like Comment)?

We have both

We create an ident like this:

(fn [] [:page/by-pagination {:page/start start
                                       :page/size size
                                       :page/type type}])

It doesn't really matter if it's nested for us you could just add an extra thing such as comment-page/by-pagination which also includes the blog-id

yeah, I make such "combo" idents as well. And I use defrecord for better performance and to avoid error

but I don't like the way a lot of mutations around load

Why not? it's just some simple state

It's is really testable and boring which is perfect in my opinion

okay, I'll look at it later. Thanks for sharing it

I wouldn't fiddle with subqueries to be honest

This is the guide btw @myguidingstar http://book.fulcrologic.com/#_paginating_large_lists

oh?

I did read that 😉

Oh now I get the subqueries, I just read some older comments. I thought you were talking about dynamic queries. So don't listen to me on that part

@mitchelkuijpers shouldn’t the load in there be using load-action instead, since it’s called from within a mutation?