Is there a way of tearing down async-flow-fx flows? I'm working on tests (using re-frame-test for the first time) and some of the flows didn't terminate, but with every test run the async flows accumulate

related - using re-frame test is it possible to run async tests that depend on other async tests. e,g, for me app/initialize is async, so is login, and both of those I'd like to reuse in subsequent tests. I'm getting obscure null pointer errors (with no stacktrace because it's react native , 😳) but I can't tell if I'm trying to use it for something it's not designed for.

(deftest initialize
  (reframe-test/run-test-async
    (test-fixtures)
    (let [loading-state (reframe/subscribe [:ui.global/loading-state])]
      (reframe/dispatch [:app/initialize])
      (reframe-test/wait-for [:app.initialize/success]
                             (println "Initialized")
                             (is (= @loading-state :ui.loading-states/loaded))))))


(deftest login
  (reframe-test/run-test-async
    (let [login-state (reframe/subscribe [:ui.login/login-state])]
      (initialize) <-- can I do this??? or this kinda thing??
      (reframe/dispatch [:ui.login/set-email ""])
      (reframe/dispatch [:ui.login/set-password "success"])
      (reframe/dispatch [:ui/login])
      (reframe-test/wait-for [:ui.login/success :ui.login/failure]
                             (println "Logged in")
                             (println @login-state)
                             (is (= @login-state :ui.login.login-states/logged-in))))))

Does anyone have a link to a write-up of how to use the new(-ish) re-frame cofx stuff for those of us who were brought up on good ol' register-handler?

@pandeiro The docs on the github repo are pretty decent (if you haven’t seen those yet — I know I missed them the first time I went through the front-page README stuff)

https://github.com/Day8/re-frame/blob/master/docs/Coeffects.md

Oh nice, yes I had missed that

Hi, I’m looking for ‘best practices’ for forms in re-frame. It’s taking a little getting used to, but I’ve gotten my brain around the ‘global immutable state’, etc I think. So say for a login form, i’ll have a {:login-form-data {:name nil :password nil} entry in the db. So now I have a login form. When I’m say handling the onChange for the name field, should I be doing a dispatch for it (and by extension every) field? What’s the best approach for subscriptions/handlers in this case? it seems like having one per field would be trivial in this case, but would get tedious very quickly

I can’t speak for best practices, but I have tried both having form state in a local ratom (i.e. inside a let in the component definition), versus keeping a form in my app db under something like [:ui :forms :login :username] etc.

ok so, you then only dispatch on say a submit ?

What’s nice about the latter approach is that it makes it very easy to have a single :verify-login-form event that goes through and validates all your inputs, plus a set of subscriptions to the list of validation errors.

Yeah, if you’re using a local ratom you wait until the form submit and then dispatch a login event.

ok hmm

in fact for something as simple as a login, I might be tempted to use the local ratom even if I were using the longer app-db style for more complex forms

so then once there’s data for a given form, you’d say copy the data from the app-db to the local ratom for edit, etc?

yeah i just used login to avoid a lot of typing lol

i’m more concerned with ‘real’ forms

I should say, for the local ratom login form, I’d create the ratom at the level of a form group, and then have each form field access the ratom, but you get the idea.

Yeah, for real forms, I like the longer, app-db-based approach, on the theory that you can copy/share validation between the form and the current db data, and it’s easier to move stuff to/from the edit form

Ok, so basically, have a ‘form cache’ in a local ratom. I can do enhanced stuff as necessary against some app-db copy. Post validation, do a dispatch that would say update the app-db, call the server (or perhaps the other way around), etc.

Ok gonna give that a whirl

It’s worth playing with, but I found it limiting in the long run. Easier in the short term, but you might regret it later (unless it’s something really trivial/ephemeral like a login form).

ah wait, sorry I think I misunderstood, you’re saying that was ultimately better to work directly with the app-db?

if so, how did you handle the dispatching, etc. something like an subscription/handler for the whole form?

No, I dispatched each field/button separately, but I used a common dispatch function that took, as arguments, which field to update, plus the value

so something like #(re/dispatch [:login-form/update-field :username (-> % .-target .-value)])

Ok, gotcha, I’ve been hacking away a bit and have kind of arrived at something similar I think

yeah that’s almost exactly what I have for my dispatch

:thumbsup:

Hello all, do you think is there side effects doing this?

(reg-event-db
 :clean-login-fields
 (fn [db [_]]
   (assoc db :username "")
   (assoc db :password "")))

so, on the grabbing it back I did more or less what you do for form ratoms (let [formdata @(rf/subscribe [:formdata])) ... then have my form fields’ values key into that

@eoliphant That works. On my first iteration I did it more reagent style (let [formdata (reagent.atom/atom {})] ...) (don’t remember the exact syntax off the top of my head, but that’s the idea)

cool

yeah i’m literally testing it now

but that got tedious because everything that does anything to the form data has to live inside the let

seems to work 😉

validation etc.

hmm fair point

much nicer to have it update the app db, so you can share validation fns between forms, etc.

ah

right

crap lol

again, shifting my thinking

the form doens’t really ‘own’ the data per se

so no reason to tie validation, etc to in when it’s not ncessary

In fact I tend to name my forms things like :address-editor, so it’s living at [:ui :editors :address-editor] in my app db. Then I can use the same clojure spec for the data when it’s being edited, and when it isn’t, and it’s easy to move from one to the other.

and if I have an :email field in multiple different editors, they can all share the same validation fns (and Clojure spec).

hmm yeah

that seems really flexible

Like I say, I can’t speak to “best practice” but I’ve been a bit happier with keeping everything in the app db except for really ephemeral stuff

yeah

i’m coming around to that lol

and the more i think about it

it’s especially useful

for what i’m doing

i’m ‘rehosting’ a legacy dynamic forms app (Java,Oracle, etc)

to datomic/clojure(script)

I’ve already pretty much captured their core datamodel in literally a page of code and edn.

so now working on the rendering,etc

just ran into something interesting, i’m still figuring all of this out, but I just noticed in my form that i’ve converted from the ratom approach to the app db approach grabbing the entire form’s data in the let isn’t reactive

(defn test-form
  []
  (let [formdata @(rf/subscribe [:test-form])]
    (fn []
....
:value       (:testfield2 formdata)