This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-11-20
Channels
- # admin-announcements (28)
- # aws (16)
- # beginners (70)
- # boot (54)
- # cider (86)
- # cljsrn (8)
- # clojure (14)
- # clojure-art (12)
- # clojure-conj (2)
- # clojure-hk (45)
- # clojure-nl (2)
- # clojure-poland (2)
- # clojure-russia (32)
- # clojurescript (60)
- # cursive (27)
- # datomic (12)
- # devcards (46)
- # editors (2)
- # emacs (37)
- # immutant (72)
- # jobs (6)
- # ldnclj (7)
- # leiningen (1)
- # off-topic (1)
- # om (205)
- # onyx (16)
- # re-frame (21)
- # reagent (52)
- # slack-help (2)
- # spacemacs (11)
Got a pretty simple question (I think). I’m obviously not understanding something. Trying to have one component that reads/mutates (a button that increments a counter, displayed in the component), then a separate component that only reads the current count. Any ideas? https://www.refheap.com/111881
Ah sorry - the count in the read only component isn’t updating. I hit the button to increment the count, but it’s only updating in the component that’s mutating the state.
Try putting :count
in your transaction after your mutation. If that doesn’t work you may need to use idents to make sure om knows they are backed by the same data.
That worked. Updated paste for those who are curious: https://www.refheap.com/111882.
I don’t think so. At least, not as I understand joins :thinking_face:. Theres definitely some odd duplication in that example that I need to clean up.
Well, this is becoming a lot more of a full-blown example for an overall tutorial, but I've added a bunch of stuff to this demo: https://github.com/awkay/om-remote-tutorial The README describes it pretty well. I took some time coming up with a really nice story for writing the read functions for the parser. I also had some ideas on de-complecting UI-only app state from persisted app state, even when it needs to co-exist on a component. The server side needs a lot more work, but it is capable of "fetching". Also demonstrates a recursive query (with ...). See the devcards, as I haven't added rendering to the UI for that part yet (though it is trivial...I have to sleep sometime).
Hey @tony.kay @jannis have you ever thought about writing together a practical guide about Om-Next on LeanPub ? I am ready to put my money and sure others will do.
@hmadelaine: I haven't written anything about it yet but if I were to it would be free.
@jannis you wrote a lot in Slack 😉
Yeah, but no complete guide, tutorial or anything. Props to those who do (like @dnolen, @tony.kay), it takes effort.
Foam looks interesting. Would be interesting to see the difference between that and Node on Lambda for server side rendering of om
@grounded_sage: I suspect anything Foam like to soundly beat anything that involves running React
@grounded_sage: that said I suspect this approach will require discipline and I foresee many cases where just running React server-side is just easier
@dnolen: how will that work? Will it be just making it trivial to use like datascript? Or will it make Om more Clojure focused.
@grounded_sage: I don’t see why it would be any different than what @arohner’s basically suggested
Oh I think I get it. Just porting it to Cljc
Sorry are you all talking about this project, https://github.com/farisnasution/foam ??
(trying to follow along)
That's alright. Bit tired so questions are probably a bit hazy. Just assessing trade offs. Tempted to use Pheonix framework in Elixir land as I feel docs, more set path for developing backend apps, insane concurrency, coolness of OTP and I feel deployment will be easier due to all these. But I really do prefer Clojure as a language.
@arronmabrey: nope its actually https://github.com/arohner/foam
@arronmabrey: my guess is @dnolen
Yep that's it.
I'm on iPhone with shattered screen so a bit slow :p
@jethroksy: it was mentioned in a talk (https://www.youtube.com/watch?v=fICC26GGBpg)
@grounded_sage: Elixir/Pheonix look really cool, that’s for sure
@jethroksy: thanks!
@anmonteiro: yup I watched it but couldn't quite gollow... would love to see an example Foam app somewhere
@dnolen: you also mentioned in your talk that with Om Next you could cache everything? Then move to Datomic at a later date. Is that right?
@dnolen: you also mentioned in your talk that with Om Next you could cache everything? Then move to Datomic at a later date. Is that right?
@grounded_sage: all I meant was that the HTTP caching layer is an easy way to deal with things that are challenging to optimize
this why slow language runtimes or slow DB queries aren’t really a problem for many web based applications
meaning you can probably make the model work even if your backend decisions are modest / conservative
Ah I see. I must have misinterpreted that part of the talk. Thanks for clarifying that for me :)
@dnolen: in your talk / example. You separated dynamic user likes from the rest of the feed. That way you could cache the static feed and mixin the dynamic user likes. In that example the feed must be exactly the same for every user... no? I mean if the entire feed was unique to each user e.g. instgram / fb news feed. Then you can't cache that... correct?
@arronmabrey: the question seems strange … can Om Next cache uncacheable things?
Well I guess in the example (I think) you used the word feed, and I guess my mind went straight to a user feed like instagram / fb. But I don't think that's the type of feed you were referring to. I think maybe an example of what you were referring to could be the public/trending twitter stream. Where it's the same for a large group of users where some of the users may or may not have liked one of the tweets in it.
I'm just trying to clarify in my mind which type of feed it was in the example, and I think I answered my own question 😉
@arronmabrey instagram / fb problem is really not any diffferent. different applications cache different things.
the only thing that matters is that you can cache whatever part of the query makes sense for your application using traditional methods
@dnolen: thanks, that makes total sense.
@hmadelaine: on docs: I certainly take help from anyone. I do periodically talk to @jannis and anyone else who will listen in order to get feedback and clarification...but I also have a whole team of people to train, so I'm already getting paid to write docs (because I choose to do so, because the is the most effective way to train a bunch of ppl in parallel). Putting them on the net just gives back to the community.
For the Foam talk previously, isn't it more straightforward to just server-side compile with nashorn? That's how I've done that
he mentioned in the talk that nashorn is "very unpolished"
Or am I misunderstanding what that does? It lets you generate pre-compiled html you can send down?
some things don't work
This is what I’ve used https://gist.github.com/jamesnvc/6bd6dcc0aa938ed45a10
Like, some clojurescript-specific things don’t work, or some general javascript things don’t work?
@anmonteiro: thanks!
alright new thing to ponder @joshfrench’s Union issue has demonstrated a problem with om.next/IDent
currently the current approach suffers in having to have the types that implement om.next/IDent
@dnolen: at first sight looks OK
seems like om/get-ident
will be of great help then (since you removed it a while back - and then reinstated :P)
compromises readability a bit, maybe?
another possibility is to support both om.next/Ident
and the inline version and see where we end up.
you only really need the later if you want generic processing pipelines w/o needing any defui
types to help you
I really like the above :om.ident
bit you just showed
It seems like that approach with the ident in the query itself means you could have several normalized keys in a single query. Not sure how useful that would be, but it could help accomplish certain things
@dnolen: Hm. Well, it seems like you could still supply a get-ident
that can take a component or class (by analyzing the query). I'm a little torn on the grammar itself. The way you've written the join implies the parent would specify the ident of the child? {:foo (om/get-query Foo) :om.ident [:type :id]}
The union query story is much more limited in the UI, so the loss of transparent composition seems fine for that limited case.
but I personally see no reason to switch up a regular component's Ident...I was getting the impression that others did
yeah was just thinking out loud, I think the current flexibility of om.next/Ident
is a good thing
Ah, and query params could be used to mess with the embedded :om.ident value...so that's nice (or at least, flexible)
yeah I wouldn’t take it there yet this will only work for union for now and I would not mess w/ it via params for the time being
So, I'm about to write up something on the default database format. Hows this sound? "The default database format has the client local state stored in a tree that matches the structure of the query response, and all items with an Ident are pulled out into flat tables at the root of the state and replaced with refs".
I've been using that in my parse helper functions to walk the graph...which is why I'm using the term
BTW, whoever suggested doing tutorials in devcards...that is what I've decided to do, and it is working very well
yeah, being able to write tests in there let's you just slam in arbitrary code that ppl can see running and play with
and the ident?
function isn't what I would expect now, since it is a "does it implement?" meaning
you cannot really know whether something is or isn’t an ident without the query in hand
I've written parsing helper functions that make it really easy to build read for the default db format
e.g. https://github.com/awkay/om-remote-tutorial/blob/fb8ddf06999512f7d0dc54b686c7dd4c2fe63357/src/om_tutorial/local_read.cljs#L10 with definitions at https://github.com/awkay/om-remote-tutorial/blob/fb8ddf06999512f7d0dc54b686c7dd4c2fe63357/src/om_tutorial/parsing.cljs#L80
yeah my brain isn’t there yet - but if there's ideas about what needed for custom traversal, people should bring that up
Just throwing in my two cents, I currently use the ref?
helper in my parser’s default read
so that it can automatically follow references/idents.
besides @dnolen 's om-next todomvc demo, any particular references I can use to learn more about om next query syntax and interaction with the server side? Feel free to point me to the source code as well.
@dnolen: is there an entry point that might have a collection of links to such community things? Or particular github users/repos you'd recommend or know about?
@dnolen: specifically, you're referring to the Community Resources section at the bottom of https://github.com/omcljs/om/wiki , correct?
@grzm: My kanban demo is a little out of date (still on normalize
instead of db->tree
etc.) but fairly clean; copaste is more experimental and less clean, but therefor more or less up-to-date and comes with server-side communication.
Looking at some of the om next tests can help you understand some of the code. https://github.com/omcljs/om/blob/master/src/test/om/next/tests.cljs Anything past line 160 seems relevant
Though probably not a starting point, but something to look at after you have went through the main documentation/tutorials and @tony.kay tutorials
@grzm: The Om Next Overview is pretty much up-to-date...and the new tutorial should come spewing out pretty quickly.
is there an example on how to do routing with om.next
and with libraries like bidi
and secretary
?
If I have two components in different parts of my app, and I want to send the results of an event on one to the other for render, what's the best practices what of doing that? A channel? Root shared state?
If the event is a mutation from a transaction in one component, you can put keys in the transaction after the mutation specifying which keys to read after the mutation to cause a re-render
Just finished recording a whiteboard session that is an overview of Om next. Might be helpful for those trying to understand how the overall system works...though you'll need to combine it with a reading of the basic tutorial and overview. https://www.youtube.com/watch?v=IlNrmKYA7Ig&feature=youtu.be Youtube transcoding should be done within a minute.
@noonian: Thanks. I'm getting a re-render of component A (if A had a state change), but I need to fire the mutation data to component B, where A and B share a parent component. Thoughts?
I would think if you put the keys that the parent component reads in your transaction after the mutation it would force a render for both of them
OK, I'll give that a shot
The tutorial I'm working on has moved to using devcards to make a more interactive experience, and I've just pushed an update. Starting it is a little different than before. You want to clean your project before restarting it: https://github.com/awkay/om-tutorial (RENAMED)
Really cool @tony.kay !
@kevinmershon: Ah I’m sorry, I thought you we’re using Om.next, root-cursor
is from Om.now so my advice probably didn’t make much sense 😛
No problem!
@joshfrench: your issue is fixed and it was simple
oh good! i’m so used to being the guy who finds the aggravating edge case, just ask my coworkers
@tmtwd: (render [this] ... (dom/div #js {:ref "child"}))
, then somewhere else in the same component: (.-style (om.next/react-ref this "child")
should work, basically
using pieces from @tony.kay’s https://github.com/awkay/om-remote-tutorial
@jdubie: I have not looked into speed testing my helpers, but I cannot see where my helpers would be slow at all. You might add in some printlns and make sure you're not accidentlly doing things you don't expect.
but if you find some kind of bug or gotcha, let me know. I'll be documenting those in a day or two....lots to write
@jdubie: if your queries are 10 levels deep you’ll need to look into path optimization
ok, so on entry to the read function, check for :query/root...what do you do if you can't support that root?