Fork me on GitHub
#om
<
2016-01-27
>
geraldodev01:01:00

Hi, I'm using defui inside a let block that defines a table-name variable. I just saw the dnolen talk that said that om.next defui don't have props on declaration to not risk confusing closures. First sorry my misundestanding of the implications of that declaration, and may me ask: Am I taking the same risk old om did by issuing a defui inside a let block ?

jlongster01:01:31

woo I have a fully functional server capable of running many queries against a SQL database https://gist.github.com/jlongster/570a9249e8648ed73a9a

iwillig01:01:06

@jlongster: looks really good

jlongster01:01:28

I'll post the code at some point, need to clean it up. also not a goal to do anything too sophisticated.

dnolen02:01:25

@geraldodev: using a def anything anywhere other than in a top level let is not recommended

dnolen02:01:17

and I don’t personally even really have much appreciation for the top level let pattern

teslanick02:01:18

I'm having a hard time grokking normalization in om.next -- I'm noodling around with an app that starts with an empty state and loads a bunch of data that should get normalized like the second tutorial, but I'm not sure how to go about it.

dnolen02:01:31

@teslanick: it might be easier if you can describe what about normalization you’re getting stumped on

teslanick02:01:14

Sure: In the normalization tutorial the app loads a map and normalizes it. Do mutator functions that insert new data provide normalized or denormalized data?

dnolen02:01:44

they work on the raw state value which will be normalized so it’s your responsibility to deal with that

dnolen02:01:55

i.e. no, we don’t normalize for you

dnolen02:01:27

auto-normalization only happens when loading the initial data or getting new data from remotes

dnolen02:01:11

as general rule the answer to the question “does Om do this for me?"

teslanick02:01:30

Ok, I thought so, but I wasn't sure.

jimmy04:01:57

@tony.kay: I have fixed the problem yesterday. It was the messed up path. I pass down the props indirectly like this (child {:value child-props}) while I should pass it down like this (child child-props)

teslanick05:01:42

Thanks for your help -- I got it sorted out.

jlongster05:01:40

holy cow om/process-roots just clicked for me, much easier way to transform queries for the server

jimmy05:01:28

@jlongster: you can briefly tell me what it does

jimmy05:01:32

haven't touched it yet

jimmy06:01:36

hi guys, I encounter a problem regarding using core async to communicate between om components. I don't pass props through the channel, in this case, I just send and event to a component, then the component can transact its own states. The problem I have is, the state getting through (om/get-state this) in the go block ( I create a go block in componentDidMount ) is out dated. How can I fix this kind of problem ?

nblumoe09:01:20

When rendering two different views of an entity (e.g. a list view item and a details view of a User) and the two corresponding components have different queries (as they need a different selection of attributes from User), how should the queries be passed down to the Root component? Should Union queries be used in such a case? Is there another recommended way of doing that?

tawus09:01:21

@tmorten: initLocalState seems to be the right place to initialise component local state with properties.

tawus11:01:47

@andrewboltachev: Any progress with routing. It is the last part of the puzzle before I start a fresh project in om.next.

tawus11:01:09

I am still not sure if set-query! is the correct way for routing, (atleast the way some of us are using it doesn't seem the best way). I see you have been working on it. So, I wanted to know if you have found a better way of doing it.

andrewboltachev11:01:16

In fact, great progress with it

andrewboltachev11:01:25

and I used exactly it

andrewboltachev11:01:51

haven't shared my experience yet so let's do

andrewboltachev11:01:20

I'll prepare a project in ~20 min

andrewboltachev11:01:42

hey @tawus it takes a bit more. I'll share link to the repo in a second

mrjaba12:01:05

Perhaps a silly question - how do I get om.next to perform a query only when I hit a button.. passing some text from another input field? currently as the user types I am updating the component local state, then when they hit the button I add it to a parameterised query, which is when I want to run the query (hit an API). However updating the local state causes a render and hence the query to be run every time a key is pressed.

mrjaba12:01:36

Do I need to read the value from the DOM only when the user performs the click? Just seems like there should be a nicer way

andrewboltachev12:01:14

@mrjaba: Do you mean new "local state" feature by "component local state"?

nblumoe12:01:54

@andrewboltachev: thx for the repo link. it's not complete yet, right? guess that's on purpose and not just a missing push...

mrjaba12:01:55

Sorry yes, compnent local state

andrewboltachev12:01:56

@mrjaba: And, answering your question: You would most likely read value from the DOM each change, i.e. when onChange is fired then you would do mutation.

mrjaba12:01:22

So I was following the autocomplete example, but instead of doing it onKeyUp I want to do it when the user presses a button

andrewboltachev12:01:08

@nblumoe: Not ready, completing it now, in fact simple_smile

mrjaba12:01:26

so to take the value from the text input field on the button press.. but I was hoping not to have to hardcode the id of the input field.. which I guess isn't too bad, but just was hoping it was less DOM maniupluation/funkery

mrjaba12:01:03

@andrewboltachev: I'll take a look at that link of yours though, thanks

mrjaba12:01:34

@andrewboltachev: So your example is almost exactly the same as what I have.. but isn't yours running the query for each key the user enters? Mine is and I can't see how yours wouldn't be doing the same?

andrewboltachev12:01:09

@mrjaba: Let me check, seriously...

andrewboltachev12:01:40

@mrjaba: In Chrome's "Network" tab I see new XHRs only when I press the button

andrewboltachev12:01:57

@mrjaba: This readf is one I don't understand that good (I've taken it from "autocomplete" example). But I think this is the clue: https://github.com/andrewboltachev/html2om/blob/master/src/cljs/html2om/core.cljs#L89

mrjaba12:01:01

I wonder if it's that local-state part

mrjaba12:01:37

(defmethod read :qc-set/by-gvm-id 
  [env k params]
  (let [st @(:state env)]
    (if-let [[_ v] (find st k)]
      {:value v :remote (:ast env)}
      {:value :not-found})))

andrewboltachev12:01:45

@mrjaba: I know there's some brand-new "local state" feature, but unfortunantely I don't know anything about it

mrjaba12:01:20

that's my current code, but that's semantically the same as yours I believe

mrjaba12:01:40

I think I have it

mrjaba12:01:38

in yours your are using transact! which sets the app state, and in transact! it's expecting a list of components that should re-read after this has been done. In my update, I'm updating the component local state which forces a re-render (and I think re-query) each time it's updated

mrjaba12:01:05

I think that's what's happening, but this is day 3 of om.next so I may very well be wrong! haha

andrewboltachev12:01:08

for me week 4 or so in React, Om and Om Next simple_smile

mrjaba12:01:43

nice, well thanks for your help simple_smile

andrewboltachev14:01:51

@nblumoe: Now I have one problem with the project. Way I did it first wasn't to good, though successful. I want to make it better and I'll figure this out

nblumoe14:01:45

ha, okay. I am struggling quite a bit with getting routing, queries (down to root) and normalization working together properly...

andrewboltachev14:01:16

for me query is nil after I set it

andrewboltachev14:01:30

@nblumoe: My initial, and working solution were query and params functions deriving values directly from URL

andrewboltachev14:01:46

@nblumoe: So, this worked like: (1) URL changes (2) You ping the root component (this set-query!, despite of having no effect, pings it) (3) It derives it's params from current URL, i.e. js/window.location.hash

andrewboltachev14:01:01

@nblumoe: Is your solution better than this crazyness? simple_smile

iwankaramazow14:01:47

next step in the craziness: partial-app-loading trough google closure modules 😉

andrewboltachev14:01:28

I'll be happy to see alternate solutions

iwankaramazow14:01:10

I'll take a crack at this later this week, need to build the rest of my UI first 😛

andrewboltachev14:01:52

yep the same thing... I've started to put this into prod, so, need to continue on

iwankaramazow15:01:54

You aren't worried about the alpha status of Om Next for production?

andrewboltachev15:01:55

Well that's just nominal. I wouldn't do things manually which are already implemented somewhere

jlongster15:01:34

@nxqd went to bed, sorry. a read function can tag various parts of the ast with :query-root true, and om/process-roots will transform the entire query so that all the tagged roots are the new root queries, and it returns a rewrite function that will take the returned data and transform it back into the original structure

jlongster15:01:54

basically, you can easily ignore local parts of the query and just send queries that the server understands

jlongster15:01:06

doesn't seem like process-roots is in the API docs yet

iwankaramazow15:01:28

maybe a basic question but css classes on components are defined this way:

(dom/div #js {:className "splash-container"} "Splash Container")
, aren't they?

tawus15:01:30

@andrewboltachev: Thanks for the example.

andrewboltachev15:01:58

@tawus: Please refer to scrollback here for the details. It's not working the way I want now (and might have non-safe parts, race conditions etc etc in it). Just "sort of works"

tawus15:01:37

Yes, I went through the comments.

dnolen15:01:10

@jlongster: process-roots is not that well tested yet - people need to play around with it more

thomasdeutsch15:01:01

is process-roots a good fit for a recursive query scenario?

tony.kay15:01:34

@anmonteiro: Are you still planning on renaming ref to ident in the source, or did you already do some of that on a PR?

tony.kay15:01:55

@thomasdeutsch: It is ok with them...

anmonteiro15:01:10

@tony.kay: I did it already, if you've found any that I've missed I'm sure David will be grateful for the fix

tony.kay15:01:30

k. I just submitted a PR on merge-idents, and some were missed there, so I fixed them

tony.kay15:01:34

just didn't want to conflict

jlongster15:01:44

@dnolen: makes sense. worked great for me so far simple_smile and you say Om doesn't do much for you...

anmonteiro16:01:26

@tony.kay: Ah I've seen that one. You're all set, no conflicts simple_smile

tony.kay16:01:12

@jlongster: process-roots has a lot of unit tests, but does not flow through union queries just yet. You could look at next/tests.cljs for cases that are proven to work.

jlongster16:01:10

really love how this is coming together

jlongster16:01:25

@tony.kay: have you had to deal with async APIs ever in the read/mutate functions? currently my read function (on the server) returns an object with channels and then I walk through and resolve all of them into concrete data before sending it back to the client

peeja16:01:22

I'm a little confused about how queries roll up. Let's say I have a RootView which renders a TodoList. The TodoList is paginated, so it has query params. In RootView's query, I do something like {:todo-list (om/get-query TodoList)}. When the instance of TodoList I'm rendering changes its query params to go to page 2, how does that change my RootView's query? The query appears to be based on the default, static query of TodoList, not the query of the instance generated in render.

dnolen16:01:23

@peeja: queries changes are not reflected at the root, this is something that will probably shift around as I think about it

dnolen16:01:55

in the meantime set-query! works perfectly fine on the reconciler so you can sort something out on your own

peeja16:01:23

Oh, maybe I misunderstand how it's supposed to work, then

peeja16:01:50

If you were putting a paginated list in the app, how would you construct it?

dnolen16:01:52

@peeja: it works, but not if you want to do some kind of routing thing

dnolen16:01:04

routing is a global problem

tony.kay16:01:17

@jlongster: I have not. Everything async in my stuff is in send. That said, I do sometimes mutate a marker into app state, return remote true to get into send, then leverage that marker to figure out stuff to do that is beyond the base query/tx stuff.

dnolen16:01:22

if you don’t want to do some kind of traditional routing, then it works just fine

peeja16:01:06

I think I'm missing something, then. Isn't the root component's query the only one that actually does anything?

dnolen16:01:44

I would ponder what I said for a while

dnolen16:01:02

A) routing is a global thing, if you want it you will invent problems for yourself which Om only partially addresses

dnolen16:01:16

B) if components just deal with their own queries then you don’t have any problems

peeja16:01:29

I'm confused. What does this have to do with routing?

peeja16:01:58

I basically want to take the TodoMVC demo and make the list paginated. I don't need the URL to change to reflect it.

dnolen16:01:03

@peeja: why does the root view care what the child queries are?

dnolen16:01:23

I’m trying to get you reconsider some assumptions you made above in the question you asked

peeja16:01:57

I thought the root view's query was the one that was sent to the parser. Is every query sent to the parser independently?

dnolen16:01:21

@peeja: right so remove that idea from your mind

dnolen16:01:25

Om is incremental

peeja16:01:41

Incremental?

dnolen16:01:07

in many cases we run queries only where we need them

dnolen16:01:12

we don’t need the root

peeja16:01:42

Okay, that makes more sense, then. But then why include subcomponents' queries in your own?

peeja16:01:47

That's what all the examples do

dnolen16:01:57

think about it

peeja16:01:12

Well, I have, and it didn't work, so I came here

dnolen16:01:30

come up with a design that can work where for initial load

dnolen16:01:33

you don’t collect queries

dnolen16:01:36

again if you stop thinking about trees and starting thinking about graphs

peeja16:01:39

I see. You're saying the initial load does depend on each component rolling up its children.

dnolen16:01:43

you’ll get over a huge conceptual hurdle

dnolen16:01:51

you seem to be fixating on the query as a tree

dnolen16:01:52

not a graph

jlongster16:01:22

@tony.kay: ok thanks. I'm running SQL behind the scenes so all functions are async. Returning channels inside a tree structure and then resolving them into concrete data works pretty well!

peeja16:01:31

Huh? Isn't it a tree? The data is a graph, but the UI is a tree, and so is the query. How can it not be?

dnolen16:01:57

it isn’t a tree

dnolen16:01:08

only is so far as that’ s special case of a graph

dnolen16:01:13

on initial load we start at the root

dnolen16:01:17

after that you can start anywhere

peeja16:01:02

I see. So, once a component has been rendered, Om is keeping track of it.

dnolen16:01:02

gotta run biab

peeja16:01:08

Okay, thanks!

dnolen16:01:13

the whole point of the indexer and the reconciler

tony.kay16:01:20

@jlongster: Oh, you were talking server-side simple_smile Didn't read carefully enough

tony.kay16:01:15

Using Datomic, and transact returns an already completed future, so just leveraging that.

jlongster16:01:01

how is it already completed? if something is async how does it provide a sync API?

tony.kay16:01:24

@jlongster: Not sure on the implementation, but basically it must block internally.

tony.kay16:01:47

there is an async transact that returns the non-completed future

tony.kay16:01:19

so I'm guessing it leverages that and just blocks until it is done, then returns the future...but the future will resolve if you deref it, since the operation is done

jlongster16:01:39

I see, ok thanks. I think it'd be good to have an example somewhere of doing async stuff; non-blocking IO is good for server perf. maybe I can write one at some point.

peeja16:01:04

(Question to the room, since David's gone…) So, then, if the RootView (in this example) changes its params and has to re-fetch data, doesn't it risk getting data it doesn't need? Its query includes the default query for TodoList, which gets the first page of todos, but the TodoList it renders has already changed its query to ask for the second page. Or does get-query on a component which has already rendered skip over queries included from other components?

iwankaramazow17:01:32

What do you mean by re-fetching data?

iwankaramazow17:01:36

remote date or local?

peeja17:01:17

Either, I suppose

dnolen17:01:26

@peeja: it’s your responsibilty to deal with how much you fetch

peeja17:01:27

Remote being more costly, of course

dnolen17:01:35

the FAQ shows a tiny example of this

tmorten17:01:59

This has probably been asked before and searched back though messages, but I'm needing a way to force my entire RootView to update and render again. Is this possible?

dnolen17:01:27

@tmorten: you can call React ‘forceUpdate`

dnolen17:01:42

@peeja: delay loads example

dnolen17:01:46

everything is a variation on that concept

dnolen17:01:02

basically remote return queries

dnolen17:01:08

you can manipulate what you return

peeja17:01:10

I think I may not be explaining myself correctly…

dnolen17:01:14

elision, re-rooting, caching

dnolen17:01:25

everything happens via dealing with remote reads

dnolen17:01:30

as demonstrated by that example

peeja17:01:31

What I'm saying is that after the list goes to page 2, the RootView's query is still asking for page 1

peeja17:01:00

Its query includes (om/get-query TodoList)

iwankaramazow17:01:03

(defmethod read 'test
  [{:keys [query state] key params}]
  (let [st @state
        found (get st key)]
    (if found
      {:value found}
      ;;else go fetch remote stuff
      {:remote true}
      )))
easy example I find myself writing a lot if the result of the query is available return the result from the state, else go fetch it remote

dnolen17:01:27

@peeja: this is assuming the entire root query gets resent

dnolen17:01:29

we don’t do that

tmorten17:01:32

@dnolen: I saw that in React documentation but didn't seem to be doing the trick. I may have it in the wrong life cycle method.

peeja17:01:49

Not even if the root's query params change?

peeja17:01:16

("root" here being any component which renders another component)

dnolen17:01:27

and if you want to the child’s query to get picked up you need to re-consider what I said about with your new understanding

dnolen17:01:42

either you decide to globally manage the query

dnolen17:01:01

or you use some combination of subquery plus letting child components deal with this stuff

dnolen17:01:14

@tmorten: you’ll have to do some spelunking on your own

dnolen17:01:19

we use forceUpdate internally, it works

dnolen17:01:54

it’s also possible to elide already loaded subqueries as I was trying to suggest as hinted at in the FAQ

dnolen17:01:00

merged the PRs from the past couple of days - nice set of ehancements

dnolen17:01:06

thinking about cutting a new alpha

mdhaney17:01:28

This is probably an obvious question, but for some reason it's not clear to me. Does the reconciler only know about idents that are in the current render tree? IOW, when I call db->tree or tree->db, does it only look at the current components to determine which idents to use to normalize/denormalize?

dnolen17:01:00

@mdhaney: it doesn’t look at components it looks at the query

dnolen17:01:21

joins in the query identify where idents should be placed or swapped out for tree->db and db->tree respectively

mdhaney17:01:19

@dnolen how does that relate to idents defined on components?

dnolen17:01:50

@mdhaney: query fragments are tagged with the component type

dnolen17:01:07

when we encounter a query fragment with a component type with a ident implementation we invoke it

mdhaney17:01:58

@dnolen: thanks, I think that clears it up for me. Or at least enough to write some code to test my understanding.

dnolen17:01:02

cut and released 1.0.0-alpha30

cigitia18:01:49

Would it make sense to alter db->tree to accept underscore-containing ident references for its second parameter, as it does in its first parameter? In this Gist below, all tests except Y3 pass in 1.0.0-alpha30: https://gist.github.com/cigitia/29497174e19d71ccec51

raphael18:01:16

Hello, in om.next what is the equivalent of will-mount?

raphael18:01:17

and did-update

tmorten18:01:58

@raphael: Under Object in your defui (componentDidUpdate [this nextProps nextState])

raphael18:01:12

Is there a doc?

raphael18:01:28

Do you think it s a right place to init a jquery plugin on the component?

tmorten18:01:34

@raphael: use that as your guide...defui is really just a "wrapper" around the react component

tmorten19:01:54

I should have qualified that. Defui has a few more features :)

tony.kay19:01:43

@cigitia: Um, your database is in the wrong format for that last one

tony.kay19:01:10

[:x _] means it is not a table,but instead just a top-level value

tony.kay19:01:26

oh wait, I misread

tony.kay19:01:34

you queried on :y

tony.kay19:01:53

I tend to agree that your use-case should work.

anmonteiro19:01:33

@cigitia: @tony.kay not sure if that should work. at that point isn't that the same as (om/db->tree [:a :b] (:y db) db) ?

anmonteiro19:01:09

actually, maybe there are use cases where that would make sense

anmonteiro19:01:34

@dnolen: is this a bug? should we follow the link in (om/db->tree '[:a :b] '[:y _] db) ?

dnolen20:01:46

maybe, a bit too busy to consider it at the moment

dnolen20:01:55

feel free to open an issue to track it for the time being

dnolen20:01:01

but not interested in work yet

tony.kay20:01:57

@anmonteiro: I'm torn. It "makes sense". Say I've written a parser and I reach some point where I want to use db->tree and I've just parsed a join (so my dkey is :y, and key is [:y _]). I could imagine calling db->tree using that key as the data...but you're right in that it is easy enough to just do a tiny bit of logic and make it work.

tony.kay20:01:21

I think I may have hit this already and wrote said logic because this case didn't work...so I'm leaning towards fixing it

anmonteiro20:01:39

@tony.kay: I am also in a duality

anmonteiro20:01:08

It makes sense to write some logic, but... we might also not want to go peek into what's there, right?

anmonteiro20:01:13

the latter being the motivation for db->tree to handle it. Would there be undesired consequences?

tony.kay20:01:35

I lean towards [:y _] being the query

tony.kay20:01:38

not the data

tony.kay20:01:50

causes my eyes to cross to think of it that way simple_smile

anmonteiro20:01:52

actually if we think of it that way, it just doesn't make sense to handle such thing in db->tree. And the example should just be (om/db->tree '[{[:y _] [:a :b]}] db db)

anmonteiro20:01:02

which works as expected

tony.kay20:01:26

right, that's what I meant

tony.kay20:01:22

it's just that an ident is data that can be followed (which is what the function does)

tony.kay20:01:48

so either idents should not be allowed as data, or we should make sure they all work

tony.kay20:01:31

if you put another item in the :x table above (e.g. 3), then using [:x 3] as data probably works

tony.kay20:01:04

in fact it does (just verified)

tony.kay20:01:42

So, I'm leaning towards bug

anmonteiro20:01:47

@tony.kay: right, but an ident is data.

anmonteiro20:01:52

a Link might not be

anmonteiro20:01:12

a Link is probably just a query

tony.kay20:01:17

hmmm...well, if we consider a link to be something different than an ident (which technically it is), I can be swayed back simple_smile

anmonteiro20:01:26

because you allow idents in your normalized state

anmonteiro20:01:30

you don't allow links there

anmonteiro20:01:34

that's my line of thinking

tony.kay20:01:50

yeah, it is query, not data

tony.kay20:01:05

That sways me in a convincing way: not a bug

anmonteiro20:01:08

so I'm actually leaning towards: not bug

anmonteiro20:01:19

link = query, ident = data

anmonteiro20:01:36

actually, ident = data & query

anmonteiro20:01:10

thanks for breaking this down with me. Won't open an issue then

tony.kay20:01:55

yeah, two heads are better than one

tony.kay20:01:02

agreed on not an issue

hueyp20:01:48

hello, is this the correct channel for omnext as well (the omnext channel appears dead?)

cigitia21:01:02

@tony.kay @anmonteiro: Is there necessarily a dichotomy between links and idents, and, even if there is, are all lookup forms that use underscores necessarily links?

cigitia21:01:20

An example of when using underscore idents might be useful within data is an application I’m making. The application stores its state in the default normalized database format. However, some parts of the database must refer to heterogenous types of entities, and some of those entities are singletons.

cigitia21:01:36

The application has two types of tabs (similarly to browser tabs): post tabs and an accounts tab. There can be many post tabs. However, the accounts tab is a singleton; there is only ever one accounts tab. There’s a simplified example of this at https://gist.github.com/cigitia/8bcb34ffe6bda347f1d0 in two versions, db-1 and db-2. (`db-2` is what I would desire.)

cigitia21:01:03

In places where tabs of either type might be referred to (e.g., the current active tab, the sequence of tabs in the user’s order), an ident to the singleton accounts tab would intermingle with idents to post tabs. Using underscores would be very useful in this case (`db-2`), wouldn’t it? It’d allow us to continue using db->tree to denormalize idents. It would also be consistent with underscores’ existing behavior in queries.

cigitia21:01:08

Otherwise, we would have to use a redundant dummy ID key (such as nil) to refer to the single accounts tab (`db-1`) every time.

cigitia21:01:56

In other words, underscores can be useful in data too, not just queries, when idents need to refer to singleton entities.

anmonteiro22:01:59

@cigitia: not sure that logic makes sense. if you have something that will ever exist just once, you don't need to normalize it

cigitia22:01:38

By “singleton entity”, I mean that there’s only one “instance” of its type, though it may still appear in many places. There are many post tabs but only ever one accounts tab.

anmonteiro22:01:41

i.e. just put your tab object directly under :ui.active-tab

anmonteiro22:01:06

right, but it still refers to the same data in your app state

cigitia22:01:08

Even then, things like :ui.tab/order have to refer to it too.

anmonteiro22:01:39

so then just put '[:ui.active-tab _] in their queries

cigitia22:01:00

Well, the active tab can also change; it too needs to be a reference.

cigitia22:01:07

The active tab might be one of the post tabs.

cigitia22:01:22

Or it could currently happen to be the accounts tab.

anmonteiro22:01:25

ah.. this was not clear

cigitia22:01:32

I probably should have left the active-tab part out.

anmonteiro22:01:52

nah, it makes sense to be there

cigitia22:01:52

It’s just another example of when heterogenity occurs.

anmonteiro22:01:59

wouldn't a union query help you then?

cigitia22:01:27

Union queries are great and make this possible at all—neither db-1 nor db-2 would be practical without them.

cigitia22:01:46

But they don’t let us use db-2, at least with db->tree.

cigitia22:01:11

Because db->tree won’t expand [:ui.accounts-tab/by-id ‘_].

anmonteiro22:01:13

that's just because links inside your state are not supported

anmonteiro22:01:26

i.e. links are currently not considered data

cigitia22:01:47

Yep. I’m making the case that they’re useful in data and possibly worth the cost, if there is any. I’ve never really gotten yet why idents and links are considered to be two different things anyway.

anmonteiro22:01:13

I'd say a union query makes sense in this case: just normalize all your tabs under the same :tab/by-id

anmonteiro22:01:29

and either distinguish them by their type

anmonteiro22:01:36

or some other thing

dnolen22:01:47

@cigitia: an ident is something that is in the data, a link is something that is in the query

dnolen22:01:11

two totally different things

dnolen22:01:37

link is just query syntax

anmonteiro22:01:41

@cigitia: I'm sure your problem can be solved by structuring your data differently

dnolen22:01:51

should update the query grammar here I’m realizing

cigitia22:01:03

@dnolen: I see what you mean: the default database format’s grammar is separate from the query grammar.

cigitia22:01:24

Nevertheless, might it still make sense, perhaps, to make idents in the default-database format more consistent with links’ syntax in this way? They already resemble each other closely, and for good reason; they’re logically similar.

dnolen22:01:04

not going to happen

dnolen22:01:12

data is data, query is query

dnolen22:01:19

we’re not going to start mixing these up

cigitia22:01:59

Right, that’s fine.

cigitia22:01:36

@anmonteiro: I’m thinking about how to restructure my data with union queries, and I keep running into a wall. Even if I combine all tabs into a single :tab/by-id, where could the accounts tab’s information be stored, while still being able to distinguish tabs by type in union queries? I already had been using union queries on db-1: e.g., {:ui.tab/order {:ui.accounts-tab/by-id [:ui.accounts-tab/x]}, :ui.post-tab/by-id [:ui.post-tab/x]}}. This does not work on db-2 because Y3 in https://gist.github.com/cigitia/29497174e19d71ccec51 doesn’t pass.

cigitia22:01:44

At this rate, I think I’m going to just leave the dummy ID for the accounts tab in anyway, as well as for similar “single-ID” heterogenous data elsewhere in the database. Maybe it’s for the best; it leaves room for multiple accounts tabs to be open at once anyway, I suppose.

anmonteiro22:01:05

@cigitia: right so you might not need to restructure your data

anmonteiro22:01:15

what I meant was just using the dummy ID, as you call it

anmonteiro22:01:48

but instead of _ or nil, use something meaningful such as [:ui.accounts-tab/by-id :accounts-tab]

cigitia22:01:50

Ah, that sounds like a good idea. Thanks for your help again, gosh.

hueyp22:01:46

are there order guarantees of multiple mutations in a transaction: (om.next/transact! this [‘(t1) ‘(t2)])

hueyp23:01:19

I’m also thinking about conditional remotes mutations … for instance if validation is done as part of a transaction, and that validation can update state if invalid (for display) but if valid we want to follow it up with a remote mutation. it is unclear to me if I should rely on any order guarantees of calling the mutation function (e.g. action thunk is executed before om calls the function to get the remote)

hueyp23:01:37

I think broadly speaking I’m comparing something like this 😜 https://gist.github.com/eyston/057953716bb2dff7c0ef

hueyp23:01:48

feeling out what belongs in a mutate vs not