Fork me on GitHub
#re-frame
<
2017-07-11
>
stuartrexking01:07:07

@mikethompson Can you give me some direction? ^

stuartrexking01:07:56

Yes, although I could write my own interceptor.

mikethompson01:07:56

So the way we use enrich is to add an interceptor to EVERY state changing event handler

mikethompson01:07:20

and in that interceptor we recompute completely the current warnings or errors ...

mikethompson01:07:47

.... placing that "state" (warnings and errors) into app-db

mikethompson01:07:33

And we do this as an alternative to "incrementally" calculating how the latest event changed the warnings and error state

mikethompson01:07:21

So ... no incrementalism ... we do a full re-compute all all errors andwarnigns each time. Because it is so much simplier to do it that way

mikethompson01:07:29

(At the cost of inefficiency)

mikethompson01:07:17

So ... strategy is that we put the re-computation into EVERY event handlers which might make a change which changes the current warnigns and errors being displayed

stuartrexking01:07:59

Which is fine, but (for example) if your handler adds :http-xhrio to the effect map, before the validation is run, how do avoid submitting to the server. I feel like I’m missing a step somewhere.

mikethompson01:07:30

Okay, you are adding a step which we don't have ... a submit In our apps, we're not submitting. We're just reporting current warnings and errors

mikethompson01:07:34

So ... in your case ....

stuartrexking01:07:57

I’m know I’m about to experience some enlightened moment.

mikethompson01:07:01

No before happens before the event handlers is run

mikethompson01:07:22

Sounds like you have a form-ish situation. Data entry, then hit the submit button.

stuartrexking01:07:47

Yes, without a form element, but yes.

mikethompson01:07:44

So the enlightenment is simply that when i was describing our use of enrich, the usecase was not form-ish

stuartrexking01:07:46

Ok, so if you are not using a form-ish flow, how so you manage state synchronization with a server? What occurs in the flow to say, save this state somewhere?

mikethompson01:07:22

Yeah, so that's the point, we're not talking to the server

mikethompson01:07:34

We have very rich SPA which seldom talk to servers

stuartrexking01:07:59

So, in my case, where would you do the validation?

mikethompson01:07:52

So, I'm assuming you have: 1. checking/validation to do after every bit of data entry (dispatched) 2. checking/validation to do when the user presses the "Send to Server" button ?

mikethompson01:07:08

And the checking/validation part is the same for 1 and 2

mikethompson01:07:00

For us, the warnings and validation involves interplay between various on-screen widgets. But I'm guessing that's not the case for you? I'm guessing you just want to be sure they have entered all mandatory values, etc.

mikethompson01:07:20

And that the emails are in the correct form?

mikethompson01:07:34

I'm just trying to get clear on your usecase

stuartrexking01:07:28

I’m building a react-native app using re-frame. User enters an email address and clicks Next, then enters a password and clicks Next. I want to validate in a few different places.

mikethompson01:07:46

But each time you are validating just one item

stuartrexking01:07:50

I could do it in the handler, or in a before, but in your various mentions on enrich online you say to validate after the handler.

stuartrexking01:07:29

I want to make sure I’m using the different re-frame steps correctly.

mikethompson01:07:42

Yeah, so my mentions are because we have a complicated desktop application with many widgets and as the user interacts with nay one of them, the error/warning state of the entire app changes.

mikethompson01:07:41

We don't try to incrementally figure out what any one interaction means, we just recompute the entire warning/state

mikethompson01:07:50

So ... back to your issue ...

mikethompson01:07:17

... after all this ... i think you should just be doing the error detection in your event handlers

mikethompson01:07:32

Sorry to have taken so long to cycle back to that point

mikethompson01:07:53

You are effectively checking on thing at a time

mikethompson01:07:02

Is the email correctly formated?

mikethompson01:07:46

enrich is really just a way of post-processing the current state (in our case, for warnings) ... so it is just a way of factoring out some post processing which is shared across multiple event handlers. But that is not your usecase. You have different error checking after each event handler

stuartrexking01:07:58

after? Don’t you mean within the handler or before?

mikethompson01:07:42

In our case we use enrich to do it :after. In your case, within (but at the end)?

mikethompson01:07:21

I do hope I'm helping here

stuartrexking01:07:35

Haha. Somewhat. I really appreciate the effort and time though.

stuartrexking01:07:21

Do you know of a good open source re-frame app that demonstrates some or all of this? Not something simple but a little more complex. There are quite a few moving pieces in re-frame and knowing which piece or step should be responsible for what is difficult for a newbie.

stuartrexking01:07:45

Something closer to my use case than yours.

mikethompson01:07:38

Perhaps have a look through the Resources list?

stuartrexking01:07:55

Of course. Thanks.

stuartrexking01:07:03

Thanks again for taking the time.

mbertheau17:07:37

I'm using re-frame 0.9.4 and when an event is handled that doesn't change the app-db, the subscriptions that depend on app-db directly fire nonetheless. Anyone else have this too?

mbertheau17:07:26

An when an actual change happens, some subscriptions fire twice - am I somehow circumventing deduplication?

eoliphant20:07:40

Hi, I’m not even sure if this is the best place to ask this lol, but basically have been working through stuff with Datomic on the server, and reagent/re-frame. And I’m getting to where everything seems to be pretty elegant and work together well, but my REST interfaces (or perhaps the way I’m doing them) just feels clunky compared to everything else. Was just curious to know what people are using. I just saw Walmart’s Lacinia (GraphQL in clojure) which looks interesting

bradleesand20:07:02

I've been using jsonapi

eoliphant20:07:20

ah ive seen that around. it’s like HATEOAS, etc support right? I’ll check it out

bradleesand20:07:32

I'm not familiar with HATEOAS but a quick googling tells me "maybe" lol

eoliphant20:07:19

yeah i just looked at the jsonapi spec, seems to be a bit of formalism, etc around doing it consistently, etc

eoliphant20:07:42

i like the GraphQL approach of letting the client ask for what it wants in the shape that it wants it

eoliphant20:07:48

but that also looks like work lol

bradleesand20:07:52

yeah it's really just a spec around using JSON payload for REST

bradleesand20:07:25

I like the idea of GraphQL but I don't like that you have to specify all fields that you want

eoliphant20:07:33

yeah i’ve historically done a lot of Java, etc. There’s a Spring HATEOAS lib, that helps you build stuff like what’s in jsonapi

bradleesand20:07:37

so you can't just ask for an object with all attributes

eoliphant20:07:37

any clojure libs for it?

eoliphant20:07:16

GraphQL might be better with a ‘’ option or ‘’-… as well

bradleesand20:07:25

I'm not using any clojure lib for jsonapi

bradleesand20:07:33

idk if there is one

eoliphant20:07:37

ok those were supposed to be asterisks lol

eoliphant20:07:03

ok but yeah i’ll check it out thanks!

mikethompson23:07:11

@mbertheau 1. First point (not answering your question yet) be sure to layer your subscriptions so the Layer 1 subscriptions are trivial "accessor" kind. They don't do any computation. https://github.com/Day8/re-frame/blob/master/docs/SubscriptionInfographic.md 2. Now, answering your question: any update to app-db will trigger Layer 1 subscriptions. Even if the db is identical? to last time. If it is important to stop this, then use an -fx kind of event handler and don't return a :db effect (then the app-db will not be updated at all)

mikethompson23:07:01

Ie. a use reg-event-fx kinda event handler and, in that handler, don't return a :db key when you want no change.

mikethompson23:07:49

But, now, I'm thinking about this a bit more, re-frame should really detect this, and help out

souenzzo23:07:13

(reg-sub :my-expensive-sub (fn [db [_ params]] (if-let [result (:result db)] result (dispatch [:event-expensive-work params])))) ^ It is possible?

souenzzo23:07:44

(reg-sub :my-expensive-sub
   (fn [db [_ params]] 
       (if-let [result (:result db)]
        result 
        (dispatch [:event-expensive-work params]))))

souenzzo23:07:25

(sure. I will need a evento to re-calculate)

mikethompson23:07:36

No, you should never dispatch in a subscription handler