Fork me on GitHub

I'm looking for a decent size walkthrough tutorial of a re-frame app from the beginning, does such a thing exist?


@josh_horwitz no tutorials on larger applications that I know of. /examples/todomvc is very detailed, but obviously limited Apart from that, look in External Resources for existing, larger applications?


Hi, Iโ€™m interested to know if anyone is successfully using the re-frame-test library with the http-xhrio effect handler making real AJAX requests.


This is to with the javascript environment that the test runner runs in. I havenโ€™t yet found a combination that works.


FWIW I got this working in phantom by adding --web-security=false --local-to-remote-url-access=true options, wrap-cors to my server middleware and specifying the base url in all of the ajax requests.


if you're using re-frisk 0.4.5 please upgrade to 0.5.0 because nasty issue in 0.4.5


I'm using a reg-sub-raw to handle subscriptions to an external db. Here's a simplified version of my code:

 (fn [app-db [_ path]]
   (.on path "value" #(>evt [::cache-evt path %]) default-error-handler)
    (fn [] (get-in @app-db [::cache path] []))
    :on-dispose #(do (.off path "value" callback)
                     (>evt [::cache-evt path nil])))))

I don't quite understand how this is supposed to interact with sub caching in re-frame. Say I have two components, A and B. While A remains mounted, B is mounted and then unmounted. I would have expected the :on-dispose to only be called when A is finally unmounted, but it looks like it gets called when B is unmounted. Is this expected behavior?


... never mind. It does behave as I had expected. I was being faked out by something I did.


Hi all. We've got quite a large app using re-frame and its huge size is becoming a major pain point. We're considering options to split it into modules, each in its own lib, and import them in a "master" app. However, I'm puzzled about how to achieve it. Splitting events, handlers, subs and views seems straightforward but I can't come up with a decent way of sharing assets. Let's say I want to make a change on a specific module - I can just fire up devcards for checking views and mess directly with its structures (views, subs, events) through the repl and running tests. While this supposedly works, I'll have to resort to questionable means to fetch the main CSS from the "main" app. It's either copying it over or keeping it duplicate among all libs, both don't sound viable to me. Anyone here every tried something similar? Any thoughts you'd like to share about it? Any other issues or concerns we might be missing?


@viniciushana we have a similar situation with compiled resources and our app builds - the (hacky, but workable) solution we use is good old softlinks


Welp, if it works it works ๐Ÿ˜„ I was thinking of either that or introducing dependency hell by extracting common assets to another lib


But from all the ideas, softlinks are very simple adopt and despite their hacky nature, it doesn't introduce the downsides from other approaches


yeah, i felt icky about them at first, but they really work very well - especially if you have a unirepo so you can guarantee relative paths


And that's precisely our situation here. We have a bunch of helper scripts that rely on knowing where is the root for all our source folders, so we can leverage it further by adding this additional layering of where to fetch assets.


once a user is logged into my app, I need a bunch of things to happen, my initial reaction is that it should be in a subscription but i've never written a subscription to extract data from a remote source, what's the best way to accomplish this?


not sure if i follow: shouldn't you dispatch an event to make these bunch of things happen?


my main confusion is where to dispatch said events


I assume you dispatch an event when the user presses login, right?


so it would dispatch events as part of this pipeline


is that appropriate to kick off numerous events as a successful response of a call to log in?


just looking for the "right" way to do this


well, it gets complex but that's what we do here. not sure if there is a better way though


k, well that helps to know i'm not alone at least ๐Ÿ™‚


likewise ๐Ÿ˜„




not advising it, but here we made a special fx "flavor" for dispatching events as the current handler finishes


why not use reg-event-fx and return a dispatch key?




as in the dispatch effect


that's what we do, perhaps i expressed myself poorly:

(defn dispatch-n [events]
  (doseq [event events] (dispatch event)))

(re-frame/reg-fx :dispatch-n dispatch-n)

  (fn [_ stuff]
    (if (:thing stuff)
      {:dispatch-n [[:yet-another-event stuff] [:another-event]]}
      {:dispatch-n [[:there-it-goes]]})))


kinda like this


why not

  (fn [_ stuff]
    (if (:thing stuff)
      {:dispatch [[:yet-another-event stuff] [:another-event]]}
      {:dispatch [[:there-it-goes]]})))


ah yeah, we do some schema validations before dispatching


so we have a specific fn that does this and then delegates dispatch to re-frame


makes sense


yep, although i'm very open to new ideas


i'm building my re-frame knowledge so i'm not aware of anything better, what you have makes sense in my brain though ๐Ÿ™‚


didn't really took part in deciding these so i'm learning the ropes


so i guess we're pretty much in a similar context, hah