Fork me on GitHub
#re-frame
<
2017-11-21
>
mikethompson05:11:02

Reminder, there are commercial courses on re-frame available here: https://purelyfunctional.tv/courses/understanding-re-frame/

cmal07:11:29

@danielcompton maybe x kb or xx kb in my page. It seems the key strings are used for check specs?

cmal07:11:35

maybe like @mikethompson says, if we do not use check specs, the key strings will be advanced compiled away? I haven't tried this.

mikethompson07:11:56

@cmal the ClojureScript keyword: :annc-toggle-display-type is transpiled to: var blah = new Keyword(... "annc-toggle-display-type", ...) which, after :advanced, becomes: var Jj=new M(null,"annc-toggle-display-type","annc-toggle-display-type",-302319952) So, yes, when you use keywords, you end up with strings. On JS platforms, strings are interned. So although a string might appear multiple times in the source (which is bad because it increases load times), once the strings are loaded, there will only ever be one copy of any one string. Either way, this is a ClojureScript thing, an not something we have any control over. It arises from use of KeyWords.

cmal07:11:11

Thanks @mikethompson. Is this related to that I used the specs (like the todomvc exmaple)?

mikethompson07:11:28

specs involve keywords, so yes

cmal07:11:55

If I do not use specs, will this happen?

cmal07:11:37

I mean if I only use the keyword in handler and subscriber registration.

mikethompson07:11:01

See above my notes on how keywords are transpiled

mikethompson07:11:17

If you use keywords, you'll end up with strings

mikethompson07:11:31

But this is generally not much of a problem

mikethompson07:11:49

You'd have to be using a LOT of keywords for it to be an issue

cmal07:11:08

So every keyword I used in the handlers and subscriptions are compiled. I am just not sure about this. 😄

cmal07:11:27

Thank you very much @mikethompson

tomaas10:11:16

hi, is there a way to fetch app.js with async option? I see that even the production build does document.write which makes async option when loading the script not to work. I'd like to fetch app.js in async way, and then its js to go and modify <div id='app'/> element. Maybe there's an build option to get rid of document.write?

yenda14:11:52

Hi, is it possible to use an effect multiple times in the same event ? For instance if I have a save-to-db effect and I have one event that saves a thing and another that saves a collection of things I would like to reuse that effect for both and be able to make changes to app-db as well

mikerod14:11:32

@yenda I’m a bit confused by the question I think

mikerod14:11:40

It sounds like you want to use the same effect from multiple event handlers?

mikerod14:11:52

e.g.

(rf/reg-event-fx
 :my-event-a
 (fn [{:keys [db]} event-vec]
   {:db (update-app-db db)
    :save-to-db (extract-things-for-saving event-vec)}))

(rf/reg-event-fx
 :my-event-b
 (fn [{:keys [db]} event-vec]
   {:db (update-app-db db)
    :save-to-db (extract-things-for-saving event-vec)}))

mikerod14:11:07

Where :save-to-db is your registered effect?

mikerod14:11:02

your save-to-db effect could just know when to save a coll vs a single based on the incoming args. Or you could have an effect for each. I don’t see what part is what you are specifically curious about though

yenda14:11:53

@mikerod sorry my formulation was not clear, in your code snippet event-b would basically do same as a but for a collection

cmal14:11:35

maybe this: (if (collection? things) do-save-collection-of-things do-save-a-thing) ?

yenda15:11:16

so one way to achieve it would be to dispatch event a for each element or like cmal suggests have a plural version of the effect

cmal15:11:53

or dispatch-n?

mikerod15:11:15

Yeah, I’d think it’d just be conditional logic for coll vs not-coll

mikerod15:11:24

but it would depend I guess on what you are actually doing

cmal15:11:22

Hi, are there any examples on drag-and-drop and brush actions using re-frame? like https://github.com/d3/d3-brush and https://github.com/d3/d3-drag

yenda15:11:20

I am rewriting a ns that was using old version of re-frame to clean up so the idea is that in one case I receive a status and in the other a collection of statuses

yenda15:11:21

but my question has pretty much been answer I can either use dispatch-n to dispatch one event for each status in the collection or I can use a plural version of the save-discover effect

borkdude20:11:43

I’m fighting re-frame syntax again. I have:

(reg-sub 
 ::route
 (fn [_ _]
   (subscribe [:dre.base.subs/cur-page-id]))
 (fn [cur-page-id]
   (subscribe [:page/state cur-page-id]))
 (fn [page-state]
   (:page/route page-state)))
but re-frame says: re-frame: expected a vector, but got: λ[cur-page-id]

mikerod20:11:00

why do you have 3 functions?

borkdude20:11:16

Because each function needs the result from the previous?

mikerod20:11:34

Yeah, you can only have 1 signal fn, but you can return a vector of signals

borkdude20:11:17

I have read the docs and I watched that infographic before asking this questino… again 😉

borkdude20:11:23

But some things still confuse me, sorry

mikethompson20:11:04

No problem, if there's anything the dosc should make clearer please be sure to say

borkdude20:11:09

One thing that isn’t obvious to me is this one: :<- [:todos] Can that handle arguments as well? Like :<- [:todo id]?

mikethompson20:11:21

No, it can't handle arguements

mikethompson20:11:57

It is just syntactic sugar for simple cases

borkdude20:11:38

so in general, it possible to have one or many unrelated signals in a subscription, but no chaining of signals in one subscription -right?

mikethompson21:11:52

Yes, but I'd say it like this: 1. A subscription can have many input signals 2. But it represents only one node in an eventual signal graph 3. If you want to define multiple nodes, which chain, then that's multiple reg-sub calls

mattly21:11:43

is there any way in a registered -fx handler to automatically get something out of the app-state database, without having to have it passed in?

danielneal08:11:54

not as far as I know, unfortunately, you have to get the bits you need in the handler and pass them through

borkdude21:11:03

We have our app db organized like this:

{:cur-page-id :page/search
 :page/search {:search/query …, :page/title "Search",}, 
  :page/details {:page/title "Details"}}
We also have a wrapping component, which displays the :page/title of every selected page. The disadvantage of this structure is that you need a subscription on the whole db to get to the page title, because the currently selected page :cur-page-id is dynamic. We could refactor this, but maybe it’s good to know first what this costs in performance. Is there a way to measure this properly? We could e.g. go to:
{:cur-page-id :page/search
 :titles {:page/search "Search", :page/details "Details"}
:page/search {:search/query …,},
:page/details {...}}
so the wrapping component would only need to subscribe to a subscription which looks at :titles instead of the whole db

danielneal08:11:54

not as far as I know, unfortunately, you have to get the bits you need in the handler and pass them through