Fork me on GitHub
#om
<
2016-01-04
>
andrewboltachev00:01:35

Hi. If I have an input, some validation function (which receives value and provides either error message or nil) a submit button in Om Next app and I want (1) validate data as user types it (but not display the error message when the form is just untouched, "pristine"), and as a result make input's border red and display this error msg and (2) submit the data when the form is valid (i.e. transact! it), should my "local" data for current value of input go to app's state (i.e. I should transact! it too), or should I rather introduce some "local" state for such a small piece of functionality?

steveb8n00:01:07

@smeister: you might find the “controller” idea in my ideas project relevant to your thoughts on keeping the view layer clean. I had the same observation so a controller is one way to address it

drusellers00:01:27

is there any kind of rough thinking on how Om-Next is progressing

drusellers00:01:41

aka when are thinking it would release - 2016 / 2017

andrewboltachev00:01:35

Adding to @drusellers question: How different Om Next is from Relay + GraphQL? I.e. what it's providing what Realy + GraphQL doesn't (except caching) and vice-versa?

andrewboltachev01:01:54

Though, I can answer that questions myself also, if I'll dig into that tools. Being bleeding-edge, and solving a lot of problems in "battaries-included way", Om tools require non-trivial effort to get into them. What a challenge simple_smile How many time did it take for you guys to study, say, Om, based on beginner React and CLJS knowledge?

locks01:01:45

for the relay/graphql one

adammiller02:01:36

@andrewboltachev: regarding your earlier question you could use local component state or app state…up to you, some like to avoid using local component state altogether. You don’t need to introduce any state though, as React components have local state (accessible via the component state methods https://github.com/omcljs/om/wiki/Documentation-(om.next)#set-state)

adammiller02:01:25

@drusellers: I believe David had said earlier that he thought there would be beta release around Feb/Mar

smeister06:01:27

@steveb8n: i don't quite understand - isn't what i tried supposed to work? Could you clarify?

steveb8n07:01:29

@smeister: yep, if you have a solution that’s good but you had a thread going with David about keeping transact! details out of the view code. fwiw that’s what you can see here https://github.com/stevebuik/om-next-ideas/blob/73e22ec9cab12d0caded6b012d74b80c14a9d1a2/src/cljs/om_next_ideas/app/views.cljs#L28

smeister08:01:47

@steveb8n: thanks, i understand. I thought you would refer to my most recent problem (https://gist.github.com/SMeister/df825c11e958a26e741e)

janherich10:01:24

@smeister: i tried to provide you an explanation for your problem: https://gist.github.com/SMeister/df825c11e958a26e741e

smeister10:01:14

@janherich: the query passed to the read method for :item should be exactly [:ui/menus]. Where is the problem then? db->tree (i could also just use get here - makes no difference) reads the top level key and the parser gives me back the result nested correctly. The toplevel read was not meant to be called - it was just for illustration purposes.

smeister10:01:48

My problem is that the re-render is successful only when i specify :ui/menus inside of the root query and i have no idea why. Initial rendering would not work if what you suggested were true, but it does.

smeister10:01:59

Updated gist

anmonteiro12:01:51

@smeister: your problem is simply resolved by specifying the keys to re-read after transact!

anmonteiro12:01:55

#(om/transact! this '[(open) :ui/menus])

smeister12:01:04

@anmonteiro: thanks! Now it works, but i am a bit confused. Why do i need to specify this inside of the subcomponent? I thought transacting on something would lead to a re-read of all keys in it's query. Also, why does specifying the key in the subcomponent's tx influence what happens after the root's tx?

anmonteiro12:01:43

@smeister: not really sure about the first question

anmonteiro12:01:01

but it might be related to the sequence of txns

anmonteiro12:01:51

" Also, why does specifying the key in the subcomponent's tx influence what happens after the root's tx?" because it also queues the child component to be re-rendered, and not only the root

anmonteiro12:01:56

@smeister: OK, so here's something else I found out

anmonteiro12:01:20

if your app state has the same structure of the queries

anmonteiro12:01:24

(which it doesn't in your gist)

anmonteiro12:01:36

then you don't need to specify :ui/menus to be re-read

anmonteiro12:01:54

to clarify: your app-state should look like the following

anmonteiro12:01:14

{:item {:ui/menus false}}

smeister12:01:54

hmm :ui/menus is something meant to be global in my app

anmonteiro13:01:12

what I said is a misstatement

anmonteiro13:01:21

I was still looking at a cached version

anmonteiro13:01:25

give me one sec

anmonteiro13:01:49

@smeister: so I take back what I said before, but your example is quite messed up to begin with

anmonteiro13:01:05

you define a read method for :item but you're actually reading :ui/menus there

anmonteiro13:01:39

anyway, to make it work you just need to specify :ui/menus after the call to open

anmonteiro13:01:45

not even needed in close

smeister13:01:30

What else should i define a read method for?

anmonteiro13:01:25

the problem is that your app state doesn't match your queries

anmonteiro13:01:48

also not sure why you're using db->tree since in this example you could just return st

smeister13:01:15

sure, i did not replace it as the example was the trimmed down version of something bigger

anmonteiro13:01:32

@smeister: ok that makes sense

anmonteiro13:01:46

I've got to run now, but if you still have any questions maybe I can attend to them later

smeister13:01:57

ok. thanks.

andrewboltachev14:01:32

Hi. A newbie question: how do I start that app? https://github.com/swannodette/om-next-demo I've done just lein repl and then

user=>   (require '[todomvc.core :as cc])
nil
user=> 

user=>   (cc/dev-start)
#<SystemMap>
user=> 

I can see the HTML page, some items but when I perform actions I've got a lot of 500 errors like
HTTP ERROR: 500

Problem accessing /api. Reason:

    java.lang.Exception: Not supported: class java.util.concurrent.ExecutionException
(but some of AJAX calls are successful, which is even more strange)

dnolen14:01:41

@andrewboltachev: om-next-demo in it’s current state is not something to try and run yourself unless you are a very experienced Clojure(Script) dev

dnolen14:01:16

no intention of bringing it up-to-date on my end until more important Om stuff is sorted out

andrewboltachev14:01:28

@dnolen: got it. I'll try to dig into it myself then. Thanks

hkjels15:01:30

@dnolen: I think you should mention that in the Readme

dnolen15:01:27

@hkjels: yes I might, but not high priority for me

smeister16:01:25

Still don't get why i have to specify :ui/menus to be re-read in the subcomponent in https://gist.github.com/SMeister/df825c11e958a26e741e. Several people have told me now that it's because my app state does not mirror the queries structurally, but isn't the structure up to my interpretation?

denik16:01:29

in om.next how can one disable printing transaction logs? At least temporarily. I have a huge logs that when printed slow down my app.

smeister16:01:59

@denik i didn't try it out, but i think you can use the logger option for the reconciler to pass in something else, e.g. a logger which doesn't log at all. https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L1647

anmonteiro16:01:08

@denik: simply pass :logger nil to the reconciler

denik17:01:00

@smeister: @anmonteiro Thanks that worked!

akiel19:01:35

Is it possible to do a set-query! after a transact!? Background: I create something through mutations and after that my router likes to go there. My router works by changing the query of the root component which I can’t do in transact!. Oh and it doesn't work by just calling set-query! after transact! but it works by defering the second call.

anmonteiro20:01:46

@maackle: wrt. issue #554, the query you're looking for is [({:message [:text]} {:size ?size})]

maackle20:01:03

my apologies, it was just bad grammar

maackle21:01:39

and you're right, when the query is constructed properly, render happens

peeja22:01:14

Am I correct that there's no stable release of Om that uses React 0.14?

peeja22:01:31

and therefore no stable release of Om that works with Devcards?

anmonteiro22:01:08

I think the latest release of it was 0.9.0, which is under react 0.13.3

peeja22:01:16

Yeah, that's what I'm seeing

peeja22:01:35

Which means no ReactDOM, which means no Devcards, if I'm reading this right

anmonteiro22:01:24

I think you can use an older version of Devcards?

peeja22:01:43

Oh, sweet, looks like you're right

peeja22:01:57

0.2.1 uses 0.13

drusellers22:01:26

I’m assuming this is more than I could probably tackle but how hard would it be to make the Om data structures compatible with core.reducers ala https://github.com/nathanmarz/specter/issues/46#issuecomment-168837093

anmonteiro23:01:59

following the discussion around issue #554 and general confusion about Om Next queries, I wrote something: https://twitter.com/anmonteiro90/status/684148857547165697

dnolen23:01:51

@tony.kay: need a rebase on the recursion limit enhancement PR

dnolen23:01:07

after applying @anmonteiro’s fix for unions + recursion

tony.kay23:01:10

ok...application order?

anmonteiro23:01:10

@dnolen: regarding #550, as @tony.kay mentioned, using devcards' dom-node with add-root! works for me

dnolen23:01:27

@anmonteiro: do you have example of this somewhere?

tony.kay23:01:16

Since devcards dom-node generates a dom node, seems to work just fine as the target

tony.kay23:01:32

fixes the fact that react elements don't work as root

anmonteiro23:01:37

(defcard x-card
  (dom-node (fn [_ dom-node]
              (om/add-root! x-reconciler Component dom-node))))

anmonteiro23:01:51

@dnolen: if you just don't have the time, I can work on the boring task of removing mock-root and updating all devcards examples

anmonteiro23:01:05

while you employ your time to something useful simple_smile

dnolen23:01:07

yeah I’m definitely happy to see mock-root go - it’s been an annoying thing to support

dnolen23:01:18

@anmonteiro: haha, sure if you want to take it - it should be pretty quick one

anmonteiro23:01:54

give me some minutes

anmonteiro23:01:12

I'll be sure to add the dom-node example to the commit message

anmonteiro23:01:19

@dnolen: I'll submit it as a fix for #550, is that OK?

tony.kay23:01:47

@anmonteiro: You have time to chat over your patch real quick?

tony.kay23:01:34

line 1251 on the right should be highlighted

tony.kay23:01:53

trying to decide if that reduce query depth should wrap the entire expression or just the query

tony.kay23:01:13

basically, where is the '..., which in the limit case will be a number instead

tony.kay23:01:36

the reduce query depth rewrites the query to be one less

anmonteiro23:01:48

@tony.kay: I'd say it looks okay

tony.kay23:01:02

so the union seen is not the part that has the ... in it?

anmonteiro23:01:07

it wouldn't find '... in union-seen

tony.kay23:01:14

rather, entry

tony.kay23:01:28

ok, so it is right as shown

anmonteiro23:01:36

union-entry will contain e.g. {:tree/foo [:id :node/type :foo/value {:children ...}], :tree/bar [:id :node/type :bar/value {:children ...}]}

tony.kay23:01:50

@dnolen: I did the rebase, all tests pass, and @anmonteiro and I agree that the conflict fix is correct with respect to our two patches.

anmonteiro23:01:08

@tony.kay: if we wanna be sure

anmonteiro23:01:20

add a number to my example in om.devcards.bugs ns

anmonteiro23:01:49

rather, in om.next.tests `

anmonteiro23:01:14

search for e.g. UnionFooNode

anmonteiro23:01:20

& re-run tests

tony.kay23:01:30

Sure, let me do that. I was trying to grok what you were recording in the union-seen

tony.kay23:01:35

just so I didn't have to trace it

anmonteiro23:01:55

@tony.kay: I record the last seen union-entry so that when there's recursion it can decide which way to go

tony.kay23:01:19

hm...something just went wrong...

tony.kay23:01:31

Give me a few mins...

tony.kay23:01:37

unrelated to testing that

tony.kay23:01:37

ok, remembering to clean helps. @anmonteiro Yeah, I've verified the numbers work with I mess with your tests.

anmonteiro23:01:09

you mean "when you mess" or I didn't understand??

tony.kay23:01:45

when I change ... to 0, it causes test to fail

tony.kay23:01:50

when I change it to 1, pass

tony.kay23:01:54

back to ... pass

tony.kay23:01:53

as expected

anmonteiro23:01:13

@tony.kay: where is it failing when you pass 0?

anmonteiro23:01:26

in my union stuff?

tony.kay23:01:30

when I pass 0, it is supposed to fail

tony.kay23:01:35

it does not recurse then simple_smile

tony.kay23:01:50

yes, perfect