is om development being phased out?

replaced by om next?

No new features but it will be maintained for foreseeable future

And when things settle down the feasibility of bridging will be investigated

I'm experimenting with :remotes and :send. The autocomplete example helpfully demonstrates a simple example and is my reference point for this question. In that example, both the read and send function coordinate about where data will live which is the :search/results key in the state.

That effectively hard codes the send function. It has no context which would allow it to respond to requests and put data in other locations.

I guess you could hash the query and use that as a key but I suspect there are more elegant approaches.

So, direct question, what would you change to make the AutoCompleter suitable for use multiple times on a page?

@olivergeorge: You could give AutoCompleter an ident and change your parsing code to recursively call the parser for the data for each AutoCompleter in your app. I think there is a tension between creating truly reusable components (which probably dont have their own queries) and components that are reusable within your application but are tied to your applications specific parser implementations

Hey @dnolen just wondering is there plans to support the ReactDOMServer.renderToStaticMarkup Would be awesome to be able to build static sites for clients in Om and simply add the backend whenever it becomes necessary.

@grounded_sage: can't you already use that function?

Does anyone have a pointer on what {:keyfn …} as arg to om/factory is used for?

@mudphone: it’s used to compute a react key from a the props passed to a component, e.g. if you are rendering a list of contacts you might return the contact’s id for the key

@mudphone: docs: "Can optionally supply :keyfn - this should produce the React key property from the component props."

ah, okay, should have looked there… was looking at source

Thank you!

@sander: docs say Equivalent to React.renderComponentToString. For example

@grounded_sage: tried (js/ReactDOMServer.renderToStaticMarkup my-component)?

I haven't actually built anything yet. Just been reading docs etc. print screening for future reference

@dnolen: regarding the problem with the compiled version from Nov. 27th. After cleaning the output directory and recompiling the cljs, it’s working. Maybe some intereference with the development files.

Anyone know why mutation of app state would not cause a re-render of a component on the first mutation? But would cause re-render on subsequent mutates? I can see that my @reconciler state is changing, but the re-render isn’t triggered. It works fine if I use an atom (and so, no indexer). But, when I switch to handing a non-atom, it doesn’t re-render on the first mutate.

btw - I’m quite tired of converting cljs maps to js all the time dom/div #js {….}. Wouldn’t it be useful to extend dom/[NodeName] functions and apply this transformation automatically during runtime?

You can use other react dom generation libraries to get that syntax. Checkout https://github.com/weavejester/flupot for dom/[NodeName] style or https://github.com/r0man/sablono for hiccup style [:div.foo {:on-click #(println “hiccup style”)}]

@mudphone: I wasn't aware that non-atoms were supported. I'd imagined that Om uses the Clojure facility to watch for changes to the atom.

@johanatan: sorry, I guess I should have asked in #C0DT1AZD3

@mudphone: Is there some difference between the two in this respect? What facility of Clojure will Om Next be using to 'watch' random (non-referency) things?

@noonian: Thanks!

@johanatan: I’m new to this, so take with a grain of salt… Om Next has a reconciler which you can pass an atom or non-atom. If you use an atom, it doesn’t normalize the data.

@mudphone: ya, I just considered that part of my Om Next template to be boilerplate lol: I only plan to have one component and one atom.

[Everything else is happening within those]

@johanatan: ah, I see. Well, looks like more debugging is required on my end.

the query in Project is specified as [:project/id :project/title {'[:project/current _] [:project/id]}]

Thanks @noonian, I'm looking into that now. I can see that having an ident gives the read function :query-root (the ident) in the env and also the :query. The ident would identify a sensible unique path to keep a component's state. Not sure how that helps regarding the send function's callback. Unless merge! uses the query-root / ident as the starting point for the merge. I can't see that from a code skim.

Whats the om way of thinking about input type range? Suddenly there's this element in the dom that get's to call the shots about things.

Or is it just a question doing the element.value and putting that where it goes?

@chedgren I don’t think it is much different, e.g using a Slider control, than the auto suggest example https://github.com/omcljs/om/wiki/Remote-Synchronization-Tutorial#building-a-simple-auto-completion-widget. Om can use things like core async to “tame” the controls behaviour!

@griffio: thanks:D

So it seems to me, that in om , in the second argument to a component, you can pass in :state, init-state or opts. ie (om/build my-component data {:state {:my-foo “foo”} :init-state {:my-bar “bar”}, :opts {:my-foo-bar “fubar"}})

is this right? and does init-state clobber or override the init-state function if the component has one?

(Om Now) override, you can give state from outside

that probably won’t come back in Om Next

interesting

@olivergeorge: I’d checkout the thinking in links tutorial. You will have to change your queries a little bit but if you give each autocompleter a unique ident based on its props, you can use Om’s tree->db function to see how Om will normalize your initial data. I’d imagine you’d have something like a list of “ident”s at the :app/searches key or something and your client side parser would pull those out, filter by the proper id from your parameterized search, and call the parser again (also in remote mode) so that each autocompleters :search/results query will be parsed.

@tony.kay: I added some cosmetic feedback about OM-507 before I take the PR. Thanks for working on this one.

I think there is a minor typo in the Person component of the Components, Identity, and Normalization tutorial.

In the line (let [{:keys [points name foo] :as props} (om/props this)] I don't think there's any reason foo should be in there

@dnolen: OK. I'll look at it. Welcome...yeah, both of those took some work...bout half the weekend

@tony.kay: I’m also more than happy to pull and do that myself

I just didn’t want to stomp on what you’d done

I don't mind learning the style you prefer...and the alg tips are appreciated

Only been doing clojure for 6 mos...so still learning the cool tricks

@codonnell: feel free to fix that

@tony.kay: k just let me know what you’d rather prefer

it would probably be easier to take your PR and see my edits afterwards

but again I’m not picky at all here

ok..well, I do have 8 guys I'm training, and I would like the bug fix...so if you don't mind I'd appreciate it.

I will definitely look at the changes

@dnolen: scratch that if you've not already done it...It's just 3 changes and I'm already there.

cool ok

@dnolen: take a look and see if I got them all (I got fnil, but I only found delim problems in the test).