This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-09-06
Channels
- # beginners (147)
- # boot (12)
- # chestnut (12)
- # cider (22)
- # clara (10)
- # cljs-dev (6)
- # cljs-experience (3)
- # cljsrn (12)
- # clojure (58)
- # clojure-austin (3)
- # clojure-dusseldorf (25)
- # clojure-finland (20)
- # clojure-gamedev (1)
- # clojure-greece (3)
- # clojure-italy (32)
- # clojure-new-zealand (5)
- # clojure-russia (12)
- # clojure-serbia (1)
- # clojure-spec (4)
- # clojure-uk (51)
- # clojurescript (75)
- # cursive (8)
- # datomic (81)
- # fulcro (29)
- # graphql (16)
- # heroku (6)
- # incanter (1)
- # keechma (1)
- # lumo (44)
- # off-topic (21)
- # onyx (22)
- # parinfer (5)
- # portkey (40)
- # re-frame (43)
- # reagent (5)
- # spacemacs (37)
- # specter (8)
- # unrepl (3)
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?
https://github.com/Day8/re-frame/blob/master/docs/External-Resources.md
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.
Clues were in https://github.com/ransomw/emo-mcg/blob/test--doo-phantom/exp/test/clj/emcg/e2e_test.clj#L83 and https://github.com/bensu/doo/wiki/End-to-end-testing-example
if you're using re-frisk 0.4.5 please upgrade to 0.5.0 because nasty issue in 0.4.5 https://github.com/flexsurfer/re-frisk/issues/38
I'm using a reg-sub-raw to handle subscriptions to an external db. Here's a simplified version of my code:
(re-frame/reg-sub-raw
:firebase/on-value
(fn [app-db [_ path]]
(.on path "value" #(>evt [::cache-evt path %]) default-error-handler)
(rv/make-reaction
(fn [] (get-in @app-db [::cache path] []))
:on-dispose #(do (.off path "value" callback)
(>evt [::cache-evt path nil])))))
... 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?
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?
well, it gets complex but that's what we do here. not sure if there is a better way though
likewise ๐
not advising it, but here we made a special fx "flavor" for dispatching events as the current handler finishes
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)
(reg-event-fx
:some-event
s-i/trim-log-check
(fn [_ stuff]
(if (:thing stuff)
{:dispatch-n [[:yet-another-event stuff] [:another-event]]}
{:dispatch-n [[:there-it-goes]]})))
kinda like this
why not
(reg-event-fx
:some-event
s-i/trim-log-check
(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
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