Fork me on GitHub
#re-frame
<
2018-03-01
>
codxse15:03:12

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

codxse15:03:59

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

joelsanchez15:03:11

it already does what you want

codxse15:03:08

hmmm, weird.. 😕

codxse15:03:46

the error was callback function

eoliphant16:03:18

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.

mikerod16:03:26

@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.

mikerod16:03:06

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

mikerod16:03:21

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

eoliphant16:03:45

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.

eoliphant16:03:00

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

eoliphant16:03:04

i know that what I was asking

eoliphant16:03:17

is kind of ‘unclean’

mikerod16:03:19

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)

mikerod16:03:32

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

mikerod16:03:46

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

mikerod16:03:31

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

mikerod16:03:56

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

mikerod16:03:29

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

eoliphant16:03:59

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

mikerod16:03:28

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

mikerod16:03:35

and the main reason is the “signal graph” idea

mikerod16:03:54

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

mikerod16:03:09

Because they invalidated some data that led to that derived data

mikerod16:03:17

On the subscription side, this is really nice an elegant

mikerod16:03:55

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

mikerod16:03:40

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

eoliphant16:03:50

i’ll give a few of these a shit

mikerod16:03:12

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.

mikerod16:03:19

Nice typo 😛

eoliphant16:03:44

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

eoliphant16:03:49

but it’s conversely

eoliphant16:03:55

pretty unavoidable

eoliphant16:03:14

i really need these ‘derived values’

eoliphant16:03:59

will look at some of what you mentioned

eoliphant16:03:08

to see about handling it on the event side

eoliphant16:03:13

i think one saving grace for me

eoliphant16:03:21

is that there’s basically a single event

eoliphant16:03:27

entry point for what I need to do

eoliphant16:03:31

‘update a form value’

eoliphant16:03:12

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

eoliphant16:03:47

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

eoliphant16:03:53

probably wony be super elegant

mikerod16:03:00

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

mikerod16:03:38

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

p-himik17:03:36

@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.

p-himik17:03:59

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

mikerod17:03:11

@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?

mikerod17:03:36

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

fabrao17:03:42

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

fabrao17:03:53

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

eoliphant17:03:32

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

mikerod17:03:02

yeah, I see what you mean I believe

p-himik18:03:05

@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.

eoliphant18:03:31

well in my example

eoliphant18:03:20

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

eoliphant18:03:08

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

p-himik18:03:15

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

eoliphant18:03:25

hmm, i guess you’re right

eoliphant18:03:37

i’ve already started on some generic code

eoliphant18:03:49

to traverse the computations, etc

eoliphant18:03:57

so will just hook it in

eoliphant18:03:06

via an interceptor