Fork me on GitHub
#om
<
2017-05-31
>
adamvh01:05:01

it seems like what you want to do is write a mutation that assoc’s your context into the app state atom and then run it in your life-cycle method with om/transact!

adamvh01:05:54

if your canvas context is associated with the key :ui/ctx, you can include this in your canvas’s query

adamvh01:05:40

and then om will know to re-render each time you bang on your canvas with a mutation

sophiago01:05:22

@adamvh so you're saying just go ahead an use swap! inside componentDidMount to assoc it to the store? i know that will work, just wondering whether there was a better way

sophiago01:05:32

and since this is canvas, i definitely do not want it to rerender every time i draw to it. otherwise it would always be blank! but i wouldn't be updating the context anyway, just querying it so i have something to draw to

sophiago01:05:24

regardless, in the interest of understanding Om.Next more, are you saying updating any keys prefixed with "ui" trigger a rerender? i assumed it was just anything under :keys, which is stored inside a key corresponding the particular component?

sophiago02:05:32

if i assoc to the store directly like this: (swap! assoc-in [(keyword this) :ctx] (.getContext (aget this id) "2d")) i'd still prefer to assoc the context actually where the component's other keys are stored rather than use the (keyword this) hack. can anyone explain that?

adamvh02:05:52

you wouldn

adamvh02:05:12

‘t assoc it to the store, you would would do something like

adamvh02:05:01

call (om/transact! [(assoc-ctx-to-store) {:ctx ctx}])`

adamvh02:05:30

and then you would have a big ‘ole multi-method which i’ll call mutate

adamvh02:05:06

and this multi-method will dispatch on the symbol ‘assoc-ctx-to-store

sophiago02:05:23

what is "assoc-ctx-to-store" supposed to represent?

adamvh02:05:43

it’s just a symbol inside a syntax-quoted form

adamvh02:05:07

that om.next will use as a dispatch key for calling your mutation multi-method

sophiago02:05:23

well, re: the multimethod...you realize one doesn't ever need to change the context for a given canvas, right?

adamvh02:05:19

right, so you probably only ever set that context once

sophiago02:05:50

yes, which is why i'm putting it inside componentDidMount instead of componentDidUpdate

adamvh02:05:34

i guess what i’m suggesting is equivalent to just doing swap! to get that context into your app state

adamvh02:05:05

so yea you’re right that seems like the thing to do here

sophiago02:05:18

well i think you're answering my question exactly, i.e. what's the idiomatic way to assoc it using om rather than crudely with swap!

adamvh02:05:36

except that if you do it via om.next’s way your component doesn’t have to take the app-state as a parameter

adamvh02:05:03

and the way to do that would be to specialize your mutation mutlti-method for some key

sophiago02:05:25

i still have no idea what you mean by "mutation multimethod"

adamvh02:05:39

ah, ok, so time to back up then

sophiago02:05:48

i don't understand why this calls for using a multimethod at all

adamvh02:05:45

when you create an om.next reconciler, you pass it a map with keys :read and :mutate

adamvh02:05:14

and the values associated with these keys will be two multi-methods

adamvh02:05:57

your components will generally implement om/IQuery and return some EDN

adamvh02:05:50

your :read multi-method is responsible for dispatching on the values of this EDN (it’s basically a parser)

sophiago02:05:15

well, currently i'm only passing the store to the reconciler and then adding my factory element with add-root!

sophiago02:05:28

i'm reading the docs for transact! now and it seems the point is to schedule rerenders based on those keys, which obviously can't happen for the canvas's context

sophiago02:05:24

i guess i'm just confused about why i'd need to set up :read and :mutate keys just to store one static value per component created via the factory

adamvh02:05:27

ah, i think you want om/set-state!

adamvh02:05:37

that’ll let you define the context as state local to your component

sophiago02:05:06

ah ok. so that will keep it local to the component, but outside of :keys used for props?

sophiago02:05:26

yeah, that sounds perfect (and, sadly, obvious)

adamvh02:05:49

om next is far from obvious to me anyway

sophiago02:05:17

eh, personally i just haven't read into how the reconciler works enough. but the whole reason i use om next is because it maps onto how i used react itself pretty well

sophiago02:05:40

i.e. using the top level API vs. JSX, the latter being a bit more how reagent works

sophiago02:05:40

anyway, so for the record i'm just calling this inside componentDidMount: (om/set-state! this {:ctx (.getContext (aget this id) "2d")})

sophiago02:05:33

and then in my function to create new canvases using the factory i'd assume: (swap! store assoc (keyword id) {:id (str id), :width width, :height height}) where "id" is probably something like canvas#?

sophiago02:05:17

or actually maybe that'd be better with set-state! and the factory itself?

sophiago02:05:50

idk. again, swap! is what i've used historically with factories

sophiago02:05:17

ah, although the problem is i'm not sure how to get the id for the component that's just loaded in order to query the context. i either need to use assign a ref to the component (with a gensym) or query the id from props

sophiago03:05:44

ok, snippet updated. i think this is correct...

sophiago03:05:28

apparently not 😞

nikki04:05:15

@sophiago idk if this helps but you can generate an ident and/or implement IQueryParams

nikki04:05:34

The former can take props as parameters to generate a query argument per instsnce

nikki04:05:37

*instance

nikki04:05:40

Rather than per class

sophiago04:05:24

@nikki the problem currently is it's not generating new canvases at all. i need to compare it to a version of the same code i have that generates other ui components similarly to troubleshoot

nikki05:05:02

:thinking_face:

dehli12:05:18

Can you set data attributes on elements when using om next?

dehli12:05:08

^ looks like you can do it with:

(dom/div #js {:data-example ""})

gordon20:05:03

Any idea why a child component having a join with an ident key would not cause a remote (or any) read for that ident when the root component's query is updated to include said child?