Fork me on GitHub
#re-frame
<
2017-04-26
>
souenzzo01:04:19

There is any push-state-fx? Some of {:db db :push-state [history "name" "/foo-bar"]}

niquola04:04:37

@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

curlyfry05:04:39

@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

timgilbert13:04:29

That looks interesting @nicola, I look forward to your clojurescript wrapper appearing on github šŸ˜‰

gamecubate14:04:41

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.

gamecubate14:04:27

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])))))

gamecubate14:04:30

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]}))))

gamecubate16:04:28

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]}))))
        {}

timgilbert16:04:34

I'm pretty sure you can return nil for no effects, so you could rewrite that last one to (when (intersect? ...) {:dispatch ...})

timgilbert16:04:20

Hmm, you might be right. Anyways, I would personally use the third form there

gamecubate16:04:45

And it works. You were right.

gamecubate16:04:53

Will file a docs bug issue.

timgilbert16:04:31

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

gamecubate16:04:10

<reading it>

gamecubate16:04:45

Hehe. Async Control Flow is kind of a contradiction in terms, but neat idea. Reading moreā€¦

gamecubate16:04:31

Really neat. Will make use of this right away.

kasuko18:04:31

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

kasuko18:04:18

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

kasuko18:04:12

I spoke too soon

gamecubate18:04:50

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.

kasuko18:04:58

I see thatā€™s what you are doing

gamecubate18:04:09

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.

gamecubate18:04:41

Anyway, now testing it, along with a physics engine, for a game prototype.

kasuko18:04:29

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

gamecubate18:04:28

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.

gamecubate18:04:44

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

gamecubate18:04:11

Will eventually open source the test app given I had been looking for just that for a long time.

kasuko18:04:28

Sweet, sounds awesome. If you do open source Iā€™d definitely check it out!

gamecubate18:04:24

I sure will.

danielcompton19:04:29

where in that does it say you can't return nil from an fx handler?

danielcompton19:04:15

the docs should be pretty stable at the moment, so file a bug or comment in here with a specific question

danielcompton19:04:43

not totally clear what you were talking about wrt docs bugs?

gamecubate19:04:04

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

danielcompton19:04:55

We can probably make that a bit clearer

timgilbert19:04:00

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)

dragoncube20:04:33

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.

danielcompton23:04:14

@dragoncube you can describe this as a tree of subscriptions

danielcompton23:04:26

where the slower calcs take as input the faster ones

danielcompton23:04:45

and then you take subs off the fast and slow ones and use them in the page