Open mitra42 opened 5 years ago
The components below typically use either DwebArchive or DwebArchive.mirror to distinguish between three cases - either running against dweb.archive.org or running against a local mirror, and do not render, or do not execute the functionality for other IAUX cases, they fall into a few groups.
I have behavior in click handlers that call back to methods, typically these are navigational..
details/AnchorDownload calls Nav.nav_download,(in non DWeb the renderer emits a plain Ancho)
AnchorDetails calls Nav.nav_details, (in non DWeb the renderer emits a plain Anchor)
Tiles/ParentTileImg can be passed the identifier of the parent, but can also be passed a member, in which case it will figure out the parent - which can involve method calls on the member.
TileImage calls Dweb transports to get the image,
Details/NavWrap.jsx/NavSearchLI has an onSubmit handler going to Nav.nav_search, this is the only one that I believe won't function at all in a non-Dweb context.
Call AJS functionality
This group of components call functionality in archive.js (AJS), that file is complex and interrelated and pushes things onto stacks etc, I can't figure it out, so just use its functions. If someone understood it thoroughly then functionality could be moved into the components.
details/ModalGo.jsx contains AnchorModalGo and ButtonModalGo which copy the functionality from archive.org of calling AJS.modal_go which pops up modal dialogues.
Details/Tabby calls AJS.tabby in archive.js to switch tabs,
ScrollableTileGrid calls various functionality in AJS to implement scrolling and resizing etc. (this is seriously complicated in archive.js)
Dweb only
These components are either only included if parent components are Dweb, or render null
if used outside Dweb. Components could be moved back into dweb-archive, but they are typically included under NavWrap which would create a dependency from IAUX to Dweb-Archive which is to be avoided.
None of these depend on dweb-archivecontroller being required/imported. And I don't plan on fixing their functionality since they aren't even rendered outside of dweb.
Details/DwebNavDIV takes an ArchiveItem parameter
Details/DwebStatusLI, has functionality under click handlers.
details/CrawlConfig has behavior to cycle through the desired state (crawling none, details or all) and as it cycles calls a URL.
Depend on Member structure Several places depend on the “member” data structure or an array of these members. “ArchiveMember” is a class in dweb-archive & dweb-mirror but it can equally well be an Object with the appropriate fields, those fields are the fields returned by Gio’s related items query or by an advancedsearch with the set of fields requested that are sufficient to paint a tile.
The components that use this include RelatedItems, ParentTileImg, TileComponent, TileGrid, ScrollableTileGrid,
I don’t propose change this because any pure IAUX UI that uses these components will need to define a similar data structure or class to the ArchiveMember. Unless listed elsewhere in this Issue, none of these components access methods on the ArchiveMember object.
What is the context for this discussion?
There appears to have been a decision made to remove functionality from components, to make them "display only".
Elaborate on the discussion topic.
In my opinion this is a bit of a mistake, because it breaks encapsulation, i.e. the functionality is removed (in the code) from where it logically belongs, to something at a different level - probably in a different repo, but to go along with that change, I've started this issue to list the places where there is notable functionality in the components I've contributed so it can be discussed what to do with them.
Stakeholders @iisa @bfalling