Made some changes https://github.com/CalebMacdonaldBlack/re-frame-interceptors-demo/blob/master/src/cljs/demo/events.cljs

I'm falling in love with re-frame, it's beautiful and clean.. but I have a problem about dispatching syncronusly consider this code

How do I tell re-frame to dispatch ::validate-token-id first before ::post-exam-token?? Thanks, appreciate the answers

it already does what you want

hmmm, weird.. 😕

got it,

the error was callback function

Hi, I have a quick question. I’m using reframe with a generic forms app. I have events and subs that set and grab form data [:(get/set)-form-data field-id value] etc I’m adding support for calculated fields. so far it’s been pretty straight forward. In my reagent component, I have a mini language for the calculations [:func [:field-id1 …]] that creates subs for each referenced fields and applies the :func. This works perfecty. so say, my def for :field3 includes the calc def [:add [:field1 :field2]] The problem that I’m having is that i actually want to set the computed value of :field3 into the db. some how fire the [:set-form-data ..] event when the subscriptions return new values.

@eoliphant I’ve had similar situations come up before. I struggle to find an elegant solution that that problem. I guess I’d describe it as: It seems valuable and natural to derive some derived data from subscriptions for rendering “on demand” and cached etc. However, there are times when that derived data is something you want to have access to for other “event-side” purposes.

I tend to just think it’s a bad situation I got into and try to figure out if I can work it in on the event side instead. aka, when an event handler gets whatever base data, it derives the value and puts it in the db

Then on the subscription side, it no longer derives anything, it just uses the db value

yeah, for me, the issue is that, in some cases, i need my calculated field a, to depend of the value of a nother calculated field. So i need the actual value in the db.

ok ugh lol

that’s kind of the path i was starting to go down

i know that what I was asking

is kind of ‘unclean’

The problem I often encounter with “moving things to the event handling side” is that there isn’t really a “signal graph” there. I get into situations (I’ve found) where I have different handlers needing to update things in a way where they keep each other consistent. (different events that may affect various data points that are used in these derived values)

yeah

Another possible thing you can do is have the derivation functionality be just a function. Use it in the subscription, and also use it during event handling (with appropriate inputs supplied). I still think that gets clunky and then also loses some of the caching value from subscriptions

You can also explore “injecting subscription” values in your event handlers

Such as what is provided in https://github.com/vimsical/re-frame-utils#inject

I have mixed feelings about if this is something re-framers would consider an anti-pattern though. It has some oddities at least

For better of for worse, I’ve used event handler subs injections with this lib though. I just try to keep my usages to a minimum

This is discussed more in https://github.com/Day8/re-frame/issues/255 if you are interested

yeah i mean in general it’s a valid requirement. but it can kind of mess with the ideal flow, and in a degenerate case, create like an infinite event loop

I often struggle trying to do derived sorts of things in the event handlers

and the main reason is the “signal graph” idea

I end up needing to be sure that multiple handlers do things like “clear derived data” that others may have made

Because they invalidated some data that led to that derived data

On the subscription side, this is really nice an elegant

On the event handling side, I feel it is just ad hoc and brittle. I may just be Doing It Wrong ™

So I’d be curious if you run into a similar concern

yeah

i’ll give a few of these a shit

shot

lol

I may not be able to accurately explain the situation either hah. I relate to what you are trying to do and just am reminded about some struggles I’ve had from it.

Nice typo 😛

yeah and my use case is pretty focused. Not doing it all over the place

but it’s conversely

pretty unavoidable

i really need these ‘derived values’

will look at some of what you mentioned

to see about handling it on the event side

i think one saving grace for me

is that there’s basically a single event

entry point for what I need to do

‘update a form value’

so I guess I could have a collection or someting of my computation functions

and basically if the key im updating is in a function apply that function to the db

probably wony be super elegant

Yeah, in your case, that sounds like it may work alright though

You can also check out the subs inject stuff for event handlers

@mikerod To make sure that you always, as you put it, "clear derived data" when some of the events might have invalidated some data, you can split [some of] your events in two parts. One part is the user intent, and the other is the one that changes actual DB values. In this case, all changes to :field1 and :field2 will be made by two event handlers. After this split, you can make them both have the same interceptor that re-calculates and stores value for :field3.

It's somewhat similar to level-2 and level-3 subscriptions.

@p-himik interesting. So you are describing using an intercepter to create this derived data into the db “automatically” for event handlers that include it?

I’ve not really explored much interesting usages of intercepters. If I understand you correct, that is an intriguing thought

Hello all, can I use reframe-utils more than one place?

using rfu/multi-generation rfu/reg-basic-sub in two cljs files?

the problem for me is that i need that behavior to be somewhat dynamic. I can’t ‘hardcode’ the interceptors, etc

yeah, I see what you mean I believe

@eoinmonty Can you give a small example? I don't quite understand what you mean by "somewhat dynamic". @fabrao Nothing should prevent you from doing that, unless you change re-frame-utils and somehow introduce a circular dependency.

well in my example

my events aren’t like [:set-field-1 value] but rather [:set-field :field-1 value]

so i need to ‘dynamically’ determine if field-1 is involved in any computations, if so, update the values that it’s associated with

I don't see a problem here. The interceptor would just check for :field-1 changes.

hmm, i guess you’re right

i’ve already started on some generic code

to traverse the computations, etc

so will just hook it in

via an interceptor