view data #3
view data #3
Conversation
src/App.jsx
Outdated
| console.log("Data received from fetchData:", response.data.value); | ||
| const take2 = storageHelper.unserializeTxt(response.data.value); | ||
| console.log("DEBUG take2", take2); | ||
| const obj = JSON.parse(response.data.value); | ||
| console.log("DEBUG obj", typeof obj, obj); | ||
| obj.values = obj.values.map((v) => JSON.parse(v)); | ||
| console.log("DEBUG obj.values", obj.values); | ||
| setDataView(obj); |
There was a problem hiding this comment.
Are these console.log's intentional? What's difficult to work out?
I pulled this down locally. For fastUsdc it doesn't seem to render keys that include JSON - only capData. Examples are the fastUsdc root and fastUsdc.status.${hash}. I also noticed the old p2p-agoric-vstorage-viewer struggled with JSON as well.
There was a problem hiding this comment.
They were intentional while debugging. Looks like you were reviewing by commit. They're not in HEAD.
I don't see much value in cleaning those out of the commit history but would entertain the request
There was a problem hiding this comment.
Looks like you were reviewing by commit
Yep, thanks for removing, though.
it doesn't seem to render keys that include JSON - only capData
Was this an observation you also had?
There was a problem hiding this comment.
yes. I want to solve this in client-utils vstorage.js or vstorage-kit.js by making them handle non-capdata JSON and even bare values
turadg
force-pushed
the
ta/2-view-data
branch
from
63953c2 to
bf2b4fc
Compare
Deploying vstorage with
|
| Latest commit: |
bf2b4fc
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://b9380f06.vstorage.pages.dev |
| Branch Preview URL: | https://ta-2-view-data.vstorage.pages.dev |
_incidental_ refs: agoric-labs/vstorage-viewer#2 ## Description In the course of working on agoric-labs/vstorage-viewer#3 it was hard to work with an async `makeVstorageKit`. It was async because construction of the kit required fetching a bunch of data from vstorage to populate `agoricNames`. That concern is a higher level than vstorage so this pulls it out. That allows `makeVstorageKit` to be synchronous. I added a test of `makeAgoricNames` both before and after. Eventually I think something should make it easy to make an AgoricNamesKit that wraps `VstorageKit` the way `VstorageKit` wraps `Vstorage`. `makeWalletUtils` does that but needs more work. At least renaming to `SmartWallet` but it would help to have a rethink of the layering and vstorage decoding in client-utils. ### Security Considerations none ### Scaling Considerations none ### Documentation Considerations not documented but this will make it less complex ### Testing Considerations new test While refactoring, tsc really let me down by not detecting destuctured properies that were no longer on the source object. I suppose our settings aren't strict enough. I enabled `noImplicitAny` to detect those (by then filtering for makeVstorageKit) ### Upgrade Considerations n/a
fixes: #2
I went a little farther since I depend on this tool so much. E.g. converting to Vite from CRA which is no deprecated.
The main UX change is making data render and doing it a little more clearly when it does.
Before
https://vstorage.agoric.net/?path=published.wallet.agoric10yw7lsgqgajcc4veeeua65je79tyeg9x8t6f5y.current&endpoint=https%3A%2F%2Fmain-a.rpc.agoric.net%3A443&height=null
(manually collapsing body children)
After
http://localhost:5173/?path=published.wallet.agoric10yw7lsgqgajcc4veeeua65je79tyeg9x8t6f5y.current&endpoint=https%3A%2F%2Fmain-a.rpc.agoric.net%3A443&height=null
(same collapsing)