Fork me on GitHub
#om
<
2017-01-27
>
tyler00:01:09

Thanks @tony.kay those examples were really helpful

tyler01:01:24

@tony.kay I have a question about the two articles you posted. I was able to get everything to work (thank you very much for the help) but I was wondering how "computed props" fit into javascript react components. For javascript react components do I need to pass computed-props for components that require a callback? When I do this, the callback stops working. However, in your section titled Out-of-band data: Callbacks and such you mention that you can get into trouble complecting callbacks with props.

tony.kay01:01:22

so, computed has to do with supported co-located queries in Om components. You can pass a callback as a plain property (e.g. (assoc props :callback f)); however, it won't work right on re-render with Om components

tony.kay01:01:36

If you have a plain javascript react component, then you do not use computed

tony.kay01:01:42

because it does not have co-located queries

tony.kay01:01:50

nor will it be re-rendered by Om itself

tony.kay01:01:44

So, perhaps understanding the mechanism will help. If you write a defui without a query and ident, you're just making a plain react component. Om will never try to re-render that by itself, because it has no way to know how to supply the props

tony.kay01:01:28

Once you add the ident and query (actually just a query), then Om does know how to obtain the props from the db, and can re-render it in isolation. It does not, however, know how to pass stuff that you added in from the parent (callbacks)

tony.kay01:01:31

Thus computed is used to annotate which things are "computed by the parent" and which are from the app db

tony.kay01:01:09

Om can then cache those for re-render

tony.kay01:01:26

but since plain js components don't have query/app database presence, it is a non-issue, and you just use props

tyler01:01:07

馃挜 a lot of things in om just clicked for me. That makes perfect sense. Thanks for taking the time to explain.

tony.kay01:01:15

sure, happy to help

danielstockton07:01:07

charts are also the one thing i pull in js dependencies for, everything else (daterange pickers, responsive mmenu type nav, datatables...) i've found i can reimplement pretty quickly in cljs with little code, often to be better than anything i can find in js land

linuss08:01:18

Hey guys, I'm having a little trouble: a few functions in Om.Next take a component as their argument (e.g. the set-query! function). I can't really seem to figure out how to retrieve or pass arbitrary components to these functions. The only thing I can seem to find is the om/app-root function, or the om/class->any function, which is mentioned in the docs to be only for development purposes...

danielstockton09:01:33

@linuss it shouldn't be an arbitrary component, it should be the component that you want to change the query of.

linuss09:01:44

Haha, sure, I realize that 馃檪

danielstockton09:01:49

This is usually this in your component lifecycle methods..

linuss09:01:08

Yeah, but I'd like an action on one component to change the query of another

danielstockton09:01:54

This is a use-case for om/computed, either pass a reference to the parent component or pass the event handlers down...

danielstockton09:01:37

I just noticed that IQueryParams is called on all my components, even if they're not rendered... I'm trying to load initial params from the url and wondered why I was getting an error from a page that shouldn't even be connected.

danielstockton09:01:48

Is that necessary or avoidable?

tmulvaney10:01:57

@danielstockton not sure if this is the best way to go about the problem you are having, but with anything that comes from the url I set something in the app state and have my query parser use that particular state rather than trying to put it into the IQueryParams.

tmulvaney10:01:59

Like in a blog scenario, I my {:post/show ...} query would use the current-post-id set in app-state

danielstockton10:01:47

I see, that might be a better way of doing it...

danielstockton10:01:32

It seems query params are designed exactly for my use case though. You could put everything on app-state if you wanted and never use query params..

danielstockton10:01:18

My use-case are things like start/end date and filters for reporting.

tmulvaney10:01:31

To me query params make sense when data is coming in, eg from user input but less so when the params are already set in the state

danielstockton10:01:35

I don't think that distinction is really clear, you can have user input transacted into the state the same as data from the URL.

danielstockton10:01:20

It makes it easy to display the current state of all the controls, because I just look at the component query params... If I transacted everything to state, my query would become a lot more complicated to read everything back in.

tmulvaney10:01:10

I guess in the :post/show example I think it would be weird to write a query to find current-post-id so we could pass it to the PostShow component for use as a query param which will then get passed back as a parameter in the :post/show query.

tmulvaney10:01:29

But I see your point

danielstockton10:01:03

For a detail view, I do something similar to you. Compassus sets :route-params in app-state and my parser reads off the id of the thing to show.

danielstockton10:01:22

My QueryParam approach was working very well until I noticed this (to me unexpected) behaviour after adding more views.

tmulvaney10:01:29

Hmm well I haven't written enough components with QueryParams to run into what you are experiencing

danielstockton10:01:17

I think I can run the initialization code if it matches current-route, otherwise skip and return empty params or something. Just seems a bit hacky and duplicating my routing logic.

danielstockton10:01:51

I'll experiment with your approach in future, see which is easier.

tmulvaney11:01:51

I seem to be mostly using query parameters when remoting. So my local queries use information in the local state but my remotes have params attached because the server doesn't know about the clients state.

tony.kay15:01:12

@danielstockton RE: re-implementing things like menus. I agree completely. I can add i18n, have them tracked in my app history, eliminate hidden state....using libraries of arbitrary React components often mixes in insanity.

doddenino16:01:05

Hi! Is it better to use om.dom or sablono?

levitanong17:01:45

@doddenino afaik om.dom supports server side rendering out of the box.

levitanong17:01:28

if you have no intention of rendering server side, it becomes a matter of taste.

doddenino17:01:53

@levitanong Nice, that's a pretty good reason to use it 馃檪

Joe R. Smith19:01:20

is there an idiomatic way to set initial queryparams when instantiating a om component from a factory?

Joe R. Smith19:01:15

disregard .. it wouldn鈥檛 have solved my problem

drcode22:01:04

@tony.kay I usually agree with the "just build it in cljs" philosophy, but lately I've been importing blueprint (http://blueprintjs.com/) into OmNext and I have to say there's something to be said for having a fully-baked component library at one's fingertips.

tony.kay22:01:36

@drcode thanks for the link. I do often wish for that for RAD. By import, what do you mean. I do have an HTML->react converter (in that second video I sent out recently). I still end up coding the behavior to avoid pulling in JS logic

tony.kay22:01:50

nvm...I see

tony.kay22:01:54

they are already React

tony.kay22:01:01

They look nice too

tony.kay22:01:04

out of curiosity, did you end up having to write a lot of foreign lib declarations? Or did you just generate a unoptimizable minified blob?

drcode22:01:05

For now I'm cheating: I "browserified" it with some dependencies, then load it before my cljs code in the html file, then have to do a bit of hacking to make sure multiple instances of react aren't loaded, and then wrote a cljs shimmy to access the relevant part of the js. (I realize I'll have to do something better for a real "release build" of my project, though performance isn't too critical for my use case)

drcode22:01:13

...but it works 馃檪

tony.kay22:01:59

I keep meaning to play more with the new module support in closure...have not had time

anmonteiro22:01:00

The world has changed 15 min ago. CLJS 1.9.456 can probably consume all those libraries

drcode22:01:19

@anmonteiro excited to try it!

tony.kay22:01:25

mmmmm. tasty

tony.kay22:01:45

documentation even! 馃槈

anmonteiro22:01:08

I want to try and drop the CLJSJS React dependencies for Om

anmonteiro22:01:19

DCE on React is my dream 馃槈

tony.kay22:01:34

Dude, this is like the biggest thing to hit cljs in a year

drcode22:01:44

Sweet snippet from the documentation... just write hello.js and then:

(:require [js.hello :as hello])

anmonteiro22:01:30

I have an Om branch consuming React

anmonteiro22:01:40

I wanna tweak it to consume React from node_modules now