Fork me on GitHub
#om
<
2016-12-07
>
adambros00:12:57

Has anyone wanted/tried to document reads/mutations? Particularly if they are multi-methods. Right now I’m putting a :doc ”string” in the return value, but I was wondering if there’s some other way I should or can be doing it.

dnolen14:12:31

@adambros there’s no obvious answer to that

peeja17:12:24

Can someone point me to the correct way for a tempid mapping to move from the server to the client? I don't see a way for the send callback to take it. Isn't that where it would go?

anmonteiro17:12:41

Hope it helps

peeja17:12:35

@anmonteiro Ah, cheers. Looks like you're sending it over as :tempids, but I don't see where that key is used on the client side. Is that a key that Om itself knows about?

anmonteiro17:12:58

@peeja: yeah, it's what default-migrate looks for

peeja17:12:34

Ah, got it. So it's well-known by the default, but you can provide your own :migrate that looks for something else. :thumbsup:

dnolen18:12:56

@calvis I was thinking it would be simple for :history to be a number or some IHistory instance, thoughts?

calvis18:12:25

that would probably work for my purposes

calvis18:12:06

ah wait maybe not- it looks like the tx information is gone by the time it gets to the cache

dnolen18:12:28

@calvis I’m fine with widening what goes into history, we drop too much

dnolen18:12:41

history entries could be a map and we could preserve all relevant info

calvis18:12:51

essentially the easiest solution for me would be to also send along tx to the cache

calvis18:12:07

(I have a history of all states but not the reason those states exist)

calvis18:12:42

so that could be solved with a quick pass of tx to .add but it could probably be solved more nicely by having the history decide what gets logged/cached

dnolen18:12:48

I’m also wondering if we should just drop IHistory

dnolen18:12:16

and assume if not number? then :history is IAtom<IVector> and (swap! … conj …)

dnolen18:12:18

then people could just watch and do all kinds of things and I don’t have to worry about it

dnolen18:12:25

I think previously I thought people might want to treat history as both a stack and as hashmap - but maybe shouldn’t really care about the later

dnolen18:12:28

users can index themselves

calvis18:12:00

what about from-history if you don’t have a hashmap?

dnolen18:12:37

like something to convert a vector to hash map? or scan the history looking for a particular entry?

calvis18:12:12

I don’t understand what you just said- I mean the function from-history depends on knowing the structure of :history so it can lookup via UUID, and I think you’re suggesting om.next no-longer dictates the structure and just let users pass their own history in?

dnolen18:12:22

oh right sorry I forgot about from-history being a thing, ok will think about it

dnolen18:12:45

but yeah I’m leaning towards not dictating the structure

calvis18:12:02

seems like IHistory would be a good way to achieve both

calvis18:12:37

w/ add and from-history as methods?

dnolen18:12:33

that does sound reasonable