This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-10-21
Channels
- # admin-announcements (42)
- # alda (1)
- # beginners (11)
- # boot (24)
- # boulder-clojurians (2)
- # cider (10)
- # cljs-dev (23)
- # clojure (63)
- # clojure-czech (4)
- # clojure-japan (2)
- # clojure-russia (44)
- # clojure-sg (2)
- # clojure-switzerland (2)
- # clojurescript (135)
- # community-development (5)
- # css (4)
- # cursive (19)
- # datomic (34)
- # emacs (2)
- # events (5)
- # funcool (13)
- # hoplon (3)
- # ldnclj (43)
- # ldnproclodo (1)
- # lein-figwheel (7)
- # luminus (7)
- # off-topic (54)
- # om (115)
- # onyx (82)
- # overtone (3)
- # re-frame (6)
- # reagent (15)
- # yada (5)
@tony.kay: What format would you like the feedback in? Don't want to spam the channel...
you can direct IM me, or pull request. I'm editing pretty heavily at the moment, so private IM with links to current push line number on GH would be nice
@tony.kay: My comments ended up short, so I'm posting them: I found your Overview a helpful read, clarified some confusion I was having! I didn't find any errors on first read. The main comment I have is that a section at the beginning defining prop, param, and selector in this context would be a great addition (also, how do these ideas relate to om/IQueryParams and is there a connection with React "props"?)
Thanks. the doc is about 20% done The relation to IQuery, IQueryParams, and React comes a bit later. Starting with how to write the parser and understanding the query grammar seems foundational
sounds good to discuss that later- a bit more exposition on "prop+params" seems to make sense though (since you go into some detail on "join+selector")
(defmethod mutate 'todos/clear
[{:keys [state]} _ _]
{:action
(fn []
(let [st @state]
(swap! state update-in [:todos/list]
(fn [list]
(into []
(remove #(get-in st (conj % :todo/completed))))))))})
I don't understand (1) how the server knows the has been cleared, given that there's no ":remote true"
(Is the mutation on the atom somehow triggering a server call? Or, is there some reason why the server doesn't need to know about "cleared" items?)
Also, I have to admit (2) I can't make sense of the transducer usage at (remove...) what is going on here? How does that work, given that the "list" variable is not being referenced?
Yes, I feel like I'm over the hump now and can proceed trying some of these ideas in a project without any significant stumbling blocks. Thanks everyone.
Up to pg 14 on docs. Running into a few little things I don't quite understand, so anyone who cares to try to help, please search for "HELP:". https://github.com/awkay/om-wiki-fork/blob/master/Om-Next-Overview.md
@tony.kay: great job ! thank you very much. Your document could be turned into DevCards
what could be the reason that componentWillReceiveProps
is not being executed on transact!
?
@dvcrn: think it's related to this? https://github.com/omcljs/om/issues/431
@dvcrn: @anmonteiro: yeah a bunch of issues around life cycle methods that I’m working through today
@hmadelaine: you volunteering??? 😉
At the moment I don't want any overhead beyond writing as complete a guide as I can.
@tony.kay: I started this morning 😉 I have to dig deeper into DevCards but It could be useful. I will let you know ! Keep up the good work
sweet! Thanks. I'm studying the mutation story at the moment. I know David is still working out some the details on that...so part of my task at the moment is to cover the cases that are known, and kinda hand wave at the cases that are coming
@dnolen: I’ve used componentWillReceiveProps
to calculate the differences between the previous state and the new state, in order to synchronize a wrapped DOM object (a Google Maps canvas) with the state of its React wrapper component.
From the docs (`componentWillUpdate`): “Note: You cannot use this.setState() in this method. If you need to update state in response to a prop change, use componentWillReceiveProps instead."
Hm, that I don’t understand. How’s component local state management in om/om next different from React’s setState()?
all the logic for managing props and state in Om and Om Next has always been completely custom
we in fact have to often move props to state because Om / Om Next just doesn’t work like React
Ah, ok, I actually thought you went and called the setState() method on the component, but I see from the source that’s not the case My misunderstanding
Cause then my usage scenario won’t require componentWillReceiveProps
, and you can disregard my initial comment 😉
Ok. I was considering putting the state elsewhere, but using component local state means getting the clean-up for free when the component unmounts.
will there be any resources on things to watch for if you want to migrate from om to om.next?
I suspect it will take a couple of months before everyone is confident that what’s there works
Quick check of understanding: (transact! reconciler ...) is what I want if I've done a server push (e.g. from a websocket) and want to change app state.
@tony.kay: thanks very much for the wiki fork. The query summaries immediately helped me in building my parser server. @dnolen that section (at least) will be valuable in the docs.
@dnolen: it was not a commentary on the quality of the existing docs, just a suggestion fore the future. I understand you have lots to do and am grateful for your efforts
FYI: The Om Overview doc I'm writing has been moved into my fork so the links and such format correctly: https://github.com/awkay/om/wiki/Om-Next-Overview I'll add links from the wiki Home as well. https://github.com/awkay/om/wiki
@dnolen: Sorry, you can't fool us. Of course there's more than one you; there is no way a single person could do all that work.
Is there an explanation somewhere that shows how to package up an om.next app into an standalone jar, runnable as:
java -cp path/to/app.jar ... args ...
?