Ipfs-webui: Reported MFS size can be bigger than the size of repo

[lidel]

cc https://github.com/ipfs-shipyard/ipfs-webui/issues/1042, https://github.com/ipfs-shipyard/ipfs-webui/issues/629

MFS can store files in "lazy" fashion, which means root is added to MFS, but children are fetched lazily, on first use.

Example

English wikipedia mirror is ~650 GB. Lazy pointer to it can be added to MFS instantly via:

$ ipfs files cp /ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco /en.wikipedia-on-ipfs.org

Problem

This feature of MFS creates a problem in WebUI, it looks like "Files" take more space than "entire repo":

This will become a problem when we start taking advantage of this lazy mode in website cohosting (discussed in https://github.com/ipfs-shipyard/cohosting/issues/6)

Solution?

We need to change the labels, make them more informative.
Below is a quick mock that illustrates what additional information needs to be conveyed.
The problem is that it does not look good, and we need to clean this up somehow.

Thoughts?

[ericronne]

A few ideas which hopefully reflect the state of affairs accurately …

A - Modify two labels

Change the third and fourth labels to "all blocks" and "local repo" respectively, to help explain why the "files" number might be larger.

B - A plus a hover-triggered explainer panel

Add a feature which offers the user text explaining more about the numbers

C - A plus a click-triggered panel

Similar to above

If B or C seem worthwhile and tests well (test? yes let's!), i'll design the full panel. If _none_ fit the bill, we can try something else …

[lidel]

I'd go with B or C: we _really_ need an explainer for these values.
We already have a lot of whitespace on the top of Files screen, so B may save space, but I have no strong feelings here.

@ericronne small clarification: value behind blocks is "the number of blocks" (I have over 600 000 of blocks in my repo). The all blocks label suggests value represents total size used by blocks, but that value is already under local repo. Perhaps we should rename "pins" and "blocks" to something like # of blocks and # of pins to make it clear its not size, but a number of items?

[ericronne]

I wonder if simply removing all would help.

B

C

C feels more user friendly to me, but creates slightly more visual noise.

[lidel]

Yup, dropping all is better :+1: I also would go with C, just for clarity's sake:
B introduces problem of having and pretty close to each other.

[ericronne]

Do we have a panel design? If not, I’ll handle...

[lidel]

Not sure: we have a similar expandable thingy (▶) on _Settings_ screen:

when clicked it expands inline:

We probably should have consistent design in both places (keep/update both), or change > to something else

[hsn10]

I dont think this is a bug. It maybe confusing and need some UI adjust but behavior is correct.