Fork me on GitHub
#om
<
2015-10-21
>
drcode00:10:29

@tony.kay: What format would you like the feedback in? Don't want to spam the channel...

tony.kay00:10:11

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

drcode00:10:38

@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"?)

tony.kay00:10:30

Thanks. the doc is about 20% done simple_smile 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

drcode00:10:04

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")

drcode00:10:55

Yeah, I think the document is on the right track, should be quite useful when done

tony.kay00:10:08

Agreed. I'll add a mention to them early, but defer discussion till later

drcode03:10:14

OK, I think I understand most of om-next-demo now, except for this function

drcode03:10:24

(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))))))))})

drcode03:10:46

I don't understand (1) how the server knows the has been cleared, given that there's no ":remote true"

drcode03:10:12

(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?)

drcode03:10:33

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?

drcode03:10:46

If anyone has any pointers, I'd be grateful

dnolen03:10:56

@drcode the code just isn’t done

dnolen03:10:15

lots of server bits are missing because I’m busy with other things

drcode03:10:15

Ah ok, I'm jumping the gun then

drcode03:10:21

never mind

dnolen03:10:57

but the basic idea is there

drcode03:10:14

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.

tony.kay06:10:05

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

hmadelaine07:10:12

@tony.kay: great job ! thank you very much. Your document could be turned into DevCards

dvcrn08:10:45

what could be the reason that componentWillReceiveProps is not being executed on transact!?

dvcrn08:10:53

(render is receiving the new props just fine)

dvcrn08:10:35

could it be that it is because the component itself transacted?

dnolen11:10:25

@dvcrn: @anmonteiro: yeah a bunch of issues around life cycle methods that I’m working through today

tony.kay16:10:34

@hmadelaine: you volunteering??? 😉

tony.kay16:10:17

At the moment I don't want any overhead beyond writing as complete a guide as I can.

hmadelaine17:10:36

@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

dnolen17:10:10

@dvcrn: it may be that some life cycle methods don’t work with custom classes unknown

dnolen17:10:46

what are you using componentWillReceiveProps for? I never needed this myself

tony.kay17:10:49

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

zane17:10:29

Anyone have insight into how the :send key works on om/reconciler?

dnolen17:10:16

look at the om-next-demo github if you haven't

dnolen17:10:46

it’s just an arbitrary function that you write that takes 2 arguments

dnolen17:10:51

the query to send and a callback

dnolen17:10:57

do whatever you are going to do then invoke the callback

dnolen17:10:05

with the result

zane18:10:17

Okay. Thanks!

grav18:10:39

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

dnolen18:10:27

@grav how is it more useful than componentWillUpdate? (which I know will be called)

dnolen18:10:56

that’s an honest question

dnolen18:10:07

again I never ever found a case for the former

grav18:10:17

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

grav18:10:47

Whereas the docs encourages you to use setState in componentWillReceiveProps

grav18:10:07

So I guess I needed to update the component local state.

dnolen18:10:54

@grav right but that part of the docs doesn’t have anything to do with Om or Om Next

dnolen18:10:01

we don’t use React’s state mechanism

dnolen18:10:18

so my suspicion is that lifecycle method is a hack for a problem we don’t have

grav18:10:51

Hm, that I don’t understand. How’s component local state management in om/om next different from React’s setState()?

dnolen18:10:58

it’s completely different

dnolen18:10:07

we don’t use anything in React at all for this

dnolen18:10:38

all the logic for managing props and state in Om and Om Next has always been completely custom

dnolen18:10:22

we in fact have to often move props to state because Om / Om Next just doesn’t work like React

dnolen18:10:39

we treat React purely as rendering and DOM resource technology

dnolen18:10:32

not only is it completely different, it’s programmable

dnolen18:10:42

you can’t control component local state at all in React

dnolen18:10:47

it’s hard wired to their semantics

grav18:10:08

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 simple_smile My misunderstanding

dnolen18:10:46

so we def need to fix the lifecycle bits

dnolen18:10:56

but it may be that we don’t need the will receive props stuff

dnolen18:10:59

and we can doc that

grav18:10:42

Yup. I guess I can safely use om/set-state! from componentWillUpdate then?

grav18:10:17

Cause then my usage scenario won’t require componentWillReceiveProps, and you can disregard my initial comment 😉

dnolen18:10:41

the caveat being you need to be careful setting state in cWU

dnolen18:10:53

otherwise you’ll drop into an infinite rendering loop

dnolen18:10:05

we may need to reintroduce setting state w/o re-rendering, we’ll see

grav18:10:49

Ok. I was considering putting the state elsewhere, but using component local state means getting the clean-up for free when the component unmounts.

scriptor19:10:22

will there be any resources on things to watch for if you want to migrate from om to om.next?

dnolen19:10:26

@scriptor: it might appear eventually but that’s literally the last item on my list

dnolen19:10:39

I suspect it will take a couple of months before everyone is confident that what’s there works

dnolen19:10:56

then can think about feasibility of bridging

dnolen19:10:26

but I’m getting more and more skeptical as I go along

scriptor19:10:30

yeah, it's definitely more of a neat-to-have than anything

scriptor19:10:39

skeptical of bridging?

dnolen19:10:40

we may just continue to patch both libraries together

dnolen19:10:54

so both kinds of users may proceed w/o hassle

dnolen19:10:27

thanks to DCE there’s zero problems with this strategy

tony.kay21:10:44

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.

dnolen21:10:04

that or merge! still not clear yet

steveb8n21:10:02

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

dnolen21:10:22

@steveb8n: there’s only one me

dnolen21:10:36

if you’re impatient you’ll have to figure this stuff out on your own for now

dnolen21:10:43

or rely on the good will of others like @tony.kay

tony.kay21:10:00

I think he was suggesting we merge some of my docs into your wiki

dnolen21:10:16

the answer is “no"

dnolen21:10:43

when we get closer to beta and I have the attention span for it then “yes"

tony.kay21:10:55

I wasn't expecting to this early.

dnolen21:10:28

right I’m well aware there’s a mountain of stuff missing from the docs simple_smile

dnolen21:10:34

I don’t need more reminders

tony.kay21:10:51

feel free to ask for help

dnolen21:10:06

don’t worry, I’m very good at asking for help!

dnolen21:10:21

when I’m confident things are worth documenting people will be able to help away

steveb8n21:10:52

@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

steveb8n21:10:14

just expressing thanks to @tony.kay for the help

dnolen21:10:26

yes that’s understood

dnolen21:10:36

but I think everyone will have to sit tight for the next 4 weeks

dnolen21:10:49

while the bleeding edge gets poured into something more certain

steveb8n21:10:32

roger that simple_smile

tony.kay21:10:06

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

tord21:10:35

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

paxan21:10:36

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

dnolen21:10:10

@paxan: it’s not any different from doing any web app with Java

dnolen21:10:24

you just compile your ClojureScript to your JS resources and package up a JAR to deploy

paxan21:10:56

so need to use cljsbuild plugin, right?

dnolen21:10:52

you could write a bash script to do this

dnolen21:10:12

there are lein things for building uberwars I thought

dnolen21:10:20

this is really a general question for #C03S1L9DN