Add URL tags and variables

[dbadol]

Need

Although this explorer front end is made as a single HTML file without dependencies so that anybody can easily download and run it locally, it is elegant and powerful enough for websites to decide to make it their main explorer front end (e.g. beamprivacy.community, beamsmart.net, etc.).

In such websites, the URLs are very often shared between users to show specific results of the block explorer (such as the details of a given block, or of a given contract, etc.).

It is thus necessary, in this new front end, to also put in the URL enough arguments for a given page to be shared directly.

This URL management will make the code a bit more complex but it has many benefits, as already seen with the old experimental front end.

Proposal 1

As a minimum, URL tags such as #blocks, #assets, #contracts, etc. should be used to allow going directly to a given section (and to remain consistent, the HTML sections should have -as often as possible- the same names as the corresponding node query argument).

The JS code would thus detect the tag in the URL, and if the section indeed exists, show it right away.

Conversely, when displaying a section by clicking on the menu, the code should add/update the tag in the browser's URL bar so that this new URL can then easily be copied and shared.

Remarks:

• Tags #blocks, #block, #assets, #asset, #contracts, #contract, #dex would each send to the corresponding section and would query the corresponding keyword (except #blocks which queries hdrs, but we can keep it that way because it's more user friendly).
• The tag #swaps would send to the Atomic Swap section which queries both swap_offers and swap_totals.
• Tags #home or #status are not needed or can be ignored as the absence of an URL tag would always send to the default Home section anyway (which queries both status and the ten last blocks).
• Tag #peers would also send to the corresponding section and query (as per issue Display the list of peers #4).
• With the above, all current explorer node query keywords would thus be covered.

Proposal 2

To make it even more generic and flexible, all URL variables (?var1=...&var2=...) should be automatically passed into the node query. This approach will allow devs and power-users to use all current node options (by simply adding them in the URL), and it would make the front end future-proof for many new options which can be added afterwards to the explorer node API.

By instance, the URL directly linking to the results of a search query or the details of one specific block would use #block?height=... or #block?kernel=... (as per issue #2).

Similarly, the URL directly linking to the details of one confidential asset would be #asset?id=.... To the details of a given contract would be #contract?id=.... Or, the list of assets existing at the time of a past block height would then be #assets?height=....

Lastly, the columns displayed in the table of block headers could also be customized by using #blocks?cols=... in the URL. In this specific case, the front end would have to detect the list of columns requested through the URL and adapt the column filter and the table headers accordingly.

As with Proposal 1, the selection of options through the user interface shall automatically be reflected in the URL, so that this new URL can then be copy-pasted and shared between users. By instance, displaying the details of a given block height shall add #block?id=... to the URL.

On the other hand, this approach allows other advanced node options such as hMax, nMaxTxs, etc. to also be available to power-users, without needing to clutter the front end GUI.

Remarks:

• A special URL variable would be ?network=... (default being mainnet), as per Issue Allow using several networks #3, which is an information used only by the frontend, and not passed into the node query.
• When this URL variable ?network=... is used, the front end shall use the first URL node it knows for that network (if any).
• Note that only the network name can be passed in the URL, not the node URL itself (for security reasons). This means that the frontend will ignore this network name if it does not already know some node URLs for it.
• All of the node queries should always use exp_am=1 (as per Issue Use the newest node queries instead of the legacy ones #8), even if the corresponding variable is not present in the URL.

[dbadol]

This a possible variation, maybe more elegant (and less risky) to avoid having to continuously modify the current URL as we navigate the different explorer pages:

1. At load time, the explorer reads the URL #anchor and ?parameters (that's something that really needs to be added). That way, it can display right away the section corresponding to the #anchor given in the URL. It also use the ?parameters to query the node and apply that config right away (e.g. list of columns, number of lines, step, contract id, asset id, etc.).
2. A small "link" icon appears on hover next to each section title. Clicking on this icon computes and copies in the clipboard a URL (with #anchor and ?parameters) corresponding to the current display.

This way, it becomes possible to share a view with someone (pasting the copied URL will lead directly to the same view) without needing to keep modifying the actual URL displayed in the current browser (which could trigger reloads and other browser-dependent actions).

[dbadol]

Example of a URL which leads directly to a given page (block headers), for a given network ("mainnet", which will use the default node URL if already defined) and with a given set of parameters (here: columns to display -and in which order- and only the totals of the 60 blocks of every hour, over a period of 24 hours, i.e. 24 rows):
https://beamsmart.net/?network=mainnet&type=hdrs&cols=Tfkioyzp&nMax=24&dh=60

Note that all the above can be queried directly to the node explorer and it will give the requested information. The frontend only needs to display it.