This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-26
Channels
- # aleph (2)
- # beginners (119)
- # boot (18)
- # cider (19)
- # cljs-dev (46)
- # cljsjs (1)
- # cljsrn (30)
- # clojure (101)
- # clojure-dusseldorf (12)
- # clojure-finland (1)
- # clojure-greece (7)
- # clojure-india (2)
- # clojure-italy (6)
- # clojure-poland (4)
- # clojure-russia (120)
- # clojure-sg (3)
- # clojure-spec (147)
- # clojure-uk (75)
- # clojurescript (86)
- # cursive (4)
- # datomic (50)
- # docker (1)
- # emacs (4)
- # juxt (51)
- # leiningen (16)
- # liberator (1)
- # luminus (1)
- # lumo (116)
- # mount (2)
- # off-topic (2)
- # onyx (38)
- # pedestal (4)
- # protorepl (2)
- # re-frame (44)
- # reagent (8)
- # ring-swagger (16)
- # schema (5)
- # specter (16)
- # test-check (226)
There is any push-state-fx
? Some of {:db db :push-state [history "name" "/foo-bar"]}
@timgilbert I'm looking something like https://mozilla-services.github.io/react-jsonschema-form/, i.e. metadata driven form builder to hack 100*x forms
@souenzzo Not that I know of, but should be pretty easy to write your own https://github.com/Day8/re-frame/blob/master/docs/Effects.md
That looks interesting @nicola, I look forward to your clojurescript wrapper appearing on github š
I need advice. I wrote an event handler that determines whether a player and a (roguelike dungeon) coin intersect, dispatching pickup-coin events accordingly
(rf/reg-event-db
:collision-check
(fn [db _]
(let [coin (get-in db [:coin])
player (get-in db [:player])]
(when (aabb-intersect? (obj->aabb coin) (obj->aabb player))
(rf/dispatch [:pickup-coin]))
db)))
Iām not sure that this code is good enough, given that it returns the db as is in all cases. Doc organization is confusing (a bit) and I wonder if a better way to handle this would be via reg-event-fx instead.Does this make better sense?
(rf/reg-event-fx
:collision-check
(fn [{:keys [db]} _]
(let [coin (get-in db [:coin])
player (get-in db [:player])]
(if (aabb-intersect? (obj->aabb coin) (obj->aabb player))
(rf/dispatch [:pickup-coin])))))
Or that?
(rf/reg-event-fx
:collision-check
(fn [{:keys [db]} _]
(let [coin (get-in db [:coin])
player (get-in db [:player])]
(if (aabb-intersect? (obj->aabb coin) (obj->aabb player))
{:dispatch [:pickup-coin]}))))
Saw this in Effects.md: > When an event handler is registered via reg-event-fx, it must return effects. So need to change previous to:
(rf/reg-event-fx
:collision-check
(fn [{:keys [db]} _]
(let [coin (get-in db [:coin])
player (get-in db [:player])]
(if (aabb-intersect? (obj->aabb coin) (obj->aabb player))
{:dispatch [:pickup-coin]}))))
{}
I'm pretty sure you can return nil for no effects, so you could rewrite that last one to (when (intersect? ...) {:dispatch ...})
@timgilbert Not according to https://github.com/Day8/re-frame/blob/5c0268411b9a293534ecbcb5e04e8e860d2c2d2f/docs/Effects.md but will try. Those docs have got to be in flux.
Hmm, you might be right. Anyways, I would personally use the third form there
And it works. You were right.
Will file a docs bug issue.
You might also want to look into https://github.com/Day8/re-frame-async-flow-fx which basically exposes a little DSL for the bespoke state machine that you're building in re-frame
<reading it>
Hehe. Async Control Flow is kind of a contradiction in terms, but neat idea. Reading moreā¦
Really neat. Will make use of this right away.
@gamecubate I think the docs are correct however in an idealogical way. The super powers that come from reg-event-fx
is that you can get away from side-effecting event handlers exactly like you have. So everything in the documentation should prevent you from doing what you are currently doing.
However since we arenāt in an ideal world and sometimes you have to do things you arenāt proud of the code does allow you to return nil but that isnāt nicely documented because you shouldnāt be doing it
I had decided against filing a doc bug issue because the docs are as much in a set of flux as re-frame is. No point making a fuss untili things have stabilized.
Have to say that re-frame is quite cool and it looks like itāll save me those headaches I had with my last, reagent-only app.
Anyway, now testing it, along with a physics engine, for a game prototype.
I must say I really love it. Itās cool youāre making a game with it. Howās that working out? I have been playing with the idea of making a re-frame game but it would still be like a web application akin to http://urbandead.com
So far so good. Picking an engine was tough. Eventually settled on planck js. Then thought to add re-frame to the mix. It took me couple of days to conclude that decision was not a mistake. Re-frameās insistence of separation of concerns may complexify project launch but simplifies things as it (the project) grows and features need to be added.
Not 100% sure of my choices yet. For example, starting the game loop outside of the framework as opposed to inside the :initialize event handler. Also, storing refs to physics bodies inside the app-db was a scary idea but seems to work out really well (no over-rendering of views).
Will eventually open source the test app given I had been looking for just that for a long time.
I sure will.
where in that does it say you can't return nil from an fx handler?
the docs should be pretty stable at the moment, so file a bug or comment in here with a specific question
not totally clear what you were talking about wrt docs bugs?
@danielcompton https://github.com/Day8/re-frame/blob/5c0268411b9a293534ecbcb5e04e8e860d2c2d2f/docs/Effects.md#where-effects-come-from > When an event handler is registered via reg-event-fx, it must return effects. From that, I had assumed that one must be explicit in the returning of a value, as opposed to implicitly returning nil with an
(if test then)
(i.e., no else) form. My mistake, though I might have worded it differently (Event handlers registered via reg-event-fx return effects, or nil).We can probably make that a bit clearer
FWIW, I think it's good style to use (when x? foo)
versus (if x? foo)
since the latter looks like you might have just forgotten to include the else clause in (if)
True.
Is anyone aware of any pattern to deal with need to have āprogressiveā calculations with subs? Example: I have big data structure calculated with sub, and view which is capable of rendering it even with some fields missing. Calculations of some fields takes much longer time, and I donāt want user to experience significant delay before he sees high-level structure. Rest of the fields should appear once calculations is completed (there could be multiple steps). So, it would behave very similar to āprogressive jpegā images in browser, but on the structural level.
@dragoncube you can describe this as a tree of subscriptions
where the slower calcs take as input the faster ones
and then you take subs off the fast and slow ones and use them in the page