Fork me on GitHub
#om
<
2015-12-23
>
rhansen09:12:51

How do people deal with routing in om.next?

rhansen10:12:31

@w1ng: Great, thanks!

rhansen11:12:00

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

rhansen12:12:20

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

akiel12:12:19

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.

artemyarulin12:12:02

@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

artemyarulin12:12:51

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

akiel12:12:57

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

artemyarulin12:12:52

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

akiel13:12:33

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

artemyarulin13:12:48

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

artemyarulin13:12:18

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!

artemyarulin13:12:21

unless I understood your question in a wrong way simple_smile

akiel13:12:59

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.

akiel13:12:53

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

akiel13:12:04

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

akiel13:12:33

As optional thing of'corse

artemyarulin13:12:18

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

artemyarulin13:12:34

it’d definitely out of scope of om-next

akiel13:12:39

thanks I really have to read something about meteor

dnolen13:12:48

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

rhansen13:12:27

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

dnolen13:12:46

@rhansen: sure but I really would not bother

dnolen13:12:56

we have tons of tests and quite a few users

dnolen13:12:08

not such bug exists that I’m aware of

rhansen13:12:59

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

dnolen13:12:29

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

rhansen13:12:22

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

dnolen13:12:26

of course there may be something else going on

dnolen13:12:47

but incremental rendering definitely works

rhansen13:12:21

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

dnolen13:12:05

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

dnolen13:12:17

a bunch of people have their own solutions for that

dnolen13:12:34

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

dnolen13:12:58

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

r0man16:12:15

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

dnolen16:12:39

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

dnolen16:12:44

patch welcome

r0man16:12:03

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

dnolen16:12:06

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

r0man16:12:08

ok, I'll work on a patch and test

dnolen16:12:50

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

dnolen16:12:14

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

dnolen16:12:09

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

r0man16:12:28

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

wilkerlucio16:12:39

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

wilkerlucio16:12:10

I'm trying it correctly?

joshfrench16:12:00

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

wilkerlucio18:12:15

@joshfrench: that works, thanks simple_smile

wilkerlucio18:12:19

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

wilkerlucio18:12:41

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

dnolen18:12:55

@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

wilkerlucio18:12:56

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

wilkerlucio19:12:47

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

dnolen20:12:32

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

dnolen20:12:41

it sounds like legitimate issue that needs consideration

wilkerlucio20:12:18

ok, I'll open an issue

maackle22:12:07

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?

maackle23:12:46

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