This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-02
Channels
- # aleph (6)
- # beginners (57)
- # boot (1)
- # cider (27)
- # clara (23)
- # cljs-dev (166)
- # clojure (287)
- # clojure-dev (23)
- # clojure-greece (1)
- # clojure-italy (2)
- # clojure-russia (13)
- # clojure-spec (34)
- # clojure-uk (36)
- # clojurescript (68)
- # core-async (63)
- # core-logic (1)
- # cursive (1)
- # data-science (1)
- # datomic (26)
- # duct (1)
- # emacs (10)
- # figwheel (8)
- # fulcro (2)
- # garden (16)
- # graphql (8)
- # hoplon (20)
- # jobs (2)
- # leiningen (10)
- # off-topic (16)
- # onyx (2)
- # portkey (5)
- # quil (1)
- # re-frame (63)
- # reagent (95)
- # reitit (6)
- # remote-jobs (1)
- # ring (6)
- # rum (1)
- # shadow-cljs (76)
- # spacemacs (26)
- # specter (11)
- # sql (7)
- # unrepl (68)
- # vim (2)
- # yada (2)
I found there ar reagent-modals and modal-panel, can the capability of them be found from re-com, so that use re-com is suffice, and on need to use them?
for re-com, it needs the following file <link rel="stylesheet" href="assets/css/material-design-iconic-font.min.css">.
@caleb.macdonaldblack that's interesting!
@gadfly361 Im currently experimenting with functions instead of interceptors. While keeping the decision tree like story in the event definition
Ill let you know
for modal in re-com, why not accept params for modal-header,modal-body,modal-foot, looks like these 3 parts are usually used together
@danielcompton you asked, many moons ago, for anyone to share their experience with graphql
i've finally finished my article on our journey: https://juxt.pro/blog/posts/through-the-looking-graph.html
Thanks!!!
When I'm working with atoms I use add-watch
to determine when atom is changed so I can enable/disable form buttons.
I want to move my form from atom to re-frame db, but I can't find a way to react to db changes.
That’s what the subscriptions are for
When your form component subscribes to a re-frame subscription, it will re-render every time that value changes
The watcher is built-in
Let me use a login form as an example. 2 fields, email and password, in the app-db as :email
and :password
(oversimplifying, but you get the idea)
So you make a subscription for email-sub
and a subscription for password-sub
that returns the value currently entered
but you also make a 3rd sub for button-enabled-sub
So the trick is that button-enabled-sub
can itself subscribe to email-sub
and password-sub
Then, in the body of button-enabled-sub
, you can return true
if email and password are both filled in, and false
if either is empty
Actually, let me back that up, you call it button-disabled-sub
and return true when either is blank
That’s ok, the same principle works on bigger forms
With the watches you can just say (add-watch your-state :change (fn [_ _ _ _] (reset! button-enabled true))
It’s the same idea in re-frame, except you don’t have to use add-watch
— the button-disabled-sub
function takes the same inputs as your change function, and returns true or false depending if the button should be enabled
You can feed in as many or as few inputs as you need
Moreover - sometimes your form is already filled with data and you want to detect changes rather than fields being empty.
Ok, but understand, re-frame is doing the add-watch
for you, behind the scenes
ok, but what are you doing inside your change function? You’re still checking individual fields and deciding whether or not to disable Save, right?
Or you just want to enable Save as soon as any change happens, hmm
Nope. The function is fired whenever anything
in your atom changes. You don't need to check all the fields.
Here’s another trick: because of how immutable objects work in CLJS, you can put all your fields in a nested map, like this (def app-db {:form1 {:f1 :f2 :f3 ,,, :fn}})
Anything that subscribes to :form
will re-render whenever any of the keys under :form
change
Add one more key under :form
, for :save-disabled
, set to true by default
Hmm, hang on, I’m taking myself down a path maybe I shouldn’t go…
I was about to suggest firing an event from a subscription, but that’s a very bad idea
If it worked, it would be fairly trivial to create infinite loops, so might be nice if it didn’t work.
Anyway, if you’re converting to re-frame, each one of those fields should be firing an event to update the db every time the value of the field changes.
I’d do 2 things: try and write a generic event handler that would take the field key and the new field value, and update it as usual
then (2) have that event handler also trigger an event to change the save-disabled
value to false.
If you use reg-event-fx
you can easily make an event handler that triggers other events as needed.
Then of course you make your Save button subscribe to the [:form :save-disabled]
key, and add the disabled
attribute to the button if the subscription evaluates to true
@achikin @manutter51 it sounds to me like if something changes about the db, you are doing that in an event handler, so that would be where you also set the “disabled” sort of db flag
If you want to do some sort of “global” (across all handler changes) work, you probably could use an intercepter on all the relevant event handlers
Yeah, actually I guess that is basically the same thing @manutter51 just said. My only contribution is then “perhaps an intercepter would help”