This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-25
Channels
- # announcements (5)
- # babashka (23)
- # beginners (70)
- # cider (24)
- # clj-kondo (14)
- # cljsrn (2)
- # clojars (6)
- # clojure (195)
- # clojure-australia (1)
- # clojure-dev (2)
- # clojure-europe (27)
- # clojure-france (1)
- # clojure-nl (4)
- # clojure-norway (2)
- # clojure-spec (2)
- # clojure-uk (12)
- # clojurescript (3)
- # clojurewerkz (1)
- # core-async (21)
- # cursive (9)
- # datomic (37)
- # duct (3)
- # emacs (16)
- # events (4)
- # fulcro (34)
- # graalvm (12)
- # javascript (3)
- # jobs (4)
- # malli (1)
- # meander (3)
- # nrepl (1)
- # off-topic (27)
- # pathom (16)
- # re-frame (17)
- # reagent (19)
- # rewrite-clj (18)
- # sci (47)
- # shadow-cljs (179)
- # spacemacs (18)
- # sql (52)
- # tools-deps (80)
- # vim (27)
- # vrac (1)
- # xtdb (9)
Any examples of the re-frame way to have a datatable like view of potentially large (more than you would want to cache locally) data coming from a server. The view would have options that would allow for sorting and searching which would happen on the server causing the page data in the browser to be refreshed. More interested in how to handle the fetching/paging into the re-frame app-db and how to orchestrate it all rather than the views themselves, though that would be good too. Thanks for any tips or pointers to examples!
I’ve implemented a pretty full-featured data table in my app. Unfortunately I can’t share the code but I can describe the basic principles.
First I have what I call the “model”. It contains the URL of the endpoint that can fetch me a page of data and data about how to render each column. Next is the “view state”, which contains things the user can change: sort column and order, page size, current page index, etc. Finally, there’s the “content” that comes back from the endpoint, which contains the row data for the current page and a count of the total number of rows.
I put the model in a CLJC file and the other two in app DB. I made the decision to only have one data table per page so that my data is always at a known path, which simplifies all my event handlers.
For each data table in my app I create an endpoint that accepts the view state and returns a new content structure. I just POST the view state, but you could just as well serialize the state into a query parameter and do a GET.
I pass the model to the view component. It subscribes to the view state and content and renders accordingly.
When I first display a page containing a data table, I dispatch the event that posts to my endpoint and populates the content slot on successful return.
When the user interacts with the data table, e.g. clicking a header to change the sort order or clicking to view the next page, I dispatch an event to update the view state, then re-do the call to the endpoint to refresh the content.
That’s the essence of it. You can add stuff around that, e.g. showing a spinner while data is being loaded, adding filters to your view state, etc., but it’s all just expanding on those ideas.
@U0DTSCAUU Thanks for the info. Will chew on that. We’re using graphql/aws appsync for the backend, but it sounds like the style you are describing should work similarly.
@p-himik where in GitHub are you seeing this version? Perhaps in the README, via a clojars badge?
Thanks, i created an issue. We'll fix it.