Fork me on GitHub
#om
<
2015-11-25
>
Oliver George05:11:10

Am I overthinking this: let's say I'm modelling Cludo: I have people, weapons and locations. I can make components for each of these using (defui ...) with om/Ident and om/Query. Happy days. What I can't see is how to declare the query or ident for a component which displays information from, say, all three (Ms Brown in the Conservatory with the Lead Piping).

Oliver George05:11:07

Can someone point me at an example of something vaguely related please.

Oliver George05:11:55

This seems logical but introduces a non-data related structure into the query

(defui Accusing
       static om/IQuery
       (query [this]
              (let [suspect-query (om/get-query Suspect)
                    weapon-query (om/get-query Weapon)
                    location-query (om/get-query Location)]
                {:suspect suspect-query
                 :weapon weapon-query
                 :location location-query}))
       Object
       (render [this]
               (let [{:keys [suspect weapon location]} (om/props this)]
                 (dom/div nil "I think it was"
                          (suspect-view suspect)
                          " with the "
                          (weapon-view weapon)
                          " in the "
                          (location-view location)))))

kevinmershon06:11:06

@dnolen: Figured it out. In order to observe a ref cursor and not see the No protocol method IRenderQueue.-queue-render! error, the atom has to be passed to the om/root definition. I had replaced the om/root definition with {} assuming that since I was using observers I didn't need to bother with the root having a state reference. Clearly, not the case.

artemyarulin06:11:57

Hi everyone, learning Om next. I have a legacy wsdl 😞 and rest services and using datomic is not a choice unfortunately. Any tutorials/articles/best practices/examples/helpers how to parse omnext queries into calls for those services? I guess it shouldn’t be that hard if I limit the amount of functions supported, for example without joins, etc.

danielstockton08:11:42

@olivergeorge: What do you mean by non-data related structure? Looks about right to me

danielstockton08:11:56

i think the query should be a vector though, queries are always vectors

wilkerlucio11:11:31

is it possible to send extra environment information to the local parser? I need to call an external function during my parsing process (in some mutation parts), I can on my tests since it's easy to set custom env there, is there a way to send extra env vars to be available on the parser at the reconciler?

danielstockton11:11:40

wilkerlucio: yes, you can pass anything as the environment

wilkerlucio11:11:59

@danielstockton: how I do that for my main parser on the reconciler?

wilkerlucio11:11:27

I tried adding to the reconciler config, but it doesn't get passed down to the parser calls

danielstockton11:11:36

would that work?

danielstockton11:11:28

i might be wrong actually, i misread something in the docs

danielstockton11:11:31

trying to work it out myself..

wilkerlucio11:11:52

I'm trying here too

wilkerlucio11:11:14

@danielstockton: yes that does the job, thank you simple_smile

anmonteiro11:11:54

@wilkerlucio , @danielstockton tony kay's tutorial also adds a :db-path to the env

anmonteiro12:11:18

I'm not really into the details, so I don't really know how he does it

wilkerlucio12:11:30

actually I'm reading his parsing sources right now, good stuff

wilkerlucio12:11:28

enough of manual data handling on the parser, hehe

dnolen12:11:21

@olivergeorge: why do you need a union for this?

anmonteiro14:11:39

@dnolen: not sure if this is a bug, or if it's even intended

anmonteiro14:11:06

but om/component? has a boolean type hint, though it does not always return a boolean

anmonteiro14:11:12

(when om$isComponent has not yet been defined, it returns nil in cljs, undefined in JS)

anmonteiro14:11:18

which is still false-y, so no bug there; but is the type hint used/applied (not sure of the wording here) in this case?

dnolen14:11:47

@denik I took a look at your example, not completely convinced that should work. Do you have a use case for that pattern?

dnolen14:11:08

@anmonteiro: huh good point, I don’t see how that could actually be a problem but will fix for correctness

anmonteiro14:11:22

@dnolen: just something I realized when looking at what om$isComponent is and where it gets bound

dnolen14:11:37

fixed in master

tony.kay15:11:28

@dnolen: On mutation: Used to be {:value ... :action ...} and action's return was ignored. Then :tempids went on the top-level, and then we realized that those need to be assigned (for side-effect free code) in action...so now return value of :action goes into :result. I think we renamed :value to :keys, and I assume you still intend that to go in the return of the mutation call itself (not action). What is the complete story on mutation now? Specifically: where are we putting :keys? What should go in the return value of :action? I assume the answer to this is "anything you want, but :tempids is a good idea" And the following is a "feature or bug?" question: I notice that default-merge still handles :tempids, but not if they are in :result...you have to restructure the result before returning it from the server (or after receiving it). I guess you could put tempids in the return of the mutate itself still, but generating them always seems like side-effect behavior...so I'm wondering if default-merge ought to be changed.

dnolen15:11:25

@tony.kay: :tempids was never top level

dnolen15:11:32

if something assumes that bug

dnolen15:11:55

the structure of mutation return value is:

dnolen15:11:11

{:value {:keys … :tempids … :result ...} :action (fn [] ..)}

tony.kay15:11:59

oh right...forgot that was nested on value when tempids was added...my bad

dnolen15:11:00

there will be no automatic handling of :result

dnolen15:11:08

since we don’t know what it means at all

dnolen15:11:40

so server-side this may require post processing on your part

dnolen15:11:47

either to elide or to compute :tempids

tony.kay15:11:36

I'm doing post-processing...but seems like if you return :tempids in result from action (which could be standard), auto-merging that into value would be useful as a standard...tempid remapping is always side-effect code.

tony.kay15:11:55

so should always happen in action

tony.kay15:11:24

If you wouldn't mind clarification on :keys and :result. You intend :keys to be "things that have change due to this mutation", and :result (on value, not :action) to be....what?

dnolen15:11:28

just not going to bother with result

dnolen15:11:54

some people might returns futures and not want to bother and have different id migration strategies I don’t know

dnolen15:11:08

and I don’t want to be involved at all

tony.kay15:11:11

no no...you misunderstood the question.

dnolen15:11:11

it’s trivial to handle on your own

tony.kay15:11:40

why would I ever put :result on :value??? Doesn't the result of action cause that?

dnolen15:11:14

@tony.kay: remember I don’t care about the specific of how you want to build your app

dnolen15:11:20

this needs to work for everyone

tony.kay15:11:46

sure. I'm trying to understand intended behavior. That's all

dnolen15:11:13

we put :result in :value map because mutations are top level

dnolen15:11:18

makes post-processing trivial

dnolen15:11:20

if you care at all

dnolen15:11:26

makes elision trivial

dnolen15:11:35

makes adding :tempids mapping trivial

dnolen15:11:13

I don’t care if it’s convenient for some apps to return :tempids after mutation

dnolen15:11:15

it’s irrelevant

dnolen15:11:01

as I was alluding to above people who use Datomic often just return a future for a transaction

dnolen15:11:14

but there are lots of cases where this may be true

dnolen15:11:32

you may later decide you want some other behavior you can accomplish with a bit of post processing

tony.kay15:11:59

my point was that even creating a future is a side-effect

tony.kay15:11:12

guid asks sys time

tony.kay15:11:16

side effect

dnolen15:11:17

@tony.kay: I don’t see how this matters

dnolen15:11:25

it’s in the :action

tony.kay15:11:39

but tempids is in value, which you generate before action

dnolen15:11:02

@tony.kay: ok i see your misunderstanding

dnolen15:11:10

mutations are top level

dnolen15:11:21

who cares when you add :tempids? simple_smile

tony.kay15:11:06

transaction: you mean multiple mutations in the same expression, I take it?

dnolen15:11:57

mutations are top level

dnolen15:11:14

you can add :keys :tempids afterwards

dnolen15:11:40

how this is done really doesn’t matter at all

tony.kay15:11:46

E.g. I might not even be able to DO the real db interaction until after each individual mutation function has run on the server...I might just be collecting up bits of things to do?

thomasdeutsch15:11:59

In my om.next app, i tried to embrace linking and a better db structure (instead of the recursive reader chaos). I ended up to not include function-queries (example: [ (:search/results {:query ?query})] into my root-queries. Also, I ignore readers that are not root readers. With this simple structure i render down my component-tree. Up to this point, it worked very nicely. Is this how it was intended ? i think that db->tree works the same for not datascript users. After all components are rendered, there is missing data (like the search/results) - do i trigger it in my render-fn / or other life cycle functions like did-mount ?

dnolen15:11:08

@tony.kay: that’s a possibility - all I know is that server side you will want more flexibility

dnolen15:11:16

and I’m just not interested in dictating anything

dnolen15:11:48

and because mutations are top level

dnolen15:11:52

there’s really no rationale for it

dnolen15:11:03

@thomasdeutsch: yes that’s how it’s intended simple_smile

tony.kay15:11:07

Yeah, I see now. Systems are usually aiming at helping you "do the right thing"...in this case, since we've completely abstracted the idea of what a mutation does to a higher-level thing there is really nothing more you can say.

dnolen15:11:29

it's very not obvious, you can always include links in your queries that are totally *virtual*

dnolen15:11:41

[:id :name [:current-user *]]

dnolen16:11:02

this should eliminate many many many cases where people believe they need recursive parsing

dnolen16:11:12

“There is no Tree only Graph” - Om Sage

tony.kay16:11:31

yeah, on the recursive parsing...I do need to rework a lot of my examples to that. So many things to do simple_smile

dnolen16:11:39

@thomasdeutsch: I’m not sure I understand the missing data bit, you can put marker values in for that stuff

anmonteiro16:11:52

@dnolen: currently in the Om Next Documentation, set-query! is under the section "Components"; shouldn't it be under "Query & Identity"? should I fix it?

dnolen16:11:43

eventually people will see the the Tree/Graph thing is really, really a big idea. I’m patient! simple_smile

thomasdeutsch16:11:49

@dnolen: what are marker values? by missing data, i simple mean that the reader for the query [(:search/results {:query ""})] is not there in the initial data, so i think i have to trigger it (for example by setting the query params)

dnolen16:11:01

:search/results []

dnolen16:11:32

for DataScript maybe this require something more, I don’t know

thomasdeutsch16:11:44

@dnolen: :search/results [] as part of a query? sorry, i do not understand.

tony.kay16:11:01

@thomasdeutsch: I think he meant as part of your state...markers in your state to indicate "missing data"

tony.kay16:11:24

I use nil, so I can distinguish "no results" from "have not asked the server"

tony.kay16:11:04

your read function can then make a decision about asking for it. If you want to force a refresh, simply mutate your marker value back over top of the state...transact causes local read and gather sends...so that will cause it to ask the server

tony.kay16:11:14

@thomasdeutsch: If you care to share your parser that uses more links in state I'd love to see it

denik16:11:25

@dnolen yes I believe it makes sense for anything you'd want to constantly re-render. Sensor driven visualizations for example. I use it for a microphone input volume indicator. Currently using a manual request animation frame loop that keeps calling .forceUpdate as long the component is mounted.

tony.kay16:11:36

I'm about to convert my main code in om tutorial to that form...be nice to see what you're doing

dnolen16:11:06

@denik ok, will think about it

thomasdeutsch16:11:22

@tony.kay: it is not a matter of parsing... it is simply getting the initial data (the db->tree data) via root-query , then render down the components. That said, i have no clever parser.

thomasdeutsch16:11:25

but i am happy to share a small example

tony.kay16:11:05

@thomasdeutsch: that would be great...I'd like to see the details of what you are doing

anmonteiro16:11:38

1. should a set-query! in componentWillReceiveProps or componentWillUpdate trigger a re-render?

anmonteiro17:11:17

2. is 1. related to @denik's issue?

wilkerlucio17:11:43

on the same topic as @anmonteiro, should a om/transact! inside a componentDidUpdate trigger a re-render? currently it doesn't

dnolen17:11:41

@anmonteiro: @wilkerlucio will look into these issue at the same time

dnolen17:11:14

likely they are all related

wilkerlucio17:11:53

@anmonteiro: I did a dirty hack calling my om/transact! inside a setTimeout callback to get the re-render to work from a componentDidUpdate, not ideal but is doing the trick for the moment

dnolen18:11:16

yeah it’s definitely possible to work around but looking into the real fix

tony.kay19:11:11

Hm. Anyone successfully using om/force? I'm not seeing target on the AST, but not sure if it is my misunderstanding or a bug

dnolen19:11:53

@tony.kay: there’s no test case for it so could be a bug

tony.kay19:11:07

I'll try to track it down...it's weird, if I put just a forced read, I don't even get a gather sends...if I put a local read followed by a force, then I get see the local AND remote parse, but target isn't set...I'll trace it down and submit an issue if it is one.

tony.kay19:11:32

looking at your AST stuff...which looks right to me

tony.kay19:11:16

I think I'm looking on the wrong node...

tony.kay19:11:06

If I have this query: [{:people (om/get-query Person)}] and I do an transact on [(app/f) ':people] which AST node should have the target?

tony.kay19:11:27

I'm assuming the :type :join node of people

dnolen19:11:32

except ’:people is not going to show up as :join

dnolen19:11:38

it’ll show up as :prop

tony.kay19:11:49

probably my misunderstanding...I am assuming transform reads is giving me the UI-rooted query in transact*...but I'm obviously confused simple_smile

tony.kay19:11:32

Oh, I see it in the transact log in console

tony.kay19:11:43

I get BOTH the forced read AND the UI rooted query

tony.kay19:11:16

actually the UI thing is from my local read request

tony.kay19:11:19

wasn't automatic

tony.kay19:11:15

I was thinking that since the local read looks up the full query that the forced remote should do the same, except mark those node AST's with a target

dnolen19:11:00

local read only looks up the full query because we know the component’s query

dnolen19:11:09

we’re not going to guess from keys

dnolen19:11:36

(it maybe we need something here, but I haven’t thought about it yet)

tony.kay19:11:39

ok. Yeah, I was thinking of "force remote" as a "force re-read of stuff I already have", and that we we're going to namespace the keys to tease apart what is what in an abstract sense.

anmonteiro19:11:18

is there documentation on what keys the env param in the parser contains?

dnolen19:11:26

@anmonteiro: we should document what appears there in clients

dnolen19:11:40

but servers can put whatever they want there

tony.kay19:11:45

So, in many cases it seems like the query I want to remote is some dynamic thing on the UI, rooted at the key I'm targeting. I guess I can implement my logic on forced reads to look up the queries on the UI myself if that's what I need.

tony.kay19:11:30

that makes sense, actually, since I might end up with multiple queries, and it is likely only one of them makes sense

dnolen19:11:49

@tony.kay: yes so that’s what I was alluding to

dnolen19:11:59

maybe we need something that will give you the query you want

dnolen19:11:02

the indexer has it

tony.kay19:11:43

In the case I'm working on, at least, I definitely want a query fragment from the UI that will work fine on Datomic on the remote

tony.kay19:11:49

I was expecting my remote read logic to "just work" by looking for that target on the real query...that's why nothing was happening...but had it been there, it would have been quite elegant, because I would not have had to write any more code...the remote fetch logic is the same on initial reads as it is on forced ones....I mean, I could also just revert the node in the local state back to a placeholder during the mutate which would "force it" without force, but that causes flicker

dnolen19:11:48

ah mutability

tony.kay19:11:59

so I was hoping for a way to say "when running though the remote read logic, if it isn't there fetch it, or if the AST says "force read it", then fecth it"

dnolen20:11:56

@tony.kay: the problem is keys don’t necessarily represent identities the way components do

dnolen20:11:01

so you have a disambiguation problem

tony.kay20:11:17

I see that...was just explaining the logic

dnolen20:11:33

ah you can already do this simple_smile

dnolen20:11:54

(om/get-query (ref->any reconciler :foo/bar))

dnolen20:11:46

old me predicted future me

dnolen20:11:30

oh but it depends

dnolen20:11:43

you might want the full-query

tony.kay20:11:54

can I use transform-reads?

dnolen20:11:56

(om/full-query (ref->any reconciler :foo/bar))

dnolen20:11:25

already public

dnolen20:11:28

but not yet documented

tony.kay20:11:42

ok. Yeah, I saw it did what I wanted.

dnolen20:11:12

transform-reads is not public

dnolen20:11:16

can only work on components

tony.kay20:11:50

? I just did (om/transform-reads reconciler [:people]) and it worked fine

tony.kay20:11:21

but "not public" is enough of an answer simple_smile

dnolen20:11:01

yeah transform-reads is not public

dnolen20:11:17

but, I’m surprised it didn’t already work, probably we don’t account for quoted keys

dnolen20:11:37

I forgot I added that behavior for @jannis

dnolen20:11:42

yeah that’s the bug

dnolen20:11:21

this AST stuff is paying off

tony.kay20:11:05

Yeah, I had seen that discussion with jannis, and that is part of why I assumed it would work that way...so you think it is a bug now?

tony.kay20:11:15

as opposed to the way it should work

dnolen20:11:46

definitely a bug

dnolen20:11:54

should have been covered by @jannis enhancement

tony.kay20:11:10

ok...well, then I won't rewrite my nice logic simple_smile

jannis20:11:27

I've not been following the discussions for a few days and the whole story around AST is slightly overwhelming to me. But I trust you guys know what you're talking about 😉

dnolen20:11:43

@tony.kay: fixed in master

tony.kay20:11:18

excellent! Will test it out after lunch

dnolen20:11:16

@jannis the AST stuff is pretty boring simple_smile it’s just to avoid needing to traverse maps, lists, vector, etc.

dnolen20:11:28

trying to use the surface syntax to get to something is a nightmare

tony.kay20:11:14

@dnolen: OK, so back to my original question...where is :target now in that AST?

dnolen20:11:33

it’s on the AST that is quoted

dnolen20:11:39

you can test this for yourself

tony.kay20:11:45

the whole tree, not the node?

dnolen20:11:53

the quoted node

tony.kay20:11:08

ok...didn't see it, but may have overlooked

dnolen20:11:25

possible it’s missing but should not be

danielstockton20:11:24

I seem to be missing something related to tempids and remote syncing, any examples of that? I'm doing an optimistic update and I end up with duplicate items in a list

danielstockton20:11:08

I may need to do something special in my merge fn since im using datascript

dnolen20:11:00

@danielstockton: nobody has tried tempids + DataScript to my knowledge

dnolen20:11:33

stuff like that might require pull requests from DataScript users

dnolen20:11:52

more than happy to take them, but I don’t have time to verify every single feature myself in DataScript

danielstockton20:11:44

don't mind being the first to try, is the general idea to return {:value {:tempids }} from the backend mutate method and then use that in merge to update the state?

danielstockton20:11:54

and what should the value of :tempids look like?

anmonteiro20:11:40

ups clicked enter way too early

anmonteiro20:11:48

anyway, getting an error in master

anmonteiro20:11:13

on transact!

thomasdeutsch20:11:14

@bplatz or @hmadelaine may have tried to use tempids with datascript.

dnolen20:11:19

@anmonteiro: did you clean your build?

anmonteiro20:11:44

I'm getting Uncaught Error: Vector's key for assoc must be a number.,

dnolen20:11:47

@anmonteiro: I have a bunch of devcards that test stuff exactly like that

dnolen20:11:19

@anmonteiro: are you using Cursive?

anmonteiro20:11:34

the error only started to appear after issue 494

anmonteiro20:11:38

(the rendering loop thing)

dnolen20:11:07

@anmonteiro: please include stack traces

danielstockton20:11:53

any examples of tempids without datascript? i can probably make the leap to datascript with that

danielstockton20:11:19

simple is good, thanks!

dnolen21:11:45

@thomasdeutsch: need more information, like how many times does it re-render when you press a key?

dnolen21:11:19

@anmonteiro: please put all the information in one place

thomasdeutsch21:11:28

@dnolen: will rerender 2x for every key that is pressed

dnolen21:11:37

looking at multiple links to correlate code and trace is ...

anmonteiro21:11:49

does the snippet work for you, should I create a gist

dnolen21:11:13

@thomasdeutsch: hrm I don’t see anything obvious, but it should be super easy to see what’s happening by putting a breakpoint in the render part of the reconciler

danielstockton21:11:16

so format of tempids is a map of vector (key/id) pairs

dnolen21:11:04

@anmonteiro: I’m not going to try it until I read it and correlate

dnolen21:11:32

we’re getting to the point where big bugs are diminishing and it’s faster for me just to read the code and stacktrace

anmonteiro21:11:33

I didn't mean does the snippet run

anmonteiro21:11:43

I meant does putting the stack trace in the snippet work for you

dnolen21:11:51

yes, that works

anmonteiro21:11:13

alright, edited

dnolen21:11:30

@anmonteiro: your mutate doesn’t make any sense

dnolen21:11:34

update what is that?

anmonteiro21:11:35

cljs.core/update

anmonteiro21:11:08

why doesn't it make sense?

dnolen21:11:31

I honestly didn’t know that update was a thing, never used it before

dnolen21:11:28

@anmonteiro: your :value is wrong

dnolen21:11:31

it must be a map

anmonteiro21:11:49

was it always like this?

dnolen21:11:00

“always” simple_smile

dnolen21:11:10

what in Om Next has been around long enough 😉

dnolen21:11:20

I changed it before the Conj I think

dnolen21:11:40

adding an assertion

dnolen21:11:47

to avoid cryptic errors

anmonteiro21:11:59

a map of what, then?

anmonteiro21:11:13

I was basing my mutations on @jannis 's kanban thing, which might be already outdated then

dnolen21:11:52

I’ve already updated all the tutorials etc.

dnolen21:11:02

and said it multiple times here

dnolen21:11:18

:value {:keys … :tempids …}

dnolen21:11:36

:tempids is optional, but :value must be a map if supplied

anmonteiro21:11:47

OK that clarifies things. Thanks a lot!

lambdahands21:11:58

@dnolen I’ve done some thinking, and I had an interesting idea that was unrelated to history, but may come in handy for working with the cache. Are you familiar with FM synthesis?

anmonteiro21:11:02

sorry for the waste of time

dnolen21:11:39

@lambdahands: only insofar as it exists

dnolen21:11:13

@anmonteiro: the error is terrible

dnolen21:11:19

there is now a descriptive assertion

lambdahands21:11:50

So there’s a lot of wild math involved that I simply don’t understand, but the general concept is taking a waveform and applying a “carrier wave” to modulate its shape. What FM synthesizers can do is have a base waveform and many carrier waves that can arbitrarily be routed into each other. So I’m attempting to merge two ideas here: a linear “history” that allows us to step forward and back between a series of states, and a set of carrier waves if you will that may be toggled arbitrarily independent of time as you wish. So think of stepping back in time, yet some facts still exist. The big challenge is deciphering whether we’re creating illegal states in the process. Sorry for the brain dump, just wanted to share some thoughts I was having.

dnolen21:11:16

so not a crazy idea and yes that's along the lines that I was thinking

dnolen21:11:59

also playing around conceptually with commute! to correspond to transact!, where in the former you know the order of operations doesn’t matter

dnolen21:11:05

and you can re-apply at will

dnolen21:11:33

also putting transactions into the history so the the commutative operations can be replayed

lambdahands21:11:54

Very interesting. So there would be two kinds of state recall, one that replays the commutative operations and one that doesn’t?

dnolen21:11:13

well we probably need three things

dnolen21:11:33

some way to affect all possible states (the base - the server reality)

dnolen21:11:09

some way to optimistically commit (not commutative)

dnolen21:11:26

and some way to reconstruct a consistent picture if that fails

jannis21:11:15

@anmonteiro: Oh, I should really update the demo simple_smile

jannis21:11:26

Will try to do it tonight

lambdahands21:11:43

That makes sense. I’ll do some more hammock-ing over the next few days. My main concern is when there’s several of those optimistic updates, some of them fail, some do not, yet the ones that do not are dependent on the ones that did. Stuff can get hairy fast.

dnolen21:11:09

@lambdahands: yes that's the problem

marcol22:11:37

I'm new at this, and it seems in line with what is being discussed regarding optimistic updates that fail, although I'm looking for a way to report back to the user that a transaction has failed. So a transaction is initiated, which of course goes through the mutate function, but the transaction on the state fails and therefore I need a way to update the UI to show this error/validation message. A use case I have is that a user updates the name of an entity, although the name must be unique, so I want to show the user that the name is already taken.

dnolen22:11:12

@marcol there’s an open issue for this problem on GitHub

dnolen22:11:24

I have a solution, just need code it up

marcol22:11:18

@dnolen super! thanks!

dnolen22:11:00

@marcol in fact worth reading over the issue to understand how it will work

dnolen22:11:08

basically we don’t want errors to corrupt app state

dnolen22:11:17

but we need to have a way to know they happened

marcol22:11:37

@dnolen will read it, thanks again

tony.kay22:11:52

@dnolen: Yeah, the new code fails to propagate the :target from force reads. The target is produced by the ast creation (next.cljs:768), but you only pull out dispatch key.

wilkerlucio22:11:36

I got again on that situation where I need to render 2 different representation from the same data at the same component level, what I have is one component managing a new object creation on the top, and at the same level I have another representation that needs to display extra info depending on the creation state of the first, this time I can't group into a single parent element because their representations are apart on the tree representation

wilkerlucio22:11:59

@dnolen: I remember that you said that my example on that time was fine if I was willing to dupe some query information, could you please say more on that? I don't got it

jannis22:11:40

@wilkerlucio: One solution would be two separate read keys, both of which internally call the parser again to read and return the same data from the app state.

tony.kay22:11:17

@wilkerlucio: 2 reps of same data...don't you want Ident?

dnolen22:11:42

@tony.kay: probable fix forthcoming to the force issue

wilkerlucio22:11:52

@tony.kay: I have an ident there, the problem is that I can't send the same key to two differnet components

wilkerlucio22:11:48

@jannis: makes sense, I'll try that, thanks

jannis22:11:03

You can still combine that with an ident.

dnolen22:11:22

ok in the middle of adding new awesomeness that DataScript people like @thomasdeutsch are already enjoying

dnolen22:11:34

should kill off any shared usage

wilkerlucio22:11:59

@jannis: I dont understand what you mean by combining with an ident, can you please say more on that?

dnolen22:11:00

and not suffer from the dynamism issues associated with it

dnolen22:11:45

@tony.kay: ok try master for target fix

dnolen22:11:59

(when you can)

tony.kay22:11:15

@dnolen: I get the quote on the query instead of metadata: e.g. {:widget (quote [{:people [:ui/checked :db/id :person/name {:person/mate ...}]}])}

tony.kay22:11:15

That is what I get...is that what I should expect? sorry...getting tired...that is query I get. I was expecting metadata instead of propagating the quote.

tony.kay22:11:35

@wilkerlucio: you are rendering two reps...like a table in one place, a graph in another, right?

dnolen22:11:39

@tony.kay: we need to propagate the quote since this is before parsing

dnolen22:11:56

@tony.kay: I’m assuming you expected it around {:people […]} ?

tony.kay23:11:14

people is what is quoted in the transact

tony.kay23:11:14

if that is the correct result, then I'll work with it...you don't have to explain it further.

wilkerlucio23:11:18

@jannis: yeah, that's very similar to what I'm doing

wilkerlucio23:11:50

in my case I'm using the awesome parsing code that @tony.kay wrote on his om-tutorial, so it looks like this:

tony.kay23:11:05

@jannis: @wilkerlucio I think inventing an ident would be better...can place in the app state as a single thing, and then refer to it directly in queries like [:value [:something :name] ]

tony.kay23:11:25

I haven't written that into my stuff yet...but David has mentioned it several times just today simple_smile

dnolen23:11:49

yes so there was missing functionality in db->tree

dnolen23:11:58

but I just landed it

dnolen23:11:14

[:id :name [:current-user _]] is now a thing

dnolen23:11:23

basically you can inline idents into a query

dnolen23:11:41

[:foo/bar _] has special meaning, it will resolve :foo/bar at the top level

dnolen23:11:55

[:foo/bar x] will do a proper table lookup

tony.kay23:11:03

now the query is {:widget [(quote {:people [:ui/checked :db/id :person/name {:person/mate ...}]})]}.

dnolen23:11:20

@tony.kay: that’s what it should be far as I can tell

wilkerlucio23:11:28

@tony.kay: about your question, yes, that kind of dual representation

tony.kay23:11:55

k. I'll work through the parser and see if it works now...it didn't just "heal", so something is still amiss, but likely in my code now

tony.kay23:11:45

@dnolen: OH....I'm using an alternate remote, not the default name...plain quote is going to cause parser to mark with :remote, isn't it?

tony.kay23:11:08

bleh...or perhaps that is the metadata

dnolen23:11:32

it’s a list that starts with ’quote that has meta on it

tony.kay23:11:41

ok...got it

tony.kay23:11:46

thanks again

dnolen23:11:12

but seriously people should try master with this new link thing

dnolen23:11:18

it should solve a boatload of problems

dnolen23:11:22

I’m excited about it!

dnolen23:11:31

and thanks to the AST stuff trivial to elide

wilkerlucio23:11:03

@dnolen: maybe it's time for a new alpha?

dnolen23:11:13

sure related big change for this though if we’re going to do that

dnolen23:11:19

breaking change for anyone using ref?

dnolen23:11:23

ref? is now ident?

wilkerlucio23:11:06

you mean ref at the env on parser?

dnolen23:11:34

ref? which was never public but that people were using simple_smile

tony.kay23:11:42

um, @dnolen ident? and ref? are not the same. I am using ref? during reads to see if what I'm seeing in the database is a vector of 2 elements that starts with a kw

dnolen23:11:53

ident? is gone

tony.kay23:11:00

I just pulled on master

dnolen23:11:09

still fixing stuff

tony.kay23:11:07

my mass sed -i was premature simple_smile

dnolen23:11:46

@tony.kay: it should work

dnolen23:11:53

I would make sure to clean etc.

dnolen23:11:56

all tests passing over here

tony.kay23:11:01

k. trying...

tony.kay23:11:30

all the client local stuff works on mine.

tony.kay23:11:43

my remote stuff is in flux from the quote thing

dnolen23:11:00

cool, thanks for the feedback

tony.kay23:11:33

somethings different on mutate

tony.kay23:11:32

@dnolen: Yeah, that seems to have broken the parsing of a force on mutate

tony.kay23:11:49

bleh...where is good for a stack trace?

dnolen23:11:53

gist works

tony.kay23:11:04

ok...but it turns out it was on my end

tony.kay23:11:11

failed to unquote in syntax quote

dnolen23:11:28

then I don’t need to see that right? simple_smile

dnolen23:11:43

deploying alpha24

tony.kay23:11:33

OK, If I try to call the parser on [(quote {:people [:ui/checked :db/id :person/name {:person/mate ...}]})] (as I walk it)...the parser does nothing (e.g. doesn't call any read). I think because it sees it as a call?

tony.kay23:11:39

hm...it shouldn't see it as a call..I'll trace it down some more

tony.kay23:11:36

Ah, the parser does nothing because target on the ast is now set