@thosmos: thanks you for the insight. I am passing a cursor to my reforms forms but data in that cursor has been set prior to the form and in that case it gets erase, in essence I just want to use the form as an update form. What would an "Edit customer" look like?

hi guys, I have a question regarding mutation in om next

will the the mutation function get hit again ( like read ) with new state after the send function gets results from remote ?

is it encouraged to normalize data on the server before sending it to the client? seems to work to send denormalized data and merge it in, but the obj will be bigger

hey james. don’t know the best practice there. what are you doing with om next? i saw your talk on redux with firefox. very cool

@yaniv thanks, much more to come and hope to show off a lot more usage. I'm just doing a side project to solve a need, and good to know these patterns for our work too

yeah om next shares a lot with redux. i’m gonna shoot you a PM to not clog the channel

well, maybe some basic concepts but there's a lot more in om next

yeah. just the single state atom really.. and normalizing all your data. which i guess falls out of the single state atom

@nxqd: I'm not sure, but if your function is just {:remote true}, what's reason to hit it? Seems like mutation function (on the remote parser) is "change state and go", i.e. it doesn't return anything. And after mutation you would need to fetch the changed keys yourself. Even :value :keys don't work, as guys there said it's just for documentation reasons (which I'm confused about still).

how do you handle this example : user > login . You want to check for error returned ?

for now I do handle it in the recursive read function since the read will be hit. hmm I'm confused about the :value and :keys as well. I'm trying to find a way to force rerender after mutation, I thought keys would be the one we need but it doesn't seem to work.

@nxqd: good question. Btw, is it the same for any kind of validation, not just for login form? and yep, seems that you can actually only solve it by reading straight after mutation. and dependant components would be re-rendered then, woldn't they?

though, well... error for particular user is client-only sate

also, see: https://github.com/omcljs/om/blob/master/src/devcards/om/devcards/autocomplete.cljs#L49

...just wanted to say: that's how you can receive data from the server, but that's just "read" they're doing

@andrewboltachev: I mean I want to check the response from server.

@nxqd: but is login operation a mutation operation? from server point ot view?

yes it is

the problem I encounter is : for example I mutate 'user/signin ( I have this mutate on server and frontend as well )

I got results into 'user/signin on my application state. And of course all the read function would be hit again this time, I manage to get the data out just fine ( I think it would be cleaner that we can get the data in the same mutation function on frontend.. )

regarding local mutation, after swap the application state, it doesn't rerender the app T_T ( :keys problem you said above )

so, on the server is 'user/signin in the db somewhere?

hmm I haven't tried to read app-db on server . I just care about the app-db on frontend.

what do you mean "app-db"?

hmm, I might misunderstand you. db you mean something like datomic ?

yep, just the database, i.e. persistant thing

'user/signin does interact with db

aha

so your app kinda knows "who's online"

yes

you can check the om-next-todo example for server example

it doesn't work and a bit outdated but all the things are there ( you might not be able run it as well )

this one? https://github.com/swannodette/om-next-demo/

yep I did try to run it

but is there anything like that? i.e. auth

nah

it just a mutation. once you understand how it interact with the server, you can build it easily.

ok, I'll check it out. the only serious thing I did in Om Next so far is this https://github.com/andrewboltachev/html2om and it works w/o mutation just like "autocomplete" example

In the meantime, on topic of "where all data goes etc" there's this video: https://www.youtube.com/watch?v=IlNrmKYA7Ig

I didn't watch yet, but should be worth it

@anmonteiro: Cool, that (applied something similar to your paste last night, which I guess is what you filed as #582) seems to take care of my loss of query on figwheel reload.

@nano: hah, cool! Also whenever #583 is merged you can drop the setPrototypeOf line

I don't have a good feeling about how typical it is to "transform" queries before sending them off to the server. do servers typically handle "raw" UI queries, meaning it knows a lot about the various keys used by components in queries, or is it typical to convert queries into a simpler format before sending them off to the server?

my impression is that usually they aren't transformed, but that seems like the server ends up being aware of the component structure? guess I need to keep building this and feel it out

@anmonteiro: Problem is that it resulted in another problem. I have :categories that I parametrize to fetch different XML urls, but now that I keep state, it won't fetch more than the first one. Need to figure out how to store the results based on the params instead, or perhaps more crude.. just nuke data when leaving the component.

@nano: or also gather-sends, queue-sends! and schedule-sends! on figwheel reload

would that work?

ok I think I figured out how to do queries in the server, one last question: should I make sure to send back normalized data? otherwise the payload is going to be a lot bigger, but that means the server needs to be aware of the normalization format

@jlongster: it’s up to you what you want to do

letting Om normalize for you is easier of course

@dnolen: ok, didn't know if anyone had any recommendation from experience. but I'll just do what feels right and see how it works!

Does anyone know if it's a good idea to make internationalization (basic translation/different languages) components where the text it needs to display forms the query that gets send to the server?

@iwankaramazow: Hi. We're doing i18n in our app with Om Next. Good idea is relative. Here is how we handle it:

- We use a GNU gettext approach for UI bits (strings that are part of the UI).

- For data the user input, it just needs to be unicode...so no "special" query...it is a scalar string

- For translations the user enters (we allow our user to create a thing that itself is internationalized) then we persist those and need queries.

So, the only time we put them in the queries is when it is persisted data, and in our case we don't need to bother with choosing the locale, since they are editing all of them at once...so multiple fetches make no sense

The first, we will be open-sourcing soon as part of helper libraries that stack on Om Next

We do use modules to load UI i18n strings as a bundle

So, for example, but button might look like (button nil (tr "Push Me"))

where tr is a function that both marks the string for extraction, and displays the translation on the screen

we also made a lein plugin for doing the extraction step

Interesting, thanks for the response!

sure

I wrote about the recent questions / developments of writing reloadable code

https://twitter.com/anmonteiro90/status/690283728350924804

hope it serves as a reference for everyone who's trying to do it

@nano: Also seems like you could make a hot-reload mutation that you could hook to the figwheel callback (e.g. (app/hotload))...that could modify your app state (if you need)...but that results in both load and remote parses. So it could just be a no-op...heck, if you have a "default" multimethod, you could just say anything and it would have that effect.

Well.. my problem isn't any longer reloading. But a problem that existed before, as now that I have reloading I had to add back-navigation in my hierarchy, and noticed that I load data for components with other parameters as my :read only checks if for example :category exists, when the current :category is really (:category {:section "blabla" :view "bleh bleh"}) .. so if I want to open another section, I can't.

So I guess I want my app-state to be more like {:categories {:foo [item1 item2 item3...] :bar [...]}} not sure how to do that though, as the foo and bar are dynamic results from previous reconciler reads.

and I'm also not sure I want to build up app-state indefinitely, I will probably attempt to do that, as it's unlikely that people will browse through the whole app, and going back to an already loaded category is more fun than waiting for it to load.

Also been pondering if I want to introduce DataScript with local storage, and somehow re-fetch the remote data on each access, and if there's a diff -> update the UI. Would be a very nice and fast experience in my mind at least. But I can't even begin to graps how to do that yet.

@nano: before you start "optimizing" with DataScript understand that a query engine is many order of magnitudes slower than raw map reads. Just noting.

All data displayed is read from a remote server - so with local storage it would be faster than that when restarting the app. But sure, during runtime it would be faster to access the data only from the app state. It's not much data though. Each view loads data on somewhere from 10 to 30 items, and each item doesn't have a lot of props.

Don't have the spare cycles to understand your app-specific use-case. sorry.

You could think of it as Netflix on Apple TV or a similar device, for me it's a Swedish Television app on my Samsung "Smart" TV.

That kind of navigation and content loading.

Hello all...just want to make sure my assumption about tempids are correct. In looking at the Om next source, :id-key needs to be in the config of the reconciler in order to take advantage of the merge of tempids to realids. And this is a global identifier for every "entity" in the system correct? i.e. I have a :person/gid identifier and a :company/gid identifier therefore I need a custom merge to map those tempids to real ids. If I had one standard entity identifier, like :db/id, merge would just work...

@tmorten that is not correct

:id-key is just a convenience if you can provide a global id key

the other way is to return enough of the updated entities in your response to rewrite the ids of the original entities

Om Next takes care of fixing references

@dnolen: so if my parser server side is only creating one entity and responds {:tempids {[:person/gid :om/id[]] [:person/gid "realid"}] the tempids wil not get merged until more entities come in?

@tmorten that’s not what I said

@dnolen: sorry, I guess I'm not following you when you say "return enough of the updated entities in your response"...

Om Next has special merging behavior for top level ident values

.i.e. [:person/by-id ...] ?

in the response if you have stuff like {[:foo/id temp] {:foo/id real}}

these will get merged in

so if you cannot use :id-key do this instead

@dnolen: I'm tracking now. Thanks.

to summarize

:tempids is about fixing links

other pointers

:id-key is about fixing the original entity

@dnolen: Not gonna lie. Sometimes the Om.next source code makes my head/eyes woozy. Nice work for sure.

if you cannot use :id-key you have other options

at least you can rest assured there’s 95% chance I’ve already considered all of your problems

So to sum it up: If in my mutation say {:value {:tempids {[person/gid temp] [person/gid real]}}}, I'll be golden?

again that's not what I said

that will only fix pointers to the old id

@dnolen: I've been up late so forgive me 😞

idents pointing to that entity will litter your application state

those we can identify and fix

because queries tell us this

but how can we fix the id value in the original data

???

:id-key

or your backend needs to pass update information

as I’ve already described above

so I need to send back the entity essentially. That is the one that will be in the top level [:person/by-id ] map, [:person/gid tempid] {:person/gid realid :person/name ".." :person/address ".."}

@tmorten: you don’t need to send back the entire entity

just the new id value

@dnolen: @tmorten We just ended up doing a clojure walk replacement for tempids...they have a type, so it is trivial to rewrite them all at once safely.

also alleviates needing to know the ident keywords

that’s also possible in some cases

using the query means less work since you look at less

yeah but the responses are not frequent on a user time scale...so don't mind t aking the perf hit...js vm is fast

enough

it just depends

@tony.kay: what made you go that route?

already seen cases where the few places where we walk blindly is a perf problem

but yes - plenty of apps where this isn’t going to be a problem

@tmorten: It alleviated all of the problems with possibly having more than one id key on state objects. Also, our app state is not huge, so the performance implications are fine.

also simplified the server/client comms, since we can make tempids be something simpler (just the ids, no idents)

tempid migration is an intentionally pluggable thing - so if clojure.walk works for you there’s nothing wrong with doing that instead

@tony.kay: I haven’t thought about it enough, but I suspect process-roots would ideally be generalized into some sort of clojure.walk like thing that also lets you pass context monadically during your walk and return that with the transformed result. I believe if you had such a thing, the current behavior could be implemented on top of it.

@noonian: Not sure it would be very easy to understand..don't really want to think abt it

not using process roots either, it turns out

@tony.kay: no problem

@tony.kay: makes sense.

FYI, I'm going to clj west...if they have breakout sessions I'm likely to offer giving an overview of how we've used o.n.

so anyone interested in seeing some early production code/use cases might find it interesting