https://github.com/omcljs/om/wiki/Thinking-With-Links!

a very short but very important post

Links broken, here's the correct one 😁 https://github.com/omcljs/om/wiki/Thinking-With-Links%21

@dnolen: wondering, this is valid using idents? [{[:current_user _] [:person/name]}]

@wilkerlucio: yep refer to the grammar

https://github.com/omcljs/om/blob/master/src/main/om/next/impl/parser.cljc

cool, going play with it

@dnolen: That does make things nice. I had not been realizing db->tree could be used that way...obvious now!

@tony.kay:

time to rewrite a bunch of stuff

@tony.kay: yeah this is a radical simplification

clientside parsing should really only be about top level keys

I like your comment "pretty boring stuff" at the first sight of db->tree in read.

haha

in fact it’s making me realize we may want to move some this stuff into a .cljc file

"oh, and here is this little tidbit that will change everything...pretty boring, I know"

since it solves a lot of problems for server side code as well

it does

@dnolen: Excellent feature!

wrapping up will look for feedback

happy Thanksgiving people!

happy thanks giving

@thomasdeutsch: seems ok for me. The only thing I can suggest is to check your clojurescript version in project.clj

The new documentation page is just what I was missing!

@dnolen: [:id :name [:current-user _]] is nice. - what if i only want parts of the current-user? like: [:current-user [:id :name :email]]

@thomasdeutsch: I'm guessing it returns whatever the root asks for, so if the root only has [... {:current-user [:id :name]}], you'd get :id and :email.

But that's just a guess.

@jannis: i am talking about the new option to link to a root key - accessing parts of the object is not possible at the moment - as far as i can tell.

@thomasdeutsch: Oh, actually.... have you tried this? [:id :name {[:current-user _] [:id :name :email]}]?

@wilkerlucio was asking whether that was valid earlier and @dnolen said yes.

@jannis: yes, you are right - this is it.

Cool

(And I was wrong thinking it had anything to do with the root query... it's simply reaching into the root of the app state, which is something completely different.)

I noticed that ident queries doesn't seem to be normalized when reading, I did an expansion on the thinking links making the user a component with an ident, it didn't got normalized

As a datascript user - i think i have to reimplement db->tree for datascript. I can not use d/pull as a replacement, simply because [(:my-fn {arg: "x"})] and the new [[:root-key _]] is not a valid pull syntax. I was wandering - why is db->tree not based on the expr->ast from the om parser?

@thomasdeutsch: "As soon as you try to enter a character into the input box, the reader :input-handler will get called twice.” I observe this too. The first read is from the Key press - React event handler dispatch - the second comes from the om.next animate request frame “loop” as it schedules a re-render.

Hello, can someone point me to an example of something similar to the normalization tutorial where the content from :list/one and :list/two comes from a remote? I have a bit of a problem understanding how remotes and normalization plays together.

@r0man: Don't think there is an exact example. Recommend going through all tutorials first, if not done so, as the answer is there. You can checkout the community examples at the end of the page https://github.com/omcljs/om/wiki#om-next Depends on what data format you are working with? The list data that you see in the example can be returned in transit format from the 'remote' middleware side. The normalization happens when the reconciler loads the list data from the :send function in the reconciler. The reconciler will only normalize 'raw' data by default like the example. So, you need a :send function to fetch the list data. I have some simple examples of loading data from a resource file - if required.

@griffio: Thanks, I read the tutorials. Watching tony kays video at the moment. Looks like there is some info in it. I'll come to you back later maybe ...

@r0man: no problem - you are only a few steps from understanding that it is quite simple!

@thomasdeutsch: pull isn’t generic enough to do everything anyway, so how would db->tree using the AST help you? Curious what you have in mind.

@wilkerlucio: I think you mean de-normalized. Yes we won’t do that automatically since we don’t know what that thing is. We only de-normalize if we have a query to drive. So if you want that you need to supply that.

@thomasdeutsch: I’m also thinking you can solve this problem with remotes possibly? This might allow you do divide up the query into parts you can handle and those that need special treatment.

@dnolen: i need to think about it.

@thomasdeutsch: yes let me know what think

@dnolen: I have not looked into remotes at this point, so i do not know how i can embrace its functionality. I also have the option to query the schema for idents, and other crazy stuff - want to get some ideas from this blogpost, too: http://blog.juxt.pro/posts/datascript-dom.html

what does AST refer to in an om context?

the query expression Abstract Syntax Tree

which is the parsed query expression? is it exposed somewhere? as a user of datascript, i guess it's irrelevant

@thomasdeutsch: I also wonder if this is a problem DataScript users actually have

it seems to me you can do this stuff just by being OK with a Schema that’s different on the client from the server

and including client only datums

@danielstockton: it is exposed and is useful even for DataScript users if you have real remote services you need to communicate with

remote services which aren't using datomic where you need a parsed respresentation?

i think in most cases, the client db schema will be different from the server schema - and i do not see this as a problem.

@thomasdeutsch do you just transact what the remote sends back into datascript or do you have a more sophisticated way of keeping client/server in sync?

@thomasdeutsch: right so this feature may not matter for you at all

I never really expected we could just hide details of the store

just that pluggability would be possibility

@danielstockton: in previous apps, i simply transacted the data into the db. but i have not worked with om.next remotes yet, so i do not know if there is a challenge involved.

@danielstockton: the pattern that I’ve seen

@danielstockton: have you tried to convert the example from @griffio to datascript?

so far is that people talk to Datomic, since a lot of the schema is just the same they can transact the entity tree into DataScript

Om Next supplies a :merge hook for this case

@thomasdeutsch: No, but i will when i get a chance. Unfortunately I'm a part time om/cljs enthusiast trying my best to keep up alongside other things

currently my remote mutate methods transact and i return the transacted datums to the frontend, where i have a merge hook which just transacts them

havent solved the tempids problem, still getting familiar with datomic/datascript so im not even sure how i'd update the db/id to match the backend

I’m using componentWillReceiveProps to re-render part of a map (using leaflet.js). However, when I om/transact! to change the data, the transaction works (and I hint a read with {:keys [:my-toplevel-data-thing]}, but WillReceiveProps receives always the previous props, not ones that happen as a result of the mutation. Am I missing something regarding the lifecycle?

if I transact again, then the willReceiveProps gets the “correct” props, just one transact too late

@txus just sounds like a bug

hm, ok, will try to reproduce it then

@txus: you on latest alpha? I have been using willReceiveProps recently and they were OK

using alpha24 yeah

I guess I’ll find out reproducing a tiny example, maybe I missed something

@dnolen: done, here: https://github.com/txus/omnext-willreceiveprops-bug

there’s code and screenshots

very strange, but then again i might be missing something

seem actually that the transacts are delayed always one transact

@txus the example is small enough please just put all of that into a GitHub issue, thanks!

will take a look over the weekend

great 😄

@txus nice colourscheme, very retro

https://github.com/omcljs/om/issues/498

@danielstockton: thank you

@txus thanks

no prob

@griffio: Ok, I watched that video, but things are still not working as expected. I pass a state atom with :normalize true to the reconciler. The state atom contains at the beginning denormalized data. After add-root! it is normalized as expected. So far so good. Now I try to fetch data from a remote via transit and get a list of results (not yet normalized). How do I get this data into my atom in a normalized way. If I just pass that data to the callback it overwrites my previously normalized data in the atom with the demormalized list I got from the remote. Any idea?

@r0man: I pushed the list example you mention but using remotes, two remote lists. Have a look first and see if anything makes sense! Here https://github.com/griffio/om-next-05

@griffio: Thanks, I'll take a look

so I'm also getting @txus 's issue after all

@r0man: you will need to supply your own :merge if you need some kind of deep merge

the default implementation is intentionally naive

@dnolen: Do you mean :merge-tree like here https://github.com/griffio/om-next-05/blob/master/src/om_next_05/core.cljs#L134 ? Or is :merge something else?

ah, ok. I see, there's :merge and :merge-tree

@griffio: I think you might be misunderstanding remotes

looking at your example

You don't list the data keys you want to deal with remotely...you list the remote hosts you want to talk to.

@r0man: I thin you might just want :merge-tree for what you're doing...`:merge` would be a lot more work than you want. I think some renaming happened at some point...hard to keep track

@tony.kay: ok thanks for the pointer understood - the example there is just get data in one single time to merge-tree.

yeah, I just didn't want that misleading anyone else who might go look at the example for instruction on remotes

I'm having a problem transact! on alpha24, looks like the reads in transaction do nothing

Perhaps a problem with transform-reads?

(om/transform-reads reconciler `[(links/like {:link-id "1"}) [:links/by-id "1"]])
; => [(links/like {:link-id "1"})]

Or perhaps that works as it should and I just don't know what it should do

@dnolen: what was the design decision, to ignore [(:my-fn {param: "x"})] in db->tree ? Was it, because query-fns should only be called after the component was mounted (received props?)

If you use db->tree you've bottomed out, should not expect any of that stuff to work

@griffio and & @dnolen: I found my problem with normalization and remotes. My data was coming back from the remote as a list, and not as a vector. Normalization didn't kick in. When returning my data as a vector it's working. '{:spots/list [{:id 1} {:id 2}] vs. '{:spots/list ({:id 1} {:id 2})

Should normalization also work on lists, like the second case?

@juhoteperi: bug

@r0man: no list support

@dnolen: ok, maybe worth adding to the normalization tutorial. do you mind if I add a note like this?

Go for it

@dnolen: I added a note to the tutorial, but I'm curious. Why no list support? Are lists reserved for anything special?

Just don't care about

@dnolen: Okay, I created an issue: https://github.com/omcljs/om/issues/499

Thanks

Does anybody know the React Native or Om way to restore UI controls' values (e.g., textinput text) upon changing back to a previous screen? I tried setting 'value' but then the cursor gets moved to before the beginning of the text after each character the user actually enters in the box [as there's no way to determine if the current render cycle is due to a) changing back to the screen from another 'modal'/popup if you will or b) the user actually entering text]). I tried a workaround where I kept some side state in another atom (that isn't being observed by Om Next) to store whether a screen change was occurring or not and that worked but only for the first render cycle-- if the user did something else on the page after changing back to the screen (like say checking a checkbox), then the side state had been cleared and my logic didn't set the 'value' of the textinput to that stored in app-state. I'm now considering an alternative workaround that should work (i.e., setting the 'value' of the textinput to the text stored in my big atom on every render except those triggered by an onChange event in the actual textbox in question); however, the idea of having 'side-state' in a 'side-atom' seems to go against the Om way.