This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-02-18
Channels
- # admin-announcements (3)
- # announcements (7)
- # aws (1)
- # beginners (76)
- # boot (340)
- # cider (9)
- # clara (35)
- # cljs-dev (7)
- # cljsjs (16)
- # cljsrn (11)
- # clojars (1)
- # clojure (192)
- # clojure-dev (6)
- # clojure-madison (8)
- # clojure-russia (373)
- # clojurebridge (1)
- # clojured (9)
- # clojurescript (172)
- # community-development (1)
- # core-async (2)
- # cursive (7)
- # data-science (2)
- # datomic (12)
- # devcards (1)
- # dirac (63)
- # emacs (3)
- # events (10)
- # gsoc (3)
- # hoplon (1)
- # jobs (1)
- # juxt (20)
- # ldnclj (4)
- # lein-figwheel (12)
- # leiningen (1)
- # off-topic (21)
- # om (232)
- # onyx (64)
- # parinfer (8)
- # proton (21)
- # re-frame (8)
- # reagent (1)
- # ring (3)
- # ring-swagger (3)
- # slack-help (4)
- # spacemacs (6)
- # testing (3)
@tony.kay: (.forceUpdate c)
doesn't work?
I'm talking about figwheel hot code reload: I am calling force root render on reconciler after reloads...but nothing updates because the app state has not changed.
I understood you're talking about hot reload
or are you saying I should save off the mounted root component and call (.forceUpdate on it)
exactly
it calls :root-render
which gets you that behavior because sCU returns false
@tony.kay: would love to hear your take on my discussion with David earlier on
wrt. "routing"
@anmonteiro: well ideally I would have access to a map such as {:mouse {:left-button-clicked false :right-button-clicked true :position [100 100]} :keyboard {:keys-pressed [‘a’ ‘b’ ‘c’]}}
then the rest of my application could no longer have to think about how that information is being generated, and would simply be able to think about it as the current state of the input devices
@anmonteiro: is that in todays logs?
thats why I was thinking about storing that information in the global app state and then just listen to the different events that could cause a change, and transact them as they occur
@hueyp: if only we could link to a slack message
12h38 for you I suppose
with core async I would need to listen to events and then put them on a channel, then every time I pull an item out of the channel I would transact it anyway right?
@adamkowalski: yes, but it's a more sane approach IMO
ok, so maybe I am trying to do the wrong thing here
how are most om next projects handling such event streams in an idiomatic way?
I might just be trying to force a event model i am used to onto a platform that has a different approach to the same problem, and thats why things are a little hairy
shouldComponentUpdate
hm....getting it to actually rerender deeply is problematic....forceUpdate only gets root. I can change the react key on the root every time, and that gets it, but I'm having trouble seeing where to hack in my own key for figwheel so I'm not leaving a silly thing in Root component production code,
Got it! It was a lot easier than I was thinking...no hack needed: Put a query in root component for :react-key, embed that as :key on the root dom element, then your refresh function need only change the react-key. Bingo...rerender all
Ive got a normalized database with todos and todos/by-priority. When I remove a todo I'd rather not have to update both. Can I do this better? https://github.com/seanirby/om-tutorials/blob/master/src/om_tutorial/core.cljs#L37-L49
@dnolen: eek, I think my PR broke something. I render a tabbed interface, and tab1 uses set-query!
to change query params, if I click on another tab (which uses set-state!
to just change the UI), the original tab seems to get the props before my set-query!
call. I suspect it's this line: https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L1622 Should I not use (props c)
if I don't re-query? I'll keep looking into it...
all the tests passed btw, I got them to run. I'll make sure to write a new test that tests whatever this broke
oh, shoot I think I know what's happening. The parent component of the tab1, the tab manager, still has the old result before the query params changed. Now that we don't re-run queries, it's getting re-rendered with the old props and passing them down. If we re-query we'd get the new params
we might have to re-query because we don't know if any query params changed in child queries
@hueyp: hmm, then what kind of information it provides ? in this example https://github.com/anmonteiro/om-next-demo/commit/fea61fc1e6786eb95d5292c33aa12704964b07f3
I feel like it's a perfect fit of how to define what kind of information we return from a mutation
haha, yeah of course I think we should. I have read it once, but it does seem a bit confused for it to behave that way. Just thought if it updates to work properly yet. @hueyp: haha 😄
maybe it's a candidate for the Om next FAQ?
@jlongster: I'm pretty sure it did My pagination suddenly stopped to work. I've suspected that code, because its related to setquery. and the pagination was working at Add invariant to build-index*
. After updating om at home, I've noticed that the server was receiving the right reads, the root node read was being invoked and the nested query params was being updated but sometimes even after the nested query changes, the lines are not shown.
@seanirby: https://awkay.github.io/om-tutorial/#!/om_tutorial.F_Mutation there is a section on 'deleting things'
seems like you do need to do that, unless you leave the ident and garbage collect it somehow at a later stage
danielstockton: Cool, thats what I figured. I don't mind it, but I suspect other users will want those updates to happen automatically. Anyways, thanks for the response
i get around it by using datascript
but that means other tricky areas, like migrating tempids
danielstockton: yea, I mean to try out datascript at some point. as soon as I finish grokking om...
@anmonteiro: hi! just read your blog post on changes to om.next code for full hot reload experience
does it apply if I'm using figwheel? or was it more thought for something like devcards?
@marianoguerra: depends on which one you read
so that one is meant to be used with Figwheel
this one builds on Devcards to create more Om-Nexty easy-to-use cards: http://anmonteiro.com/2016/02/om-next-meets-devcards-the-full-reloadable-experience/
ok, thanks!
@jlongster: right stuff like that was probably the reason it worked the way that it did
@jlongster: there are also two kinds of tests, stuff that doesn’t really require a UI that you ran
@dnolen: I'd love to hear your take on this (regarding our conversation from yesterday):
Say I have a dashboard like the one in the Union tutorial. In a perfect world
1) what should be the view that the root component has when we change e.g. a Post's query (e.g. from [:id :title :content]
to [:id :title]
)
2) what should happen to the other Post instances? should they maintain the same query or should their query change as well?
2.1) or even: should we allow both to happen
@anmonteiro: I think we need to go a bit deeper before we can ever start talking about 1) or 2) or some combination
first there’s the current assumption around set-query!
where components get to change their own query
this actually limits options - and we should think about what happens if we put it on the chopping block
@dnolen: I understood. Requires thinking, but would make things simpler, from a 30k ft perspective
OK I agree that's the first question that needs to be asked
follow-up to that are: - what are things that currently work that would stop working in such a scenario? - would we lose flexibility?
we need to put some bounds on flexibility based on apps that most people will actually write
by tabs you mean the union item, by dashboard view, the subview?
however for unbounded lists of heterogenous stuff - is a child changing a subquery
really a reasonable thing?
I don't get what you mean by bounded/unbounded. Language problem
that's the bounded thing, I suppose?
but a you have a dashboard of N items (you don’t know how many there are, you’re just asking for the first 50)
got it
“I don’t know what or how much I’m going to show” and there’s no way to express changing the query of one of these things
that brings us to what I meant by the Dashboard question I started the conversation with
you have a list of N things - and you change the query of one thing in that list of things
this just seems gratuitous - I can’t see any solution that doesn’t require undesirable complications
Right, I understand that
however it’s different from wanting to fix this for natural tree relationships in a UI
but it should be possible to change all the Posts queries, in my scenario
@anmonteiro: yes you should be able to do that
and have the root be in sync
which is not currently possible, if I understand correctly
@anmonteiro: that’s right
@anmonteiro: which does get me thinking - based on what you were saying yesterday
now I'm gettting that this is what I wanted to ask all along, I just formulated my first question incorrectly
without changing anything else?
every place in the indexer where we use a static class we instead switch to the instance (when it mounts)
Trying to fully understand these last bits
1. When are components not in a join? I can only think of the root
and maybe the union item
No I don't believe so, what I'm getting at is how do you detect when looking at a join that there is only 1 instance or many? Maybe I'm missing something really simple here
hrm no it is tricky, you would have to check to see that the result of the join is a vector
the first pass at?
right
there's maybe one thing that we could use
we have a set of all the mounted instances in :class->components
that could probably be used to know if a join has 1 vs many instances
can't know without trying
@anmonteiro: btw, this is definitely a good conversation - I haven’t had time to think about the “routing” problem and I think this is the most promising idea / direction so far.
I'm happy to pick your brain, and I believe this is a good thing to be thinking about
I prototyped a very simple version of a query manager last night
I would summarize the idea as "transitioning the indexer from the static tree to the runtime tree"
but I'm not sure if the assumptions I built it on were the correct ones, after today's conversation
probably
I'll share what it's doing anyway
at componentDidMount
I index the instance query template at the data path of the parent
whenever a child changes its query, I propagate that change at the template of each parent
until reaching the root.
For very simple cases, getting the root's query was giving me a view of the changed children
@anmonteiro: that’s also an interesting idea
@dnolen: I'll pursue both in parallel
but the indexer stuff, if it works, should probably prove simplest
@anmonteiro: cool! exciting stuff
definitely agreed
@dnolen: btw, we're not validating componentDidMount
's function signature
I'll send a PR your way in a sec that takes care of it
I finished writing the todo app using clojure+sql and om.next, before I write a post explaining the code I would like some feedback on the code, particularly the om related code
if someone want's to take a look, the backend om specific part is here: https://github.com/marianoguerra-atik/tudu-v1/blob/master/src/tudu/api.clj
the ui part is here: https://github.com/marianoguerra-atik/tudu-v1/blob/master/src/tudu/ui.cljs
@marianoguerra: shouldn't you use {:value something} as results from the mutate and read functions at the server ? I mean, if you are using the parser at the server the same rules apply
@geraldodev: I think I have it wrong in the mutates
in the read I do it correctly https://github.com/marianoguerra-atik/tudu-v1/blob/master/src/tudu/api.clj#L25
@marianoguerra: thanks for sharing!
@grzm: no problem, let me know if you have any doubt or something is not clear
is there something useful to return in a mutate? other than the tempid mappings?
(in the backend)
@marianoguerra: I haven't dug into the code yet, but am getting an error trying to get the app up and running.
what error?
have you run "lein figwheel"?
I don't serve index.html from /
will add that to the readme
and http://localhost:8080/index.html works.
seeing Cannot compare <#C06DT2YSY>/id["171faee9-87f1-4175-bed4-34bcb41fbeba"] to 1
in the console when adding a new item
Also repeated WebSocket network error: The operation couldn’t be completed. Connection refused
yes, the tempid stuff is not finished
the websocket error looks weird
I get this at page load "Firefox can't establish a connection to the server at <ws://localhost:3449/figwheel-ws/dev>." but figwheel live reload works so it seems harmless
do you get it repeteadly?
(it is because we are loading the frontend from the backend and not from the figwheel server)
if someone knows how to avoid that error let me know
don't know a way to have figwheel and the backend repl in one repl
don't know if it's desirable 😛
Well, for development, likely not. Might be nice to have instructions on how to run it stand-alone/prod
@grzm: will add it now
thanks One of the benefits (?) of being a newbie is that I will likely hit every single possible bug/barrier to entry
Quick question: Where is the best place in an app to put calls to set-query!
? Let's say someone clicks on a tab in my app, and I have a new component that becomes visible as a result, with new query requirements. Then, I could write my :onClick
event look like this:
:onClick (fn [e]
(om/set-query! component-with-new-child ...)
(om/transact! this '[...])) ;update the ui to make the clicked tab appear in the foreground
Alternatively, I could put the set-query!
in the mutate action, or place it in the component-with-new-child
somehow so that it can update its own query.
What is the best practice for where set-query!
calls should go?@grzm: https://github.com/marianoguerra-atik/tudu-v1/commit/bac272a8baf68a4ccffc59983266d4198de8674c
@drcode: there isn’t a real best practice - set-query!
is the thing most likely to be tweaked in the near future
@marianoguerra: thanks!
let me know if you have any problem or doubt, the idea is that it's clear and useful
@drcode if what the transact does is just invoke set-query! I'm not bothering call transact! because set-query! already does, and it even allow you to read keys.
marianoguerra: All the info is there in the documentation. For a newbie like me, I was looking for something shorter as well.
there's a shorter way for the backend
lein run
@marianoguerra: Just a couple of small editorial things I noticed.
In ui.cljs
, it took me a bit to realize c-or-r
(e.g., close-item [c-or-r]
) meant component or reconciler.
I think I've seen this usually just as c
, and it's understood that reconciler works there as well.
The code is pretty straightforward. I'm going to dig into your core.async stuff later to learn from it.
It's very helpful for me to see complete examples like this. I hope my feedback has been helpful.
@grzm: the core async stuff is only for the http request, because the request returns a channel, not much magic there
thanks for the feedback, will do the changes
I'm getting a Use of undeclared Var om.next/query->ast
in om.next remote synchronization tutorial
is it legal to call om/set-state!
in componentDidUpdate
? I’m not seeing it result in a render
@hueyp: I've been successful at doing that
might not work on master because of the bug introduced yesterday