Closed Gregg8 closed 9 months ago
Thanks @Gregg8 for spotting this.
Can you please confirm if the paths returned by devtools in issue 1(Vectors can cause incorrect path to be generated) and issue 2 (Sets can cause incorrect path to be generated) are correct?
If you are running a development version of 10x
you can print the devtools-path
and index
variables on this line. On this line, we conj
the path of a clicked object (index
) to the existing nested path (devtools-path
.) If devtools path is correct, then that line is the obvious culprit.
When you said "paths returned by devtools", I initially interpreted that to mean "paths returned by right-click > Copy path
", so I tested that.
I get mixed results (which might also be useful info when you're working on this):
[:vega/specs :curve-lines]
and I copy the path of layer
, I get ["layer"]
instead of [:vega/specs :curve-lines "layer"]
I am not set up with a dev version of 10x and not sure how much time I have to do that. I'm hoping with all the above detail, you would be able to set up some test data to reproduce the issues.
Note: While testing that, I found another thing I'd consider to be an issue (have added it above):
right-click > Copy path
while I'm nested in the tree, it clears the nested path to empty and returns me back to the full app-db. It should leave the current path as is
- While nested, I get different wrong results (e.g. if the path is currently
[:vega/specs :curve-lines]
and I copy the path oflayer
, I get["layer"]
instead of[:vega/specs :curve-lines "layer"]
This would mean that the issue is in how we merge paths after receiving them from devtools which would point to this line. I will try to reproduce this issue and provide a fix. Thank you again.
After some digging it seems like issues 1(Vectors can cause incorrect path to be generated) and 2(Sets can cause incorrect path to be generated) are an effect of this line in devtools
.
I think the issue of wrong paths is only occurring in sequential collections which contain integers, specifically in the paths of the integers and the values immediately after the integers within the collection. All other paths in the collection should be correct if I am right.
I will push a fix to devtools
to fix this issue.
More details about these issues. In issue 1 - Vectors can cause incorrect path to be generated. I have made the following discovery, Using the data below as a vector:
[:vega/specs :curve-lines "layer" 0 "mark" "size"]
When you click the values in the vector the path displayed should be a number/index. That means, that instead of the following paths
=>
[:vega/specs]
=>
[:vega/specs :curve-lines]
=>
[:vega/specs :curve-lines "layer"]
=>
[:vega/specs :curve-lines 0 "mark"]
I should get
0
, 1
, 2
, (Skipped 3 - explained below) and 4
. This is exactly what I get for this simple vector (Would be different if the vector was nested in another data structure.)
The issue I get is that, when I click on 0
instead of getting the path 3
, I get 0
. This is the issue that I can reproduce and fix and occurs in all sequential collections. As indicated in the previous comment, this is as a result of these two lines 1 and 2
For issue 2, I am polishing a fix to devtools that should include extra code implementation for sets. Sets are not currently handled correctly in the implementation of paths. I have got to a point where path generation in sets works normally unless the set has children which are composite data types like vectors, lists, maps etc. Then, the paths of the composite children will have their position in the set missing. This is due to sets having random order.
e.g Assuming the data below
{:a 2
:c #{2 3 [4 5]}
:b 3}
The current implementation will have the values 4
and 5
with invalid paths that look like [:c 0]
and [:c 1]
respectively. Note that their position in the set is skipped.
I cannot reproduce issue 3 yet and I am still having issues reproducing issue 4 consistently. More details will come later.
The following tasks are highlighted in this issue,
I have attached a PR that fixes most of the issues mentioned above except 2;
Have been testing the items you checked off and they all now look good to me 👍
Expand arrow stops working
Copy REPL command fails
app-db
?app-db
and, assuming you're using a decent size app and not Todo MVC. The UI is now deadapp-db
and you just want to quickly look at all data. Works a treatprint
icon can freeze up the UI for a long time (for a large app-db
)
js/console.log
app-db
as a string somewhere along the waymore...
link, which would reveal the next 100, and so onJust a comment (and possibly an enhancement request), I note that in terms of path inspector nesting, we're a bit stuck in terms of lists. Comparing get-in
with vectors and lists:
Works with vectors:
(get-in [{:a 1}] [0 :a])
=> 1
Not with lists:
(get-in '({:a 1}) [0 :a])
=> nil
I haven't looked up why get-in
works with vectors but not lists. There's probably a good reason.
Since the path in the inspector is used with get-in
, you can't currently narrow down to individual list items, which could themselves contained nested data.
I note that nth
DOES work with lists so perhaps there's a solution here.
Thanks @Gregg8 for the feedback. Some comments on the above mentioned issues:
:max-number-body-items
. This will need a new release in devtools to fix that issue before it can be seen in re-frame-10x. EDIT: ~This should be fixed after this PR is merged in devtools and re-frame-10x~. This has been merged and the new devtools version committed in #356 Tested 1.2.6
:
app-db
branch you're displaying. For example, dumping my entire app-db
took almost 30 seconds. I am guessing there's a point in the code where it is creating a string from the object. Perhaps this is necessary, hopefully notconsole.log.toString
functionapp-db
is pretty much instant to dump to the consoleNote: with our new code in place, I retested Copy REPL command
and it still crashes the browser page
I think I've narrowed down all the issues still open here. Let's open a new ticket if anything else comes up.
I did a rewrite of the popup menu, since it was made of all imperative interop stuff. Now it's standard reagent/re-frame: 9c27b45
My takeaways so far:
"@re-frame.db/app-db"
instead?
Firstly, I must say I love this feature.
Congrats @MawiraIke for doing the hard work!
1 - Vectors can cause incorrect path to be generated
Steps I used to reproduce:
Take for example, this path which I manually constructed and works...
[:vega/specs :curve-lines "layer" 0 "mark" "size"]
(1) I started with a blank inspector and started clicking down the tree...
Clicked on
:vega/specs
: =>[:vega/specs]
Then clicked on
:curve-lines
: =>[:vega/specs :curve-lines]
Then clicked on
layer
: =>[:vega/specs :curve-lines "layer"]
Then clicked on
mark
: =>[:vega/specs :curve-lines 0 "mark"]
This is the point at which it failed:
(2) Starting again (from a blank inspector) I click on item 2...
Clicked on
:curve-lines
: =>[:vega/specs :curve-lines]
Then clicked on
layer
: =>["layer"]
This time it removed all 2 elements before appending
(3) Starting again, I click on item 3,
layer
: =>[:vega/specs :curve-lines "layer"]
Then clicked on
mark
: =>[0 "mark"]
(4) Starting again, I click on item 4,
mark
and this works: =>[:vega/specs :curve-lines "layer" 0 "mark"]
(5) Starting again, I click on item 5,
size
and this works: =>[:vega/specs :curve-lines "layer" 0 "mark" "size"]
So it seems to have a problem with vector/array boundaries when you are already nested down the tree.
2 - Sets can cause incorrect path to be generated
Steps I used to reproduce:
[:curves/processing-step :job/task-ids]
:job/task-ids
correctly produces[:curves/processing-step :job/task-ids]
[:curves/processing-step :job/task-ids :job/task-ids]
3 - The
Copy REPL command
failsSteps I used to reproduce:
app-db
itself4 - Expand arrow becomes unclickable
Steps I used to reproduce:
5 - Current path is erased when you
right-click > Copy path
Steps I used to reproduce:
right-click > Copy path
while I'm nested in the tree, it clears the nested path to empty and returns me back to the full app-db10x Version
1.2.1
Reagent Version
1.1.0
React Version
17.0.2-0
re-frame Version
1.2.0
What browsers are you seeing the problem on?
Chrome