This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-22
Channels
- # beginners (24)
- # boot (80)
- # braid-chat (11)
- # cider (89)
- # clara (11)
- # cljsfiddle (5)
- # cljsjs (9)
- # cljsrn (63)
- # clojure (114)
- # clojure-austin (1)
- # clojure-berlin (5)
- # clojure-brasil (4)
- # clojure-dusseldorf (5)
- # clojure-hamburg (17)
- # clojure-india (1)
- # clojure-new-zealand (3)
- # clojure-poland (1)
- # clojure-russia (91)
- # clojure-taiwan (1)
- # clojure-uk (54)
- # clojurebridge (3)
- # clojurescript (170)
- # core-matrix (1)
- # cursive (14)
- # datomic (8)
- # emacs (13)
- # hoplon (96)
- # immutant (20)
- # jobs (9)
- # jobs-rus (13)
- # kosmos (3)
- # off-topic (8)
- # om (111)
- # onyx (41)
- # parinfer (116)
- # pedestal (2)
- # proton (4)
- # re-frame (46)
- # reagent (7)
- # ring-swagger (24)
- # slack-help (2)
- # testing (1)
- # untangled (8)
Lighter.
And of course if you change the app-state, and it’s some data needed for an Om request, the relevant update will be done without your involvement
I get it, I won’t need to care about the reception of what I put into the channel. Om/react will handle the reloading if and when I update the app-state.
Hey guys, is Om.Next still considered alpha, and are there any known breaking changes coming down the pipe?
@erichmond: still considered alpha
thanks, that’s actually still really helpful. one last question, do you know how long it might be until it hits beta? I just need a rough rough answer in weeks or months or years? I’m asking because we are speccing out projects for 2016, and there’s a project that might be a good fit for Om Next coming in the next few months
I was thinking... you have to pass down (om/props this) down to the children components in order to access the queries. Isn't there a possibility to make this implicit? And then you could just have an arg to send down computed information
Or is it a bad idea per se for some reason? Maybe too much magic? I see this common pattern frequently in what I'm developing
You don't always want to pass everything to every child
@thiagofm a children components query can be dependent on the parent — e.g. [:todo/text :todo/completed?]
— which todo? Relay / Falcor address this differently than om though — the parents pass a pointer, not data, and the children query the store themselves vs getting it via props (similar to how an om component can get props directly on a reconcile)
[{[todo/by-id 1] (om/get-query Todo)} {[todo/by-id 2] (om/get-query Todo)}]
and Todo’s query is [:todo/text :todo/completed?]
I wish get-params could get the params of a component(such as om/get-params Component), like (om/get-query Component), but it can only get the params of the scope of the component, like (om/get-params this)
@thiagofm: why not use (om/params Component)
?
@anmonteiro: that is perfect, thanks!
The reason why I want this, is that I want to update-query in a children component, but there's no way to do that. So I'm writing my own abstraction in order to update the query of a children component from the root component
I think that sometimes it's worth stepping back and looking if what you want to do really makes sense
I want to create something like: (om/set-query-from-children Component key value), so I can just use it from the root
I'm not saying you're doing things wrong, but if you find yourself having to go out of your way to implement abstractions over stuff that should be simple, this might be a red flag
thiagofm: is this for routing?
My problem is the following, I have two components, the root one: Window and the children, called Code. Code displays a file which fetch via a remote in Github, but it's dependable on the :language state, so if the :language is "Ruby", it will fetch ruby code, for example. But I can't modify that query from the children component(set-query inside the Code component)
So I wrote something that lets me build the whole query inside the root component, getting it from the children
@thiagofm: you should be able to set-query!
inside a component
@anmonteiro: in a nested component, I get: Uncaught #error {:message "No queries exist for component path (haxlife.components.window/Window haxlife.components.code/Code)",
@thiagofm: that will happen if your queries are not correctly structured
@cmcfarlen: here you can find the window.cljs and code.cljs https://github.com/thiagofm/haxlife/tree/master/src/cljs/haxlife/components, and there the parser: https://github.com/thiagofm/haxlife/blob/master/src/cljs/haxlife/query.cljs It's kinda outdated from what I have now, but with the queries specified as it is there, I can't set-query! from the code.cljs component
@thiagofm: [(first (om/get-query code/Code))]
get-query adds metadata to the return value that is used later to determine which component that part of the query is associated with. Calling first will not work for you as it won't have the metadata. You will need to use a join to get Code's query. [{:code (om/get-query code/Code)}]
@cmcfarlen: let's see
what would be a good approach to debug/understand why a view isn't refreshed after a mutation? the write happens, and is followed by a read, and the read data contains the mutation changes - but the view isn't refreshed
@cmcfarlen: I have changed it to [{:code (om/get-query code/Code)}], but now it seems that it doesn't send the query params anymore to the read
I have at Window: (query [this] [{:code (om/get-query code/Code)}]) and at Code: (query [this] ['(:code {:query ?language})])
Hey can we do prop validation in Om Next like React did? https://facebook.github.io/react/docs/reusable-components.html#prop-validation
@thiagofm: Yeah, this adds more depth to the query. So now the params will be in the ast of the children. You can recursively call the parser on the ast children or you can dig in there from the first read call for :code
. Check out (-> env :ast :children)
in your read fn.
@thiagofm: check out the "Implementing Read" section on this page: https://awkay.github.io/om-tutorial/#!/om_tutorial.E_State_Reads_and_Parsing
@adamkowalski: factory
accepts a :validator
function that receives the component's props
@cmcfarlen: the ast will only contain the query from the current read? (I don't want to get issues with stealing other params)
awesome, that is exactly what I needed
@anmonteiro: whats the standard way of giving a user feedback if i don’t like the props
should I log a message, or throw an error, or just let the assert fail?
when the assert fails I get a really vague message by default: Uncaught Error: Assert failed: (validator props)
@cmcfarlen: works perfectly
@adamkowalski: I'd say that the validator
is not something to give feedback to users
not end users per se, but more of a sanity check for the developer
i would like to make my components reusable, and be able to share them with others. so if somebody fails to give me all the required props, or passes them in the wrong shape I would like to tell them what happened and how to fix it
yes, that would be the use case
right now I just throw an error that tells you the name of the component and the error message
I think the way React does it is by using invariants
whatever you end up choosing depends on what you want to happen
you can 1) hard error 2) log an error message (e.g. goog.log
)
I think the 1st will halt computation after the error is thrown, so that's where you have to choose
ok, and another alternative is to specify pre and post conditions right?
that would be a more clojureish way to specify invariants
so for a websocket component I require at minimum a url, and then for the pre condition I could check if the url is a string
so what would be the function body?
if you're just using pre/post conditions..
(defn- web-socket-prop-validator [{url :url}] {:pre [(string? url)]} true)
i just tried it and it worked great. when it fails it the source maps are good enough that it will point you to the line of code in the cljs file where it failed
otherwise you don’t even notice anything happened
Does anyone have any examples of how to model many-to-many relationships in Om next? Eg. Assuming I have Products and Tags, would I store the associated idents on both sides of the relationship or just on one side? Given that in the UI i’d like to display the tags for a product and also the products for a tag.
if you have both products for tags and tags for products it seems like on any change you would need to make updates to both things making your model more complicated
cant you model it with just products having tags associated with them?
then if you want to find which products have a certain tag, just filter through all your products keeping only the ones with the tag you want
you would get the same query ability just with less complexity
ok, so thats a vote for only storing links on one side of the relationship. Thanks
Let's say I read something from my remote based on a query(for example: language: Ruby), how do I save it to my app state?
@thiagofm: when you call the callback in your send function, the remote data gets merged into your app-state
So I would have to merge some part of the query with the remote data, and then posteriorly query the date using the query as some sort of index/key?
I don't understand your question, can you rephrase?
Let's say that sometimes I might query for "United States" or "Canada" in wikipedia. I would like to keep a cache of it. In order to do that, following your reasoning regarding the cb. I would have to return in the callback something like {"United States" wikipedia-response}. And whenever I do a read, I would have to verify if "United States" is there, otherwise I call the remote?
yes that should work
@thiagofm: have you heard of optimistic updates?
one thing you could do is when you originally make your transaction, place the data you need into your app state
then send a message to the server. which when it comes back with a reply can make a new transaction to override the data if needed
and for caching do the same thing but in reverse. if the value is already there then don’t ask the server
otherwise send a request and when it comes back transact it into your app state
@adamkowalski: luckily in this application I won't have to send data to backend, but this sounds like a good idea!
@adamkowalski: yet I don't think this can be used for everything 😞
how do you guys handle om components that don’t need to render anything?
is it fine if I just put (render [_] nil)
it seems like it just generates a no-script tag and wont bother anybody
also I cant make transactions if I dont have a query in the component
so I just did this static om/IQuery (query [this] [])
@adamkowalski: that's an anti-pattern
use om/computed
to pass callbacks down the component tree