Fork me on GitHub

Thanks @tony.kay those examples were really helpful


@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.


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


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


because it does not have co-located queries


nor will it be re-rendered by Om itself


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


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)


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


Om can then cache those for re-render


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


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


sure, happy to help


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


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...


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


Haha, sure, I realize that 馃檪


This is usually this in your component lifecycle methods..


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


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


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.


Is that necessary or avoidable?


@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.


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


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


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..


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


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


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.


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.


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.


But I see your point


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.


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


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


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.


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


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.


@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.


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


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


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


@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


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


@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


nvm...I see


they are already React


They look nice too


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?


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)


...but it works 馃檪


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


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


@anmonteiro excited to try it!


mmmmm. tasty


documentation even! 馃槈


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


DCE on React is my dream 馃槈


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


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

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


I have an Om branch consuming React


I wanna tweak it to consume React from node_modules now