This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-02-09
Channels
- # announcements (4)
- # beginners (71)
- # boot (258)
- # braid-chat (7)
- # business (3)
- # cider (5)
- # cljs-dev (5)
- # cljsrn (64)
- # clojure (154)
- # clojure-canada (1)
- # clojure-poland (112)
- # clojure-russia (290)
- # clojurebridge (1)
- # clojurescript (60)
- # community-development (1)
- # core-async (25)
- # cursive (9)
- # data-science (1)
- # datomic (40)
- # editors (14)
- # events (2)
- # hoplon (2)
- # jobs (3)
- # ldnclj (51)
- # lein-figwheel (2)
- # luminus (1)
- # off-topic (5)
- # om (57)
- # onyx (29)
- # overtone (1)
- # parinfer (52)
- # portland-or (1)
- # proton (17)
- # quil (2)
- # re-frame (77)
- # reagent (1)
- # ring-swagger (20)
- # spacemacs (1)
- # test-check (4)
- # testing (13)
- # yada (1)
with om next would it be a good idea to talk to a server using web sockets?
@adamkowalski: the protocol you use to talk between server and client is your choice
@iwankaramazow: one alternative (that I’m planning to use) instead of server side rendering is to run the initial query for the app on the server and inject the transit encoded result into the app host page. When the state atom is initialised (but not yet normalised) it can be pre-loaded with this data. That will produce almost the same initial rendering speed as a server side render but without the need for porting all of om.next
@anmonteiro: thanks for fixing the bug regarding reindex
@steveb8n: Interesting, this might be a good way in the short term. I'll take a look at it later this week, need to finish partial app loading/code splitting first in this app I'm building
@iwankaramazow: the only downside I can see it that the initial app query needs to be hardcoded in the server. It’s easy to record the initial query but you have to remember to do it every time the client code changes.
Is there any possibility to just spin up a node server with its sole purpose to render everything to html? I vaguely remember some people doing this with a python or ruby backend
npm install http-server; cd project-dir; http-server
python -m SimpleHTTPServer 8000
ruby -run -e httpd . -p 8000
How do you normally dispatch to display the the main panel, as in, showing different pages? I have a bunch of react components (defui) for each page, and then I create the factories and then I have a multimethod that dispatches on the page name/route and each method calls each factory. It feels a bit too verbose:
(defui AboutPage
Object
(render [this]
(dom/div "This is the about page")))
(def about-page (om/factory AboutPage))
(defmethod layout/pages :about [_]
(about-page))
I could abstract away quite a bit of it with a macro, but before that, I’m wondering how other people are doing this.
Plain old functions here
I have something like ((routes/render-page url) (om/props this))
which hides the 'ugly' stuff
If you want to look at an example(s): https://github.com/jdubie/om-next-router-example https://github.com/anmonteiro/aemette
Well, that uses a hashmap for dispatching, instead of multimethods:
https://github.com/jdubie/om-next-router-example/blob/master/src/om_router/core.cljs#L96-L99
@pupeno: Have you implemented some form of link component for routing, i.e. something which renders a (dom/a)
+ blocks the default click behavior + triggers transition trough history
?
iwankaramazow: yes.
iwankaramazow: pushy is great for that. I did it with both bidi and my favorite, silk. I wrote blog posts about it. It was using re-frame, but it’s possible with Om Next with similar code: https://github.com/jdubie/om-next-router-example/blob/master/src/om_router/core.cljs#L123-L135
This is my blog post: https://carouselapps.com/2015/08/18/no-hashes-bidirectional-routing-in-re-frame-with-silk-and-pushy/
I'll take a look at it.
I'm currently stuck with (dom/a)
deep in a component hierarchy. I somehow need those components to have access to history or a callback which sets a history token. Currently a circular dependency is drowning the current approach.
ah fixed it, I was one (declare ...)
away from the solution
hi guys how to focus programmatically in om.next, I have set ref
on the element
and get it via (om/react-ref)
but returned ref doesn't have any focus
method. Am I doing it wrong ?
is it not possible to have subqueries fetched from a remote, if the parent does not get fetched from remote?
the wish to do so might seem odd at first, I have that situation because I have a child component with dynamic queries and this subquery needs to get merged into the root query. that's the only reason for the nesting of queries
Do you really need a child component for this (can't include it in the parent's query)?
that's why I am going to do now. However, I would prefer not to, because then I end up with such things bubbling up to the Root component all the time, when I would prefer to keep it the child
queries have to compose up to root anyway and then you pass everything down through props
hard for me to imagine your specific use-case
its the remote/client split that seems weird, wondering how that would ever come about
You can remove app-specific parent state from a query using process-roots. You have to mark your remote ast queries using query-root: true
@nblumoe: doesn't process-roots
work for this case?
does anyone have a concrete use-case for this?
https://awkay.github.io/om-tutorial/#!/om_tutorial.G_Remote_Fetch talks about re-rooting server queries
@hueyp: example?
e.g. (item-component (assoc item :foo “bar”))
vs (item-component (om/computed item {:foo “bar”}))
not sure if its just an organizational or functional distinction for query props vs other props
hmm I just took a look at the source code
can't seem to find an immediate benefit
correct me if I'm wrong..
@hueyp: I believe Om uses props for it's state-managagement facilities. You are encouraged to use computed for stuff like callbacks. They will be stored out of band (but still accessible) and not interfere with the whole query-app-state architecture.
Take what I said with a grain of salt because I'm still new to om next.
@hueyp: Props are supposed to be the query results. You then use om/computed
to add any computed or extra data that you want to pass in to a component.
@hueyp: in addition, if for some reason you had a UI component without a query, there wouldn’t be a need for computed (except for a desire to organize data I guess)
so reasonable to say someplace internally om treats om/props different than om/computed?
another random question … if I want to initialize something in a defui
constructor … is there a way to do that, or maybe just put the code in initLocalState
? 😛