Fork me on GitHub
#re-frame
<
2017-06-21
>
qqq00:06:14

(defn foo [kw]
  ... @some-r-atom ...)

(def foo-view
  [foo :bar])

(rc/render foo-view app-div)


Now when @some-r-atom changes, I expect the div to re-render.
Is that correct? (Because it's not re-rendering)

tanzoniteblack00:06:49

@qqq yes, that’s how you should expect reagent & ratoms to work

tanzoniteblack00:06:02

generally if you’re not seeing that, then 1.) verify that you’re actually using reagent.core/atom, not just the regular clojurescript atom and 2.) inspect the atom in your repl to verify that the change you expect is actually being made to the atom

qqq00:06:19

@tanzoniteblack : will try that advice; thanks!

qqq00:06:09

lol; it works now

tanzoniteblack00:06:13

other random things that might cause that: use defonce to create global atoms, so you’re not wiping state out when re-evaluating the NS in your repl (or figwheel)

qqq00:06:21

on the on-click, I js / console logged a "this is changing" message

qqq00:06:25

but then I didn't actually change the ratom

tanzoniteblack00:06:33

😄 that would do it

qqq00:06:14

since we're alread discussing this

qqq00:06:45

a [func arg1 arg2 arg3] is re-rendered whenever: (1) a prop (arg1, arg2, arg3) changes OR (2) an r-atom taht func de-refered changes right ? and those are the only two conditions under which it re-renders

tanzoniteblack00:06:06

those are the only 2 things that you should count on to cause a re-render, yes

tanzoniteblack00:06:39

(however, I’m not familiar enough with reagents internal to guarantee that there is no other way in which a re-render might occur if react so felt like it for some reason)

qqq00:06:33

fair enough; thanks again for 'rubber duck' debugging 🙂

naomarik08:06:16

In reagent you have components that render subcomponents. Do you always structure your main components to “flow” data down to the subcomponents? The other option is to tie certain subcomponents to global state, so their data comes directly from an atom instead of their parent. this probably isn’t much of a problem when that subcomponent is only appearing once in the page, but makes them less reusable. So question is: is it ALWAYS better to gather all data from some component and flow it down to the subcomponents? this is very obvious when you want a reusable component, but for other things like rendering part of a page, it doesn’t seem really necessary to flow all data down when you can access a piece of info directly. Would you render a full page like this as well?

qqq08:06:34

have you used erlang or smalltalk?

qqq08:06:48

my current style is: (1) have a bunch of objects, they can only talk to each other via message passing

qqq08:06:55

(2) each object has it's own internal state + a draw function

qqq08:06:11

(3) there's a global "shell" that tells objects which div they should render into

qqq08:06:26

so there's "no global flow of state", but a bunch of objects, each of with it's own state

qqq08:06:35

within an object, there is a "global to pdown flow of state"

mikethompson09:06:17

@naomarik I don't there's a single idiomatic way. Sourcing/subscribing to data at a higher level and then passing it down is often a good idea. But it can get a little laborious and inefficient in some cases. So, "it depends".

naomarik09:06:45

yeah i had a feeling that it “depends”

mikethompson09:06:54

But unlike @qqq i would avoid going the objects sending messages approach - actors approach, I assume.

mikethompson09:06:09

Did that for years. Love not doing it now. In fact, designed re-frame to avoid it.

mikethompson09:06:54

The moment one says "It depends" ... that does beg the question "on what". So I'm sitting here wondering if there are any guides I know

naomarik09:06:59

i’m feeling the way that i’m starting to do certain things is passing IDs of relational entities down to child objects from the top, then i have all the info i need to subscribe to data from those subcomponents

mikethompson09:06:14

Yeah, that is certainly a pattern

naomarik09:06:50

is there a lot of overhead of passing loads of data down? i’m not sure so this is why i started doing this

naomarik09:06:14

like if a subcomponent 5 levels down needs the data, you wouldn’t pass that all the way down from the parent would you?

mikethompson09:06:29

Very little overhead. Because often the "id" being passed this time is the same as lat time. Ie. same prop

naomarik09:06:06

even if it’s let’s say a vector of few thousand items?

mikethompson09:06:45

Remember that "props" must be = tested to "last time"

naomarik09:06:07

so pretend you have frame1>frame2>…. all the way to a table that loops through the items, there’s no overhead of passing the data all the way down through the parent components?

mikethompson09:06:49

That does sound a problem

naomarik09:06:02

this is why i started just passing references down, so the table itself knows what to fetch

mikethompson09:06:10

I assuming these large vectors are changing in small ways

naomarik09:06:17

yah could be

naomarik09:06:32

the frames wouldn’t really need to update, just a subcomponent within them

mikethompson09:06:25

So that does seem like the eventual child should subscribe

naomarik09:06:41

so maybe a good pattern to follow is to just throw references down so the child can subscribe to it knowing the IDs it needs — like you said

mikethompson09:06:47

Rather than having the data being passively passed through multiple layers

naomarik09:06:17

that way you just have a map of N keys which wouldn’t typically be larger than 10 for the most extreme cases

naomarik09:06:50

cool — that helps 😉

naomarik09:06:51

i think the other useful thing to have a discussion about is how you structure the client-side data to be able to do things like accept new info from the server and have it normalized so things aren’t repeated. i keep feeling the best solution to this is datascript. at the moment my client side DB is a map of {<table-name> {<pkey> <data>}} and this allows me to just assoc anything i want into it as i receive new information from the server. the downside is it’s a bit annoying to do filtering/data joining whenever i want a bit of information. i’m not sure what other patterns exist

naomarik09:06:17

before i did this, i was just building data structure that was easy to use for my UI hierarchy and it was a nightmare whenever my UI changed or needed to pull something a different way.

naomarik09:06:19

so that didn’t last long 😉

naomarik09:06:02

i feel that either datalog or querying my data in a graphql style would eliminate some friction i’m having with my subscription queries

jiri.knesl16:06:54

hi, is there any roadmap for re-frame?

mattly20:06:59

is there any way to get the value of a subscription into an event handler besides passing it in as part of the dispatch?

mattly20:06:15

I mean in theory I could recalculate it from the app-db, but in this particular case that's expensive and somewhat convoluted

souenzzo20:06:05

@mattly it's no FAQ (if not, should be) (defn my-subs [foo] bar,,,) (reg-sub :my-subs my-subs) (reg-event-xx :my-event (fn [_ _] (subs/my-sub ,,,)))

mattly20:06:52

@souenzzo similar to a 2-stage subscription?

souenzzo20:06:59

There is no sugar to do that. There is already a bug with the tittle "an easier way to access subs from events"

mattly20:06:09

er, (rf/reg-sub :mysub/name depends-on-subscriptions-fn produce-a-value-fn)

mattly20:06:44

I found the GH issue on the topic

mattly20:06:43

what I'm doing right now (this is really hacky but) is I have a subscription that pulls in the necessary stuff and returns a function that calls dispatch with the needed values from the event and the subscription values

mattly20:06:51

my specific problem has two facets:

mattly20:06:36

1) in the actual DOM event handler, I might need to .preventDefault the event based on the app state and the event value

mattly20:06:26

I can't do that in the dispatch handler because the react-wrapped event has "gone away" by that point, so to speak

mattly20:06:54

2) some of the calculated state is needed in the computation done to update the state in the dispatch handler

mattly20:06:20

oh interesting, you can do @(subscribe [:some-event]) in an event handler