Fork me on GitHub
#re-frame
<
2018-03-02
>
wqhhust04:03:32

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?

wqhhust06:03:26

for re-com, it needs the following file <link rel="stylesheet" href="assets/css/material-design-iconic-font.min.css">.

wqhhust06:03:37

But where should I put the file in source code?

caleb.macdonaldblack07:03:29

@gadfly361 Im currently experimenting with functions instead of interceptors. While keeping the decision tree like story in the event definition

gadfly36107:03:55

Sweet, looking forward to how that turns out

wqhhust09:03:57

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

oliy14:03:04

@danielcompton you asked, many moons ago, for anyone to share their experience with graphql

oliy14:03:23

i've finally finished my article on our journey: https://juxt.pro/blog/posts/through-the-looking-graph.html

oliy14:03:58

let me know if you want to know any more

achikin17:03:41

Can I have some kind of watches over re-frame db?

achikin17:03:51

When I'm working with atoms I use add-watch to determine when atom is changed so I can enable/disable form buttons.

achikin17:03:45

I want to move my form from atom to re-frame db, but I can't find a way to react to db changes.

manutter5117:03:10

That’s what the subscriptions are for

manutter5117:03:00

When your form component subscribes to a re-frame subscription, it will re-render every time that value changes

manutter5117:03:12

The watcher is built-in

achikin17:03:34

But how can I change something in the response to subscription change?

achikin17:03:56

Say my data is changed and I want to enable "Save" button

manutter5117:03:51

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)

manutter5117:03:38

So you make a subscription for email-sub and a subscription for password-sub that returns the value currently entered

achikin17:03:53

Yes, that's what I do usually.

manutter5117:03:55

but you also make a 3rd sub for button-enabled-sub

manutter5117:03:25

So the trick is that button-enabled-sub can itself subscribe to email-sub and password-sub

manutter5117:03:01

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

achikin17:03:20

I have really, really huge forms.

manutter5117:03:43

Actually, let me back that up, you call it button-disabled-sub and return true when either is blank

manutter5117:03:53

That’s ok, the same principle works on bigger forms

achikin17:03:12

With the watches you can just say (add-watch your-state :change (fn [_ _ _ _] (reset! button-enabled true))

achikin17:03:25

And it'll change whenever anything changes in your data

achikin17:03:19

You don't need to check all the forms components, subcomponents and the rest.

manutter5117:03:21

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

manutter5117:03:47

You can feed in as many or as few inputs as you need

achikin17:03:56

Moreover - sometimes your form is already filled with data and you want to detect changes rather than fields being empty.

manutter5117:03:43

Ok, but understand, re-frame is doing the add-watch for you, behind the scenes

achikin17:03:47

But in this case I should subscribe to all my fields...

manutter5117:03:46

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?

manutter5117:03:19

Or you just want to enable Save as soon as any change happens, hmm

achikin17:03:06

Nope. The function is fired whenever anything in your atom changes. You don't need to check all the fields.

manutter5117:03:40

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}})

achikin17:03:43

Yes, this way.

manutter5117:03:22

Anything that subscribes to :form will re-render whenever any of the keys under :form change

achikin17:03:39

Yes, true.

achikin17:03:19

But how can I use that to toggle save button state?

manutter5117:03:49

Add one more key under :form, for :save-disabled, set to true by default

manutter5117:03:13

Hmm, hang on, I’m taking myself down a path maybe I shouldn’t go…

manutter5117:03:43

I was about to suggest firing an event from a subscription, but that’s a very bad idea

achikin17:03:03

I doubt its even possible

manutter5117:03:39

If it worked, it would be fairly trivial to create infinite loops, so might be nice if it didn’t work.

manutter5117:03:15

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.

manutter5117:03:34

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

manutter5117:03:05

then (2) have that event handler also trigger an event to change the save-disabled value to false.

manutter5117:03:38

If you use reg-event-fx you can easily make an event handler that triggers other events as needed.

manutter5117:03:34

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

mikerod18:03:13

@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

mikerod18:03:23

that, in turn, your subscription looked at for render to respond to

mikerod18:03:48

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

mikerod18:03:40

Yeah, actually I guess that is basically the same thing @manutter51 just said. My only contribution is then “perhaps an intercepter would help”

achikin19:03:37

Interseptor sounds like a good solution, thank you.

mikerod21:03:59

I’ve been reading about these new react 16 features today. Seems all pretty complex to me

mikerod21:03:29

I’m wondering how these sorts of react design choices will play out from re-frame/reagent’s perspective. Also, I wonder how hard it’ll be to interop with the react components of the future