How do people deal with routing in om.next?

there is a routing example at https://github.com/jdubie/om-next-router-example

@w1ng: Great, thanks!

Hmm. Om.next never seem to update the root after transact!. It replaces the entire div. Is this by design?

@rhansen maybe https://github.com/omcljs/om/wiki/Om-Next-FAQ#why-is-my-component-not-rerendered-after-transact is relevant

@sander: no. My component is re-rendered. But it does so by replacing the app-div, not by updating the parts that have changed, which React usually does.

Is there a story regarding server push in om.next? I find nothing about it. I see only client A mutations trigger a re-read and re-render on client A but not on client B.

@akiel: As far as I remember just call om/merge (.setTimeout js/window #(om/merge! rec {:ns/data new-data}) 3000))) supply merge-tree to the reconciler

and merge function should return new state (defn merger [state new-data] -> state

@artemyarulin: I see. But there is nothing to help me telling the server which novelty a particular client needs? I think about something taken from the queries.

Well, only you know the data. There are many ways how you can implement the sync between clients - but no, om-next isn’t a Metero-like framework which will handle that for you

So om.next is still pull based - I see.

I didn’t said that: It’s just up to you: - connect to the server via websocket and call om/merge! when new data appeared and merge it in the way you like; - do optimistic update and fire a remote call with each transaction, - replicate all the transact! calls via server across different users by sending event names, - or maybe calculate atom diffs all the time and send it via websockets to all the clients. It depends on your data|task

For example the way I’m using it on iOS application - om just fires specific events, and Objective-C backend handles it, process and return the data using push via om/merge!

unless I understood your question in a wrong way

I was hoping that om.next solves the problem of getting data to a component in a more wholistic way were is essentially cares about all the I/O.

But than I also understand, that this would be very inflexible.

exactly

But there could be something like the indexer on the server side which knows which client needs which data.

As optional thing of'corse

data sync is not a trivial thing - consider all the conflict resolution for example

have a look on the way how Meteor handles it http://info.meteor.com/blog/optimistic-ui-with-meteor-latency-compensation

it’d definitely out of scope of om-next

thanks I really have to read something about meteor

@rhansen: you have a bug somewhere in your code if that is happening

@dnolen: Hmm… I’ll go through the documentation again and see if I’ve missed something. If I can’t fix it I’ll try to create a minimal test-case and take it from there.

@rhansen: sure but I really would not bother

we have tons of tests and quite a few users

not such bug exists that I’m aware of

@dnolen: A minimal test-case makes it easier to ask others where the bug is 😉

such show stoppers generally get reported immediately - and I know pretty darn well how React is supposed to work.

Fair enough, I’ll try to pinpoint what I’m doing wrong.

of course there may be something else going on

but incremental rendering definitely works

@dnolen: Just to be certain of my understanding, and that I’ve expressed my problem correctly: I have a root component that renders a different child based on the property of a :url key in the state-atom. It’s a router, basically. My impression of React is that it will update (not replace) the ui tree as long as the root view remains the same (which it does in my case). What I see instead, is that the root div is replaced with a new div that represents the current state (react-id changes). If I update the local state of a component, this works correctly, but every time I call om/transact! I witness this behaviour. It could be that this works correctly if the ui-tree remains the same (same child components, with the only difference being changes in props), I haven’t gotten that far in my application yet. Does this make sense?

@rhansen: sorry I’m pretty tired of hearing about routing problems

a bunch of people have their own solutions for that

and I’m just not interested in this context at all when talking about perceived rendering problems

produce a real rendering problem separated from whatever higher level goal you are trying to accomplish

@dnolen: sure

@dnolen: Records in the app state, or received from the backend are turned into maps through normalization. Is this intended behaviour?

@r0man: not intended - just no support for records at the moment

patch welcome

ok, can you send me a CA at <mailto:[email protected]|[email protected]> ?

I personally have no use for records so it’s not something I need

@r0man: sure!

ok, I'll work on a patch and test

@r0man: sent

@r0man: whatever work you do I’m only interested in record support for entities

so this should be as simple as looking for {} and replacing with (empty data)

(or something like that, I always forget if records are emptyable or not)

ok, for example a person entity having a GeoPoint record as :location, the :location is still a record of the same type after normalization

right

ok

I'm trying work with tempids, but when I try to merge the tempids by state goes blank, I wrote this to test:

I'm trying it correctly?

@wilkerlucio: try (om/reconciler {:state (atom state) :parser s/parser :id-key :db/id})

@joshfrench: that works, thanks

@joshfrench: actually, it doesn't I was looking at the wrong place, still getting same results

it returns {:om.next/tables #{}}

@wilkerlucio: have you looked at the :tempids tests in the Om repo? I would compare and contrast to determine if you’re looking at a bug or a misunderstanding

@dnolen: I haven't, going for it now

@dnolen: I found that I need to send my main query to the merge! in order for it to work, as: (om/merge! reconciler delta (om/get-query s/App)), looking at the merge! implementation it seems like on a regular case it would get the query for the root at the application state, but when I render something and look at my reconciler, I never see anything at (-> reconciler :config :state deref :root), and that causes the query to return blank and then the migration ends up cleaning the database.

@wilkerlucio: write something up I can’t look at it at the moment

it sounds like legitimate issue that needs consideration

ok, I'll open an issue

I’m having an issue with remote fetch not triggering rendering. On what condition will using the reconciler :send function’s callback on a remote read trigger a re-read and re-render? Does it have to do with the query? In my case, the novelty I’m passing to the callback is only updating tables (`:person/by-name`, etc), could that be the cause?

or could it be that I’m using om/mock-root in devcards...