This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (4)
- # asami (1)
- # babashka (48)
- # beginners (84)
- # bristol-clojurians (1)
- # calva (15)
- # chlorine-clover (11)
- # cider (37)
- # clj-kondo (17)
- # clojure (72)
- # clojure-europe (13)
- # clojure-italy (43)
- # clojure-nl (6)
- # clojure-spec (8)
- # clojure-uk (19)
- # clojuredesign-podcast (7)
- # clojurescript (132)
- # code-reviews (7)
- # conjure (3)
- # cursive (24)
- # datascript (10)
- # datomic (61)
- # docker (4)
- # duct (24)
- # emacs (2)
- # figwheel-main (8)
- # fulcro (43)
- # graalvm (5)
- # juxt (1)
- # keechma (14)
- # malli (2)
- # off-topic (120)
- # re-frame (111)
- # reagent (6)
- # reitit (13)
- # shadow-cljs (118)
- # spacemacs (3)
- # tools-deps (32)
- # uncomplicate (5)
- # xtdb (6)
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.
I would be interested in helping. Perhaps doing one of them, getting things moving along...
No I'm okay for now. Just looking for one of them that easy to setup and use w/out an internet connection.
the idea is to store them like they are stored in Fulcro, so keys are idents, and values are normalized table entries that in turn have idents that point to other things
The one thing I didn’t get right, @U0D5RN0S1, in the description above: The functions will receive the pathom
env, which in turn can have (via plugins) database specific config info, including the
key->attribute lookup map for attributes, etc.
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)
Follow the development directions for Inspect, and add it there, and then use development mode in F3 and add it there. It has to be added on both ends. If it is a general data type that everyone would use that does not add deps they would not use, then I’d even take that as a PR. I’m not sure what transit’s resolution order rules are, so you’d have to figure that out
Great, I am in a bit of a rush but I will probably have to do it one day or another, I'll keep that PR in mind
(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?
one can set it with
::form/confirm (fn [message] #?(:cljs (js/confirm message) ))
Out of curiosity, was it not working for you by default? That was happening to me (and may still be..)
(I think all forms are supposed to use js/confirm with that generic message by default, but I think I had to set it manually in my project for some reason..)
Yes, not working for me trying out a form, but it works in the RAD demo, perhaps a validator is required...
oh interesting.. didn’t see any logic connecting the two, but interesting idea to try
cc @tony.kay just for visibility -- this is what I was asking about a few days back, never figured it out 😞 Don't know why js/confirm is occasionally nil..
Its an intriguing question. And also a potential time waster for many people. Would be good to have an error message that recommends setting
i think it can be nil in non-web environments (react native, for example), but if we know we’re in a normal web browser, it’d be nice a log/warn would nice
Good point. Also seems like it is something still under development, because ideally there would be a more global 'modal confirm dialog' way that is better looking and comes from the rendering plugin.
yeah, but I think a lot of these defaults aren’t really meant to be used in a production user-facing environment — they’re convenient for internal tools, and quick experimentation, but every app is going to have its own design, style, and thats not really the concern of the framework
And in this case the global confirm dialog could be 'app styled' by making a modification at the rendering plugin. i.e. every app can have its own rendering plugin.
The problem at the moment is that confirm needs to be sync, and most things in js-land are not…it’s a problem in the design right now. That bit of code will move to return a boolean, a promise/future returning a boolean, or an async channel resulting in a boolean.
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.
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
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.