Fork me on GitHub
#om
<
2016-02-09
>
adamkowalski05:02:47

with om next would it be a good idea to talk to a server using web sockets?

jimmy07:02:37

@adamkowalski: the protocol you use to talk between server and client is your choice simple_smile

steveb8n07:02:29

@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

jimmy07:02:54

@anmonteiro: thanks for fixing the bug regarding reindex simple_smile

iwankaramazow08:02:24

@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

steveb8n08:02:06

@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.

iwankaramazow08:02:51

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

danielstockton08:02:17

npm install http-server; cd project-dir; http-server

danielstockton08:02:27

python -m SimpleHTTPServer 8000

danielstockton08:02:01

ruby -run -e httpd . -p 8000

Pablo Fernandez08:02:08

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))

Pablo Fernandez08:02:43

I could abstract away quite a bit of it with a macro, but before that, I’m wondering how other people are doing this.

iwankaramazow09:02:35

Plain old functions here

iwankaramazow09:02:52

I have something like ((routes/render-page url) (om/props this)) which hides the 'ugly' stuff

Pablo Fernandez09:02:50

Well, that uses a hashmap for dispatching, instead of multimethods:

iwankaramazow09:02:40

@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?

Pablo Fernandez09:02:03

iwankaramazow: yes.

Pablo Fernandez09:02:06

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

iwankaramazow09:02:42

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.

iwankaramazow09:02:45

ah fixed it, I was one (declare ...) away from the solution

jimmy11:02:46

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 ?

sander13:02:28

@nxqd: maybe you need to call something like (om.dom/get-node (om/react-ref v))?

sander13:02:32

yeah call om.dom/node on the component that react-ref returns

nblumoe15:02:50

is it not possible to have subqueries fetched from a remote, if the parent does not get fetched from remote?

nblumoe15:02:44

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

danielstockton15:02:02

Do you really need a child component for this (can't include it in the parent's query)?

nblumoe15:02:54

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

danielstockton15:02:27

queries have to compose up to root anyway and then you pass everything down through props

danielstockton15:02:12

hard for me to imagine your specific use-case

nblumoe15:02:22

yes, but I would like to keep the query params on the child component

danielstockton15:02:25

its the remote/client split that seems weird, wondering how that would ever come about

taylor.sando15:02:17

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

anmonteiro15:02:26

@nblumoe: doesn't process-roots work for this case?

nblumoe15:02:46

hm I don't know. did not use it so far at all, will need to check, thx

danielstockton15:02:04

does anyone have a concrete use-case for this?

hueyp18:02:44

is there a benefit of computed vs adding a value to props?

hueyp19:02:49

e.g. (item-component (assoc item :foo “bar”)) vs (item-component (om/computed item {:foo “bar”}))

hueyp19:02:25

not sure if its just an organizational or functional distinction for query props vs other props

iwankaramazow19:02:25

hmm I just took a look at the source code

iwankaramazow19:02:41

can't seem to find an immediate benefit

iwankaramazow19:02:51

correct me if I'm wrong..

currentoor21:02:19

@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.

currentoor21:02:45

Take what I said with a grain of salt because I'm still new to om next.

jannis21:02:28

@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.

ethangracer21:02:52

@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)

jannis21:02:40

Yep, correct

hueyp21:02:32

so reasonable to say someplace internally om treats om/props different than om/computed?

hueyp21:02:44

and thanks simple_smile

hueyp21:02:27

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? 😛

jannis21:02:06

Depends on when you want to initialize things. initLocalState is one possibility, componentWillMount may be another.

jannis21:02:12

Or componentDidMount

hueyp21:02:51

:thumbsup: