With Om Next it is the state that determines the UI, and the state is changed by mutations that are effected from clicks etc. It would seem sensible for the click to be listened to but not at the same time for the appearance of the UI to change. Is it possible to do this? A case where this simple approach would help is where there is an upper limit on the number of checkboxes that can be clicked. When the user has gone over the limit clicking should be ineffective. Just an example. It would be nice to know whether there is a solution for the general case.

click -> mutation -> state -> UI

rather than:

click/UI -> mutation -> state -> UI

cjmurphy: you could just store the number of clicked boxes in a path that's not rendered and then determine if you need to update the rendered state based on that

I'm not sure if om.next optimizes that avoidance of re-render for nested data though

Thanks Matt - sounds tricky thou! I have an actual solution to my specific problem, and that is to not allow a click (b/c component is disabled) in the first place when the max has been reached. This stays 'inside' Om (applies to the other frameworks too). My question is more of a Javascript problem. I wonder if it is even possible for UI changes to only be programmatic? It would be so easy if for example components were designed so that when you returned false from an event the component's UI did not change.

@cjmurphy: What would be the role of local state in such a model ?

sounds incredibly hard to debug 😄

I think you can always ask a component itself what its state is, so not need to keep that state elsewhere. I don't want to use local state. In this case it is important for other parts of the app to know what has been 'turned on'.

you could always keep two state graphs -> the rendered, and the 'real'

and then sync real to rendered when the relevant component returned 'true'

it just gets tricky if you have N components viewing a single state tree

I'm aiming for simplicity. It is the components that are 'at fault'.

@cjmurphy: are you looking for preventDefault? not sure I understand

How to write a query that says every field and a link [* [:link _]] ?

@tomjack: If the user clicks I don't want the tick mark to appear in the checkbox. I want Om-Next to effectively be putting that tick mark in. And I'm thinking that that's what everyone else would want too, for all components - as a general thing. I don't come from a js background so need to ask about things that might be quite obvious - like preventDefault. I'll look it up...

Thanks @tomjack - preventDefault seems like the right thing. I want absolutely nothing to happen - "I got the click - I'll (Om Next) will deal with the rest". I'll try it out a bit later...

I think maybe you could get what you want by :onChange (fn [e] (.preventDefault e))

onClick will not be enough for the people who check boxes with their keyboard

oh - I was using onClick for the checkbox, I'll try onChange then...

oh, I'm wrong, it seems

(I see my onClick hander being called when hitting the space bar on a checkbox..)

I like onClick being called when spacebar or mouse clicked on it - that's good - and that's enough too!

onClick seems like the event that is separated from the current state of the component, which is what I would like to use. There should only be one place where state is kept. If it happens to be kept in components it is best always ignored - which onClick does and onChange doesn't. So it is kind of good that keyboard events are caught by onClick as well. Of course maybe I'll then be relying on on a bug - a click is not a tap. If there's an onClick there should be an onTap.

well, wait, yeah, how about literally just :onChange (fn [e] (.preventDefault e)), but do what you want in other handlers?

It fully (recursively) denormalizes and you don't want it to. But that's what db->tree does. Apart from that I know nothing about union queries 😛

I am doing tree->db

@tomjack: I need to do the mutate as well. I can :onChange (fn [e] (.preventDefault e) (change-om-next-state)) I would think. Can't try it right now.

And you even have an ident on the comment.

https://facebook.github.io/react/docs/forms.html#potential-issues-with-checkboxes-and-radio-buttons

looks like I'm probably giving you bad information

in fact you don't need to do anything at all, it seems?

(dom/input #js {:type "checkbox" :checked true})

this checkbox already cannot be unchecked by the user?

I'm already doing that. When checked false the user can still change it to true.

(dom/input #js {:type    "checkbox"
                               :checked (when selected? " ")
                               :onClick (fn [] (pick-fn) false)})

use :checked true or :checked false

:checked nil means it's an 'uncontrolled component', apparently

Right yes I was just using a space

Just copied from Semantic UI examples.

Thanks - will try later - in middle refactoring. thanks..

Could the fact that the post doesn't have an ident cause the problem? I guess you thought of that..

I don't really understand that yet, but Post doesn't have Ident in the unions tutorial either

the Ident is on DashboardItem

(which makes more sense in the original tutorial..)

hmm, somehow an monteiro has it working here: http://anmonteiro.com/2016/01/exploration-patterns-om-next-part-1/

the composite's children in the init state in the source are recursively normalized correctly. must have screwed up my dashboard example

actually, they are normalized with the ... in the Composite query, but not with say [:id]. not sure if that's a bug?

@tomjack: changing :checked (when selected? " ") away from what it was didn't help - b/c the checking done by the css anyway. However what did work perfectly is (.preventDefault e) as the first thing the event does. I'm going to use this on every single Om Next event I write!

What’s the difference between shared-state and app-state in Om?

The app-state is shared, am I wrong?

Why do om components take two args data and owner all the time why? I can’t find this info in the docs.

I’m using Om now

cj murphy: I really think this is exactly what you want: https://facebook.github.io/react/docs/forms.html#controlled-components

there is no need for preventDefault

the second checkbox cannot be checked or unchecked unless the first is checked

and the first can only be checked because of the update-state!

I found that there is no upper limit on the number of check boxes that can be checked using this code:

(dom/div #js {:className (str "ui" (if selected? " checked " " ") "checkbox")}
           (dom/input #js {:type    "checkbox"
                           :checked selected?
                           :onClick (fn [e] #_(.preventDefault e) (pick-fn))})
           (dom/label nil ""))

Notice preventDefault commented out. Yet this one works:

(dom/div #js {:className (str "ui" (if selected? " checked " " ") "checkbox")}
               (dom/input #js {:type    "checkbox"
                               :checked selected?
                               :onClick (fn [e] (.preventDefault e) (pick-fn))})
               (dom/label nil ""))

I was always using 'controlled components' (first example), but it was not working.

can selected? be nil? i.e. does (boolean selected?) behave the same?

I just made it nil and could not select any (as expected) because nil is false.

I mean without the unnecessary (?) preventDefault 😛

if selected? is nil, the component will not be controlled

So comment out prevent default and make it nil - I'll try that.

comment out preventDefault, and use (boolean selected?)

if selected? is never nil currently, then I'm wrong

(well, if it's already either true or false exactly)

With that I can select as many as I like - no upper bound.

oh - boolean is a function - was not sure what that was

You are correct

With boolean function I don't need preventDefault

Thanks for your effort 😆😄

sure, sorry to have misled you to begin with

d'oh, my union example is busted, need to make :post/comments and :comments the same https://clojurians.slack.com/files/tomjack/F0SFT7XPZ/dashboard_dashboard_cljs.clj

works fine after that. and even adding likes nested in comments, also works. so it's a bug in my code

Do folks here use tree->db a lot to extract information from deeply nested data in mutations, do you tend to resolve links manually or do you extract the info in the components and pass down everything the mutation needs down as parameters?

I am a little undecided. I'm working with deeply nested/linked data a lot but tree->db seems such an expensive operation that wouldn't want to use it everywhere. My components on the other hand already have all links resolved into actual data via query joins but then I would like to avoid cluttering them with application logic.

@dnolen: React 15.0.0-rc.1 is up on CLJSJS, should we consider upgrading or wait for the actual 15 release?

I see.. in the dashboard union example, it is important that the DashboardItem ident matches the keys in the union map. This surprises me -- I was building a union where the different kinds of things all share a unique id space, giving them all matching idents, and had assumed the keys in the union map only mattered in my parser functions.

I was wondering how this could work; I guess it cannot. So you really must put 'union entities' into separate tables?

I guess I was imagining 'non-deterministic unions' where choosing the union entry is left up to parser functions, and the union'd parts of the data would always be normalized with respect to all the different union queries

something like: normalization takes the values in the union expr map, catvec's them, applies merge-joins, and uses that as the query to normalize

@anmonteiro: I would rather wait - but also would like to hear if there’s any breakage

@anmonteiro: thanks for rebasing the PR will take a look later today

@dnolen: OK I'll try it out locally when I have time and let you know

@dnolen: I have 2 or 3 things I'd like to run by you if you have 2 minutes

@anmonteiro: will have to be a little later in the day for me

@dnolen: I'll just write the questions and you answer whenever you can

1. would you be open to a PR making om.next.protocols CLJC ?

@anmonteiro: k

2. can I work on #398 (normalization available server-side)? I was thinking about a om.next.impl.db namespace that both om.next and om.next.server would require

(this would be quite easy to do once the PR with the helpers in om.util is merged)

Anyone have a few minutes to explain what No queries exist for component path (om-frontend.quest/RootView om-frontend.quest/Card om-frontend.quest/OptionElement) means? I get this whenever I attempt to run a mutation. I’m structuring an small app in devcards which is like a choose your own adventure, where the top level of the app state has :cards and :current-card keys. :cards is a list of items containing an identifier, text and choices. A :current-card is a card identifier. I’m rendering the :current-card correctly with buttons for the options, but when I try to select the option, triggering a transact to change the :current-card, I get the message above. Any ideas what I’m doing wrong?

@folcon: if you share your queries for those 3 mentioned components I'm happy to take a look

I don't need the whole defui stuff, just the IQuery implementation

sure

thank you

;OptionElement
static om/IQuery
  (query [this]
    '[:current-card])

;Card
  static om/IQuery
  (query [this]
    '[:name :header :description :options])

;RootView
static om/IQuery
  (query [this]
    (let [subquery (om/get-query Card)]
     `[{:cards ~subquery} {:current-card [:current-card]}]))

@folcon: your problem is right there

queries must compose to the root with get-query

there's no way that Om knows the path from the root until OptionElement

as in RootView should also have a get-query call to OptionElement?

exactly

I'm not sure about the structure of your UI, but if OptionElement is a child of Card, then the get-query OptionElement should be in the Card component

ok, so Card contains an OptionView element, which contains a OptionElement

does it matter that it’s skipped as OptionView contains no query

no problem there

hmm, I’m now getting an invalid join. I think I should normalise the option elements by some identifier in the same way I’m doing cards. That could be a problem as there are supposed to be duplicate option elements

is there no way to manage the option elements other than by giving them an unique identifier?

hmm, ok the invalid join is gone, but I’m now back to the no queries exist problem… Part of the issue may be that I’m using a mixture of flat and list data, simplified:

(def init-data
  {:current-card :start
   :cards [{:name :start
            ...
            :options [{:goto :stay-at-home :text “Stay"}]}
           {:name :stay-at-home
           ...
            :options [{:goto :nearest-village :text “Go to next village"}
                      {:goto :stop}]}
           {:name :nearest-village
           ...
            :options [{:goto :stay-at-home :text “Return"}]}
           {:name :stop}]})

@folcon: you can always use idents

instead of keyword placeholders

but for idents to work, I need to have a defined part of my data that I know is unique right? But the options above may not have unique parts (the goto attribute + the text maybe unique). Would I need to manage it myself?

yes

ok, thanks I’ll try and work out how to manage that ...

why does om.next recalculate props after a call to set-state!, which just touches component local state? The app state shouldn’t have changed, so why parse again? Is there something I’m missing?

@anmonteiro I upgraded Om.next to React 15 in my local copy, seems to work without any problems for the moment...

@iwankaramazow: cool! thanks for the feedback

I wanna try a few things out myself too

namely the absence of data-reactids

and several text nodes as the children of a component which are not mapped to <span>s anymore

the rendered html looks pretty clean without those data-reactid

also curious whether renderToString still has a data-reactchecksum

my guess is yes

I honestly have no idea how they would do it without one

agreed

could probably be done, just very slow

Yea performance is still the bottleneck

i’m trying to perform a remote mutation along with a query to read after the mutation has run. is it possible for the query to use the mutation’s result as a parameter?

with something like (om/transact! this ‘[(document/update) :document/text], I’d like the :document/text query to use the (document/update)’s value

@bostonou: you could maybe implement something yourself to make that work - but there’s nothing about the query syntax that would signal something like that

ok thanks

@dnolen does my question make sense as something that should be done? my struggle so far with om/next has mainly been with questions like this, e.g. I can implement something myself, but i wonder if i’m missing some design goal/approach

@bostonou: I could see why you might want to do that yes

cool. fyi, i’m checking out om/next for potentially moving to it. some really good stuff so far

Hi everyone! I finally moved from Om to Om Next and while setting things up I keep getting message 'TypeError: ReactDOM is undefined'. Is that some known problem or is it all my fault?

@whythat: you may be seeing an old version of react

@whythat: if you're using sablono you might need to also require om.dom

@anmonteiro: I do require it, and still nothing

@whythat: what version of Om are you using?

So far I've tried 1.0.0-alpha22 (as in GitHub guide), and also -alpha30 and -alpha31

@whythat: I would check lein deps :tree at the root of your project and see if React is not being overridden somewhere

also make sure to clean builds etc

@whythat @anmonteiro : I had the same problem once, an old version of React was being pulled by another dependency, lein deps :tree, showed the problem. Moving the om to the top of the :dependencies vector fixed-it.

it's definitely better to use :exclusions than to rely on the dependencies order

@anmonteiro: well, it turned out that I was using old version of sablono which used react 13 while Om required 14, so that seems to be the problem. Thanks a lot.

@anmonteiro: Thanks for the tip

for working with om next on devcards is there an explicit render step that needs to be taken?

I’ve managed to get it to work, but the cards weren’t updating, then I just discovered that you can select an individual card to load it. If I make a transaction that I would expect to update the devcard, it doesn’t update. After selecting a devcard to load it and pressing back, it suddenly works… this is a little puzzling.

Folsom: might double check the checklist for writing figwheel compat code.. There are some def/defonce gotchas