Clojurians Log v2

Just playing with app.basic-ui. My understanding is that the same keyword is sometimes used as an edge, and sometimes as the the id value in an ident - for instance the keyword :friends (and :enemies). Perhaps it would it make understanding easier if there's some differentiation, so two different keywords used, for example: :friend-edge and :friend-id?

@eric.shao contributions welcome. I don’t personally need react native, so I don’t have a lot of motivation…unless you want to fund such an effort 😉

@claudiu I didn’t realize merge alt unions it didn’t work on the server. You can open an issue. The server-side rendering could use some love. It is low on my personal priority list, but I’d be glad for help cleaning it up. The whole satisfies, implements, etc story between server and client is fun.

Ah great new, I'll keep an eye on that issue. We've disabled pathopt before to try and avoid problems with our query struture but for our app the performance hit was too high.

@gardnervickers Oh! that’s great news

you should comment on the issue to encourage a fix

#876

stay on the older version for now, as long as it is working for you. I assume you’ve moved transacts towards the root as a workaround for the errors

I was trying to reproduce the issue yesterday but I didn't make much progress.

which are: “no queries found…” and index OOB exceptions on reconcile.

Unfortunately, recent versions of Untangled were clamping pathopt to ON

even though there was an option to turn it off

BTW: I’m in a Starbucks in the middle of Montana at the moment on a road trip. Need to head out soon.

Ah nice enjoy!

@wilkerlucio Hm. Did you resolve that?

I didn’t change anything except pathopt…it should not have caused any regressions.

Not so much edge/join verses table, but edge/join verses what goes into the second place of an ident. In your example :friends was used as both.

OH, I see 🙂

yeah, using keywords as IDs can be confusing I guess

I quite liked :the-one!

let me think on that some. Perhaps a careful naming update on that guide would be good. Perhaps even doing something silly like starting every ident table name with TABLE. 😄 I knew he was :the-one!

table.people/by-id

Then also join.people and id.people.

hm. less loving those 😕

If you’re looking at an app state, idents make it obvious what is a join. In a component, the query makes it obvious. Not seeing the need for a naming convention in general on those

but at root, those get confusing

Not so much a convention I was thinking, just to help people when they see :friends used in many different ways for the example.

so, this is only really a concern on the root node. How about :root/prop-name?

move the root-level props “out of the way” so to speak…then all that’s left is tables.

@tony.kay 'The whole satisfies, implements, etc story between server and client is fun.' Is there anywhere where I can find this working, or how should I go about solving this ?

@claudiu Read om/next.cljc. There are a few places where it is split out.

@tony.kay: I was able to get around it, it seems something odd is going when the root component requires only keys not present on the data, my fix was to add a :ui/react-key at my initial state, so it always have at least this one present, I might have some time to look on it later and try to pinpoint more exactly whats going on

ok 🙂 will try to see if I can get it working. Got a bit stuck on that one since I was expecting it to work 🙂

@claudiu Sorry about that. As far as I knew it was.

So :root/prop-name means it is an edge used on the root component? Just :friends the id part of the ident. I supposes there is no ns used for :friends, so its available...

I have seen cases where an empty db causes db->tree to not return data for a node. Never heard of that causing problems for root, but I guess if your query gives back nothing, then shouldComponentUpdate might prevent a render? But not an initial render 😕

weird

:root/ means it is off of the root node as a prop OR edge

everything else would then be table names, since nothing else could get there

unless a load loaded something there without that prefix, but I generally :target loads so I can use something convenient for the server naming in the load query.

[:person-list/by-id :friends] [:person-list/by-id :enemies] was how I understood it. So here these keyswords are not tables, not joins/edges, they are ids.

yep

idents are always [TABLE ID]…the assoc-in, update-in, get-in path of the entity

Yeah I know - was just saying to help with understanding for people.

right, and if the root edges were like :root/friends it would be clear, since there wouldn’t be a name collision

the ID could still be :friends

@tony.kay Will add a issue and in the meantime try to see if I can find a fix. Really slow progress (wedding in 2 months is killing my free time & I'm new to clojure). But would love to help out with untangled if I can. Thank you 🙂

True - just have a difference is all that is needed.

yeah, and I’m trying to solve the other issues I’ve been wanting to help ppl with: stomping on root props/edges with loads, and making the app state a little easier to read from root.

You look to one :friends, then look to another, you want them to mean the same thing.

yep. I gotta hit the road. Happy Untangling!

np thanks! :simple_smile: