This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-10-23
Channels
- # announcements (1)
- # aws (11)
- # beginners (28)
- # boot (235)
- # business (1)
- # cider (19)
- # clojure (34)
- # clojure-china (1)
- # clojure-czech (10)
- # clojure-japan (7)
- # clojure-poland (3)
- # clojure-russia (84)
- # clojure-sg (4)
- # clojure-uk (3)
- # clojurescript (114)
- # community-development (4)
- # core-async (15)
- # cursive (8)
- # datascript (5)
- # datomic (6)
- # editors-rus (27)
- # events (2)
- # hoplon (61)
- # jobs (2)
- # ldnclj (56)
- # ldnproclodo (5)
- # lein-figwheel (232)
- # luminus (1)
- # off-topic (5)
- # om (215)
- # onyx (436)
- # overtone (8)
- # re-frame (3)
- # reagent (3)
I just pushed a dynamic query example doc...it is quite incomplete, but it has a working example to look at. Embeds query fragments with query params. https://github.com/awkay/om/wiki/Om-Next-Dynamic-Queries
@dnolen: I just read the source change. Sweet! This is just what I needed to clean up my example code!
@a.espolov: Upgrade versions…try alpha4. He fixed a bug in it recently
Something changed... now, a single-page-app router only needs to do some data fetching/change. When the data is changed -> the UI will display the correct view for it.
Of course it was possible before om.next, but now it seems to be very easy/natural to do so. Until this point, you would need a bunch of logic and data-fetching in the parent component if you would make this kind of data-centric routing. In my case it resulted in a lot of data fetching and core.match - now, this code is gone.
@dnolen: what is the story about defaults in queries? Is ist possible to use the datomic default function? and what about the maps, how would you add a default for the case that no data is loaded?
@thomasdeutsch: there isn’t any need for default case beyond syntactic sugar
you may want to bottom out at Datomic Pull somewhere in your query so the only is that it should work
@thomasdeutsch: for the case where no data is loaded just supply the data you want to show at startup
@thomasdeutsch: glad to hear you seeing the benefits of the simplication
fwiw, I think you’re going to see a lot of code disappear and the result will be something very uniform and very easy to reason about.
Hey all, is there any way to view what changes trigger an update on a specific component?
@gardnervickers: changes don’t trigger updates
the main exceptions at the moment is that we schedule the component that requested a transaction for updates
set-params!
and set-query!
as well, but again this only applies to the component that invoked these things.
Ok that’s a lot less involved than I assumed.
over the coming months people will start to realize that Om Next doesn’t do anything at all
^^ amaze
if Om Next doesn't do anything, what have you been doing all this time?
@bostonaholic: haha, I just mean all the code there is just for managing the co-located queries and giving everyone a parsing infrastructure.
but there’s no magic, you have to write all the parsing code, all the state management, all the re-rendering triggers etc.
no, I get it. I love that mentality
after writing apps in backbone, ember, angular, (and probably more) I agree with that
I'm with you guys, using Om.next really feels something different, I've being writing one app using Falcor recently, and knowing Om.next I'm missing the colocation and parsing management, I'm having to do a lot of it by myself (in a very crude way), that makes me really appreciate your work on Om.next @dnolen
@wilkerlucio: haha, oh yeah. I mean I really, really read through the Falcor docs
We’re much more like Relay in that regard, but Relay is just a OOP disaster implementation API wise
I am also writing an app using falcor, and redux and find everything said about om next very enlightening
I am actually re-writing http://data.worldbank.org. We can possibly open up the api and document it well so others can have a go at it. I think I will have a look this weekend at if I can integrate om next with falcor.
@dnolen: also when I first read your docs about the indexer, that made me feel pretty good, we had those indexing powers for ages with jQuery and they got lost when the MVC'ish frameworks started to pop, and finally the Om.next reconciler, oh my, that's the kind of code that I'm very glad I'll not have to write, so thanks again, following the Om.next development is being a great experience, I can barely wait to start using it on real apps
@wilkerlucio: yeah, still not sure what the indexer means for production - but from a tooling perspective I have some big ideas brewing. Hopefully I have time to take it on, or somebody can carry that torch.
but basically I think we could have a jaw dropping Chrome DevTools plugin for Om Next.
yeah, that's good application for it, making a Om.next Devtools plugin in Om.next, that's sounds like a fun project
I'm familiar with Bret presentations, do you have specific points on what you don't agree with him?
@dnolen I have been experimenting with some devtools stuff .. biggest hurdle is sharing data between browser->devtools
it is doable but the "browser" needs IPrintWithWriter for everything and the "devtools" needs a reader
I was thinking of devtools for om that say ... want to display the results of a Query
edn actually kinda works since there is a default for IPrintWithWriter like #object [...]
Is anyone using componentWillUnmount in om.next alpha4? It seemed to be working in alpha3, but I’m now getting: `ERROR: Assert failed: Invalid signature for componentWillUnmount got [this], need (= (count sig') (count sig)) at file` Trying to figure out if this is just an issue with my code or a bug
I think from past use of React and double-checking the docs, the signature of [this]
for componentDidMount
should be correct
@chris-andrews: probably a bug looking
@chris-andrews: looks OK over here at first glance but your error doesn’t make sense to me
Yeah, sorry, the second sentence above I typed the wrong thing. It is componentWillUnmount
componentDidMount
isn’t having any issues
@chris-andrews: yep typo fixing and cutting a new release
cool, thanks for checking that
@dnolen: I just tested it with my code and the issue is resolved
@chris-andrews: great thanks for the report
@dnolen: It’s really fun to try out, things are working very well even in the alpha state
is there a way with figwheel + om.next to not have the data reload every time you save? I’m using the code from the end of this tutorial https://github.com/omcljs/om/wiki/Queries-With-Unions and every time I save a change the favorites reset. I’ve tried defonce atom for the state var but that caused an error
@tyler you need to move your data into an atom, defonce
it, use it as :state
and pass :normalize true
to the reconciler
@dnolen still not working. It doesn’t throw an error any more when I refresh the page, but it throws an error as soon as a figwheel hot reload is triggered. I made a gist if anyone has a second to take a quick look and make sure I’m not doing something stupid: https://gist.github.com/tvanhens/e90042fed08e8ed23340 if its a bug I can create a ticket with the details
In om.old, I’m transacting directly on a cursor, replacing its value with a new value (it’s a map), the update happens successfully but upon rerender the cursor is nil. If I only update a property of the map then it works fine. Should I not transact directly on a cursor in that way?
@dnolen: Any chance we can change the defui macro to make the factory, since it is kinda boilerplate noise: (defui Person person ...same as already...)
one thing that I have in mind is that if people want to write a much more powerful layer over the foundation
Hello! so... I'm trying to normalize data in om.next that looks something like this:
(def init-data
{:universe
{:size js/Infinity
:beings [{:name "John"}
{:name "Mary"}]}})
I just want to 'normalize' the inner :beings
list, but it blows up if I try to normalize without an Ident for :universe
.
It looks like normalize*
expects a vector for the Ident where in this example I'd just want it to be the keyword :universe
... not sure if I'm approaching this all wrong
@alexhemard: if you’re having trouble with normalization you should show that your defui
bits look like
Are the code samples in the Om.next quickstart possibly outdated? I’m getting a Error: No protocol method IQuery.query defined for type om-tutorial.core/Counter: [object Object]
when trying to use this bit of code copy-and-pasted from the page:
(ns om-tutorial.core
(:require [goog.dom :as gdom]
[om.next :as om :refer-macros [defui]]
[om.dom :as dom]))
(def app-state (atom {:count 0}))
(defui Counter
Object
(render [this]
(let [{:keys [count]} (om/props this)]
(dom/div nil
(dom/span nil (str "Count: " count))
(dom/button
#js {:onClick
(fn [e]
(swap! app-state update-in [:count] inc))}
"Click me!")))))
(def reconciler
(om/reconciler {:state app-state}))
(om/add-root! reconciler
Counter (gdom/getElement "app”))
looks like (query component) is getting called even when there is no IQuery interface
If it helps, the page uses alpha4 as a dependency. I bumped around to alpha3 and 5 but got the same results.
@akiva: odd, I've seen that error before when I was on my chromebook, but on Window$ $even the tutorial works fine
unless David fixed it just now right before I started doing the tutorial which, to be honest, I wouldn't be surprised if that was the case
wow in the Clojure community we're just addicted to the tight feedback loop <crazy parrot removed>
there’s probably another one coming today if I can wrap up this fancy routing stuff for HTTP caching
oh yeah, I've been following the naming thread, need to check and see where its at right now
Is there any way to force normalization to occur after a mutation? … Or is it better to just insert the data in normalized form in mutations
@dnolen thanks. Thats the way I’ve been approaching it but didn’t know if that was idiomatic or not
@tyler it does introduce circularity issues if you’re not careful … but I don’t have better ideas at the moment.
In the om.next quickstart Counter example, an atom is used for app-state, and after each mutation, it reflects current state. In the normalization example, a def is used for init-state and therefore does not reflect current state, which is found in normalized form in the reconciler itself. If I change the init-state to an atom, errors occur with the reads. Is this expected behavior?
I never complain about boring commits. My entire afternoon has been lost debugging some interesting commits
in the query unions tutorial, where is it stated that an item’s :type
should be used to look up the corresponding subquery? is that just handled via ident
?
just need to write a tutorial on remote integration and then will probably switch to beta1
it’s all coming along nicely, all the “hard” problem turned out to be not so hard, so my confidence in the design is increasing
yeah, the more I play with it, the less I feel like I need any kind of fork ...I can't find anything to add