Anybody interested in helping a little with RAD? I’m interested in someone writing a database adapter for key-value stores that could then make it easy to use a variety of dbs like redis, firebase, mongodb, etc. I’m thinking something along the lines of: • The user of the lib supplies function (fn write* [ident cljc-map] …) that can store the given map (assumed to be normalized, so that refs are ident values within the map) for the provided ident, and (fn read* [ident]) that will return the map stored under that ident (with the idents for refs). They key is the ident, in other words. In redis, it already uses Nippy, and these two functions would be trivial. • The library would treat each “normalized” fulcro-state-db-style entity as a thing to store in such a store by ident. • Form middleware for save and delete would then be pretty easy. Schema enforcement based on attributes would be easy to include. • Auto-generated resolvers based on ID would also be trivial This would let us dramatically expand the back-end storage options, since new adapters would just need to supply two functions.

Ideally it would be CLJC, so it could even be used as a client-side db adapter (though we still need remote integrations to make that fully possible). Then using database-as-a-service (or browser-based dbs) APIs would be pretty easy to adopt.

I could probably knock together a basic template pretty quickly, but I don’t have the time to refine/test it.

Is there a way to modify Transit handlers used by Inspect? Transit does not support sorted colls (they are ser/de as unsorted ones), which makes Inspect unusable as soon as you use one (at least, it prevents time travel which is a big let down)

(Well of course, that would only be viable for colls sorted by default <, not user functions (eg. no sorted-map-by), but still)

In the Fulcro RAD Demo if you want to leave a new form a Cancel/OK modal dialog comes up with "You will lose unsaved changes. Are you sure?" Can anyone help me with where that messages comes from?

@tony.kay Do RAD implements "server side pagination" (fetch pages one by one)

@souenzzo not at present

What is there is that URL report parameters (control values) do get sent to the server; therefore the server can choose to respond with a subset of real data. For expanded options you would set a ::report/machine option on report and customize the UISM and add such support.

So, if you look carefully “filtering” on the report is really client-side filtering of the server result (`row-visible?`).

Therefore, you can get most of what you need on server-side pagination by adding controls that have nothing to do with client-side filtering, and send those to the server to get a subset result

For example, on my system I have things like reports on all orders. Of course I don’t want all orders ever…I want them for a date range. So, the date range defaults to “today” and I auto-run the report. If the user changes the date range, then I pull those, etc.

Limiting the span of the allowed date range makes it reasonable in most cases

You could add a “Page” control that says what page number, and let the server do sort/filter/paginate, and just send that number as a query param to say which page you want. That would not require any change to the UISM

The control’s “on change” action would change the number and re-run the report

TL; DR: You can get what you want with a custom “page” control that sets a report param, and a resolver that interprets that param. The control just runs the report when it changes.

Yeah. Our app already use pagination as a custom param.