This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-21
Channels
- # aatree (88)
- # admin-announcements (14)
- # alda (26)
- # announcements (4)
- # avi (6)
- # aws (7)
- # beginners (80)
- # boot (268)
- # braid-chat (58)
- # cider (4)
- # clara (54)
- # cljs-dev (16)
- # cljsrn (27)
- # clojars (13)
- # clojure (123)
- # clojure-chicago (2)
- # clojure-czech (8)
- # clojure-france (5)
- # clojure-hamburg (2)
- # clojure-miami (6)
- # clojure-nl (5)
- # clojure-russia (285)
- # clojure-spain (2)
- # clojurebridge (3)
- # clojurescript (137)
- # code-reviews (14)
- # community-development (6)
- # core-async (8)
- # core-matrix (10)
- # cursive (2)
- # datascript (1)
- # datomic (24)
- # dirac (2)
- # emacs (5)
- # hoplon (4)
- # incanter (6)
- # jobs (7)
- # ldnclj (42)
- # ldnproclodo (2)
- # leiningen (1)
- # mount (60)
- # off-topic (15)
- # om (134)
- # onyx (65)
- # perun (4)
- # portland-or (2)
- # proton (15)
- # random (1)
- # re-frame (24)
- # reagent (7)
- # testing (4)
- # yada (9)
@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?
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. 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).
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?
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"?
yep, just the database, i.e. persistant thing
so your app kinda knows "who's online"
it doesn't work and a bit outdated but all the things are there ( you might not be able run it as well )
yep I did try to run it
but is there anything like that? i.e. auth
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
@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:
- 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
where tr is a function that both marks the string for extraction, and displays the translation on the screen
Interesting, thanks for the response!
I wrote about the recent questions / developments of writing reloadable code
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.
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.
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...
the other way is to return enough of the updated entities in your response to rewrite the ids of the original entities
@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?
@dnolen: sorry, I guess I'm not following you when you say "return enough of the updated entities in your response"...
@dnolen: Not gonna lie. Sometimes the Om.next source code makes my head/eyes woozy. Nice work for sure.
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?
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 ".."}
@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.
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
@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