Clojurians Log v2

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!

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

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

@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

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

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?

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?

you wouldn

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

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

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

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

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

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

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

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

right, so you probably only ever set that context once

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

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

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

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!

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

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

hmm?

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

ah, ok, so time to back up then

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

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

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

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

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

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

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

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

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

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

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

yep

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

om next is far from obvious to me anyway

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

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

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

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#?

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

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

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

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

apparently not 😞

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

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

*instance

Rather than per class

@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

:thinking_face:

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

^ looks like you can do it with:

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

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?