om-next

2016-09-05T12:21:51.000007Z

If you are asking about passing properties, which Im not sure since its not in your code. Then pass properies to it (maybe from root) by (dialog-modal {:dialog/id id}) given that id is a property/value coming from its parent component. Dont know well om/get-computed, never found a reason to use it.

levitanong 2016-09-05T18:20:22.000009Z

@am-a_metail I can’t imagine that maintaining a separate globally scoped map of values would be more idiomatic than what you did in the beginning. What your colleague suggests seems rather contrived to me. Further, if he suggests that route, why not place the contents of error-data in app state altogether? In which case, you’d have a separate (defui Error) containing an (ident [this {:keys [dialog/id]}] [:error/by-id id]) and (query [this] [:error/title :error/message]). Ad then your Dialog would include the Error’s query and incorporate it into its own.

levitanong 2016-09-05T18:21:47.000010Z

I’m assuming you intend Dialog to be as general as possible—which would mean that it shouldn’t know anything about your app state’s structure. It seems to me that om/computed is the correct way to go.

am-a_metail 2016-09-05T18:22:53.000011Z

Thanks @levitanong - that was my intention

am-a_metail 2016-09-05T18:23:19.000012Z

And the ident never occurred to me but makes perfect sense

levitanong 2016-09-05T18:23:35.000013Z

You get other benefits in going om/computed as well. You can pass other hiccup syntax like (dialog-modal (om/computed {} {:message [:div [:div [:div [:div “derp”]]]]}))

am-a_metail 2016-09-05T18:24:23.000014Z

Is that better than using children?

levitanong 2016-09-05T18:24:59.000015Z

even better:

(dialog-modal (om/computed {}
  {:message [:div “close me” 
               [:button {:on-click some-close-fn} “Close”]]})

am-a_metail 2016-09-05T18:25:27.000016Z

Yeah I like that

levitanong 2016-09-05T18:25:40.000017Z

what is better than using children?

am-a_metail 2016-09-05T18:26:13.000018Z

See first example: (om/children) for example

am-a_metail 2016-09-05T18:27:30.000019Z

(dialog-modal (om/computed ...) (child/view {})

am-a_metail 2016-09-05T18:27:34.000020Z

Or something

levitanong 2016-09-05T18:27:41.000021Z

Oh, well I didn’t know about om/children at all 😛 I don’t think that’s documented at all!

levitanong 2016-09-05T18:27:45.000022Z

Now I feel silly

levitanong 2016-09-05T18:27:57.000023Z

Today I learned.

am-a_metail 2016-09-05T18:28:29.000024Z

Not silly - it's not documented as you say

levitanong 2016-09-05T18:28:53.000025Z

I would still maintain my stance though, that if your component is to be generic, it shouldn’t know the structure of your app. Like, you should be able to drop it into another app.

levitanong 2016-09-05T18:29:02.000026Z

and it should work just fine.

levitanong 2016-09-05T18:29:10.000027Z

So I think you’re doing the right thing 🙂

am-a_metail 2016-09-05T18:29:38.000028Z

I am constantly fighting YAGNI even when the effort for reusability is equal/less

am-a_metail 2016-09-05T18:29:58.000029Z

And now spend half my time fixing bugs

am-a_metail 2016-09-05T18:30:09.000030Z

Bah

am-a_metail 2016-09-05T18:30:24.000031Z

But thanks for confirming I wasn't doing something weird

am-a_metail 2016-09-05T18:30:29.000032Z

Or too weird anyway

levitanong 2016-09-05T18:31:27.000033Z

No problem 🙂 Thanks for letting me know about om/children! 🍻