This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-12-29
Channels
- # beginners (31)
- # boot (5)
- # cider (1)
- # clara (1)
- # cljs-dev (9)
- # clojure (118)
- # clojure-nl (2)
- # clojure-russia (90)
- # clojurescript (344)
- # cursive (4)
- # datascript (1)
- # datomic (41)
- # emacs (5)
- # hoplon (48)
- # ldnclj (13)
- # lein-figwheel (13)
- # leiningen (1)
- # off-topic (1)
- # om (146)
- # omnext (1)
- # onyx (65)
- # re-frame (22)
@anmonteiro: Here’s where I got the indexer term from: https://github.com/omcljs/om/wiki/Quick-Start-%28om.next%29#the-indexer
@anmonteiro: oh man, I tracked my refresh problem back to my server (I’m using the Phoenix Framework). It is apparently serving a new page, whenever I update my CLJS.
@anmonteiro, @adammiller : thanks for your help
@mudphone: good to know it's working; it's normal do have to defonce
the reconciler
@anmonteiro: thanks
I'm having an error after merging an ident in, using datascript. The specific error is: Uncaught Error: Invalid key [:user/id "020b3e79-9f17-484c-9ea3-9f2428810072"], key must be ref or keyword
I'm using a custom :merge-ident
function, which seems to be working fine, so I'm not sure why this is popping up. It is happening in (key->components [_ k] ...)
I've been playing with a minimal om.next / sente setup today. Sharing here in case anyone is interested (also would love suggestions). https://github.com/olivergeorge/stripboard/tree/master/src/stripboard
(My idea was that perhaps watching a server side atom is a nice way to visualise data while programming. Not sure if the idea has legs.)
hi guys can anyone give me a good example of parameterised read query expression ? I have tried this but it is a mutation ...
'[(project/page {:selector [:project/name
{:project/developer [:db/id :developer/name]}]
:project/name "Phu My Hung"})]
@nxqd: Try [... (<query expr> <param map>) ...]
. You're close, except your project/page
is not a query expression.
@nxqd: The grammar is a good reference: https://github.com/omcljs/om/blob/master/src/main/om/next/impl/parser.cljc#L5
https://raw.githubusercontent.com/artemyarulin/ktoa/master/om-next-cross-platform-sync-state.gif With om-next when we have all the app state in one place it almost trivial to share it between different clients during development. I’m really happy with it
@artemyarulin: your demo is sick. I'm looking forward to it 😄
@nha: Kinda this as well. I’m working on om-next lein template currently which allows to do the same, but without spending too mach on environment setup
mobile development discussing goes in #C0E1SN0NM channel, welcome!
@artemyarulin: Awesome ! I am no mobile dev, but I will definitely check it out as soon as it matures a bit
add-watch for app-state atom which calls figwheel custom ring handler which then append string with reset! () call to the file with a state, which then figwheel recompile and distribute across the clients. Hacky as hell, but it works and I spend 1 hour on this staff
It’s not that hard I guess I should create an issue for figwheel - it has a open websocket already, maybe we can utilise that
Does anyone else experience that the parser reader is triggered when updating the component local state?
@rhansen: that's expected behavior AFAIK
Updating local state schedules re-rendering which in turn calls reads
I could be wrong
@anmonteiro: You’re probably not 😛
How would you structure a multiple view single page app, I have experimented with various approaches now falling back to doing a new add-root! on every "page" switch, essentially mounting a new om.next class. The thing I want to solve is pass routing params to the root component (class) being mounted, after reading for a while through the code it seems its not that trivial, is there something I am missing?
@deplect: I have solved that using set-query!
on every route change; I've put together a lein template which you might find useful (https://github.com/anmonteiro/aemette)
I have a nested query where :remote-read should, well, trigger a remote read:
[:url {:page [:test :remote-read]}]
Currently im using the following for the :page reader:
(defmethod reader :page [{:keys [parser query] :as env} _ _]
{:value (parser env query)})
But this doesn't work (won’t trigger a remote read) as parser
only returns the value of the query. How can I know if a sub-query specifies :remote
?@rhansen: have a look at https://github.com/awkay/om-tutorial/blob/master/src/main/om_tutorial/parsing.cljs#L191
@anmonteiro: Thanks!
@anmonteiro: Thx! Browsing through your template gave me some valuable inspiration, essentially the componentWillUpdate in combination with the IQueryParams part in the ..components.app stuff was the pattern I was looking for
@deplect happy to help
I’ve run into a performance issue with om next where the speed of transacting a new value into the app state is affected by the size of the new value. (As in: if the new value is a map containing a 100-element vector, it’s pretty snappy. If it’s a map containing a 5000-element vector, it gets really slow.) I haven’t found the actual culprit yet, but it seems to be something about how the mutate expression is handled by the parser.
If I wrap the value within the app state in an atom, and then deref the atom whenever I need to use that value, things speed up dramatically.
Om Next is completely anti putting large amount of query driven data into the ui data tree
Well, it’s not really query-driven, as I understand that. None of the queries look inside that value.
@peeja: yep, no new ideas there wrt. the architecture, I just made it work with Om Next
@dnolen: you said yesterday that you wouldn’t build now anything for production using Om Next. When do you estimate to have a beta version?
@anmonteiro: Well, you pushed the controller architecture into Om mutations, which—while it's the obvious thing—is also good to see written out before we go transform the giant app. So thanks!
@peeja: right, but the controllers are still used to trigger those mutations when the channels receive something
@peeja: I also have some ideas wrt. remoting that I didn't include in the template, if you want some suggestions later
@dnolen: is it intended behavior that a root component that implements IQuery but returns an empty vector for its query will not be rendered? I run into this when I’m starting out since I don’t need any dynamic data yet and just want to get a static view up. In order to render a constant UI that doesn’t use app-state you need to add a bogus key to the query just to get add-root!
to work.
@dnolen: It is, in fact, a typo (not in code, in slack): [ { [:current-user '_] [{:things (om/get-query Thing)}] }]
db->tree
is fine with it, but transact!
/`set-state!` cannot find the query for the child that renders Thing. I submitted an issue
I just updated my routing example to use the *total query* approach in favor of using set-query!
on the root component. My implementation of the set-query!
approach was probably naive but switching things to use total query removed a lot of logic from my components and made things much more testable. added an example of this to the README.
https://github.com/jdubie/om-next-router-example
@jdubie: yes I was just experimenting with the set-query! approach and it doesn't seem to be a natural solution. Your total query strategy seems more natural, like the way you pass along the route->query map and using it to resolve the query belonging to the component. Drawback of this approach is when you are in an interactive development flow and you change the query in the component you would have to repopulate the route->query map no? Wondering if it would make more sense to just do the resolving completely in the parser?
@deplect - thanks for taking a look. glad you agree. re: interactive development. i use figwheel and have defined route->query
in a namespace that always gets reloaded when anything changes so can interactively change queries. i would warn against building that map in the parser - queries shouldn’t know anything about components
changes around error handling means I'm killing off the possibility of ever passing nil
props
I don’t see any value in supporting such a thing and it’s a simple way to detect that an error has occurred
that is … you should never pass nil
but we may internally pass nil
for internal error handling reasons
@dnolen: Thanks for setting me straight on that. Missed that part of the Contributing doc.
@glv I’m pretty sure your issue is due to the path marking traversal in om.next.parser
That’s what the Chrome profiler was pointing me to, but I haven’t understood that code well enough yet to see the issue clearly.
@dnolen: Not sure if you saw this question earlier or not, but is set-state!
and update-state!
supposed to trigger a query when they are run? They schedule the component for re-rendering, which makes sense, but I had this impression that the component query is only run on mount and on transactions 😕
@glv not sure when I will get to it since it’s a finesse thing at this point - higher priority architectural stuff needs sorting out first.
happy to take a patch of course - the idea would be to use the query to figure out what values to ignore
No worries … for my actual project, I can use the atom-wrapping trick as a workaround for now, and I’ll try to find time to dig into the code and figure out how to patch it. I’m a bit intimidated by that code, though.
do not direct questions at me if your problem would clearly be a stow shopper for actual usage
assume you are making some simple mistake that other people can answer if clearly the problem would prevent everyone from proceeding
this is the default implementation https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L1518-L1534
it should be self-evident there is no such thing as calling set-state!
and not re-running queries
if you’re jumping on board a certain level of engagement is going to be required to both advance your understanding
source is pretty interesting to read also!
@glv yeah atom wrapping trick works for the time being - will definitely get to it post error handling / routing hooks work
@dnolen i wonder if theres a slack integration that would allow you to tag the repetitive questions and build an adhoc wiki--did a little googling and found this. might be useful. https://slack.com/apps/A0FHVR2R0-guru
@johannjohann: hrm maybe, the problem is not precisely getting the same questions over and over again
rather newcomers who are just starting out who have questions about anything working at all
encouraging the former and kick starting the later are definitely on my todo list for 2016
yep. its principled, and for good reasons, but i think its somewhat easy to want to fall into old habits of building up stuff--you get maybe 40% there without really taking in the principles, get confused etc
@dnolen: I should’ve read the source first, but in this case I probably would’ve had the same question. After some brief hammoc time I’m chucking this down to me not understanding the differences between Om and React and will make changes accordingly.
I was using component local state to store the contents of several input fields in a form component. But that would be bad in the case of remote queries in the tree.