@johanatan Can you set the value after first setting the element to focussed

that should put the cursor at the end

At trying the om.next tutorials of @dnolen everything works fine in dev mode. But when compiling the files for production with advance optimizations while changing the atom state the following error is thrown:

Uncaught #error {:message "No queries exist for component path (#object[fw \"function fw(){React.Component.apply(this,arguments);this.state=null!=this.vb?this.vb():{};return this}\"] #object[bw \"function bw(){React.Component.apply(this,arguments);this.state=null!=this.vb?this.vb():{};return this}\"])", :data {:type :om.next/no-queries}}

@danielgrosse: need a minimal case please, then file an issue. Thanks.

Hi all, I’m looking for a bit of help with how to write the read functions for a simple app.

The app consists of a select list of partially loaded records, only the ids and names of the items have been loaded. Then, when an item is selected, I want to load the rest of the attributes for the selected item.

This is what I have so far. I don’t know how to handle the loading of the additional attributes for the selected item. Any pointers?

@dnolen what is ::skip used for in the rendering queue?

it seems related to the initial render somehow, but I can't really figure it out

@anmonteiro: implementation detail, not related to initial render

I was digging into the issue 498 and found a few things if you're interested

related to supporting banging on the atom without triggering a re-render

(the thing where "transacting seems off by one"

it only happens when you transact! on the reconciler, not if you transact! on a component

because transacting on a component will add it to the queue

doing it on the reconciler will not, and only ::skip will be there, so it does nothing

(the second time it will transact! because you're clearing the queue then)

@anmonteiro: try with master, the ::skip stuff wasn’t fully baked and I’m no sure why I had logic in there using it when setting up the reconciler in add-root!

don't need to try

this is what I did as well

and it worked

after commenting out that line

hence my ::skip question 😛

the thing is that after removing that from add-root!, it never gets on the queue anymore, so you also don't need to check for it in line 1353

trying it anyways just for the sake of it

OK, double-checked and it's working now

thanks!

cool

@thomasdeutsch: does DataScript not support multiple DBs?

I’m not really interested in adding more features around how the parser work so that would be the last option only (if at all)

this in reference to OM-501

@dnolen: not like datomic does. It is all in-memory.

yeah so this seems to me trivially solveable if DataScript supported that

and I did not realize that it did not

i.e. put client only datums into second db and query across both

or couldn’t you solve with with-db?

in anycase I think some more time should be spent considering how this could be done without changing anything at all

as always if we can fix in the data we want to do that before offering any programmatic solution

At the moment, it is not " trivial to introduce custom stores like DataScript" just because the fact that we have to be able to do database lookups by using the om.next query syntax. My only solution this far is to add shared values - but this violates the premise to have declarative components.

@thomasdeutsch: it seems to me there are many ways to solve this problem for custom store like datascript

and you’ve only offered one possibility

multiple remotes, query-preprocessing, custom parser

there’s tons of functionality to sort through

that said not suggesting you be the one to figure it out

but I’m not interested in pursuing any direction without someone making a convincing argument based on many alternatives

that said the multiple db thing would seem to solve this

I can’t imagine it would take DataScript much work to support it

then you could put client only information into the second one

and feed both into app state

i will work with om.next and will get used to its internals, before i can think of other solutions besides a custom parser or query-preprocessing.

updating local state won't cause a re-render in devcards. is this one of the limitations of devcards not supporting om next?

@dnolen say I wanna get the computed next-props in willReceiveProps, do I have to destructure manually?

@danielstockton: perhaps but what if the user is entering chars in the middle of the string? I really want the cursor position to be preserved. Also the cursor being moved isn't the only issue-- there seems to be some flickering/ extra/ out of sync rendering going on.

Is there anything special you have to do to depend on the snapshot version of om? Just using [org.omcljs/om "1.0.0-alpha25-SNAPSHOT"] results in an artifact not found. Does it have to be something like a checkout dependency to get the absolute latest snapshot version?

Nevermind, cloning the repo, and running lein install works

can anyone repro #502?

getting a really strange behavior

when I use the destructuring syntax: {:keys [foo] :as next-props} in componentWillReceiveProps or componentWillUpdate I get stale props

@anmonteiro: I have this experienced this here as well

the destructuring thing?

Just shoutout to @tony.kay for an amazing om tutorial. I've discovered it like an hour ago and it's been very useful so far!

@jetmind: Thanks. Beware, there are some things that are out of date. I'm working like mad to get through my normal work and get to writing more. Also, if anyone is working on remoting and wants to talk through details, let me know. I'm working through forced remote reads in a transaction at the moment.

@dnolen: I think this is a bug: The parser always short-circuits read/mutate when AST target is set to remote. I see the reason for this when running the parser in "local mode", but it seems to me that is should only short-circuit when the parser target =/= ast target...if you're running the parser in remote mode, then you want the remote mode read (which is supposed to return the bit of query to send to the server) to actually get called.

Argh, no that's not right either. Well, maybe it is...I hit a problem with process roots that hid what I expected.

@tony.kay: not sure what you mean, need to see an example of what you think is unexpected

@anmonteiro: is OM-502 resolved by the typo fix?

@dnolen: I found some issues with process-roots. Just wrote some failing tests. Will post an issue and PR, then I'll get you an example of the parser thing that I think might be wrong

Ok

Issue #503 and PR #504

@dnolen: So, on the parser, here is the scenario and what I expect.

If I change line 150 to: res (when (or (nil? (:target ast)) (= target (:target ast)))

then it does what I expect

@tony.kay: yeah I’m not really sure about OM-503 - will need to spend a lot of time thinking about it