You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current explorer has a lot going for it, but adding functionality specific to different ExplorerItem types is getting daunting, plus our approach of merging all ExplorerItem types into one object with paths, locations, etc is bound to bite us later.
What I propose instead is that we put the explorer in its own package @sd/explorer, and rip out any usage of ExplorerItem both in @sd/interfaceand sd-core. @sd/explorer would have no knowledge of how to render its items. Instead, it would manage layout rendering, selection state, data loading, and virtualisation.
To instruct the explorer on how to render an item type, we should make a config object for it containing a bunch of things:
Generic for the item type (eg. ExplorerFilePath, ExplorerLabel)
Components for how to render
Hooks defining how to fetch that particular item (mostly wrappers around useExplorer*Query, gonna be useful for column view since each column will need its own query).
Event handlers (click, focus, etc)
Context menu items
Using this approach we can easily modify the behaviour of individual item types in the explorer, while keeping the ability to render multiple types of items at once (by providing multiple configs at once).
It will also mean that the explorer only loads functionality that it actually needs, as opposed to considering functionality for all item types all the time.
The current explorer has a lot going for it, but adding functionality specific to different
ExplorerItem
types is getting daunting, plus our approach of merging allExplorerItem
types into one object withpaths
,locations
, etc is bound to bite us later.What I propose instead is that we put the explorer in its own package
@sd/explorer
, and rip out any usage ofExplorerItem
both in@sd/interface
andsd-core
.@sd/explorer
would have no knowledge of how to render its items. Instead, it would manage layout rendering, selection state, data loading, and virtualisation.To instruct the explorer on how to render an item type, we should make a config object for it containing a bunch of things:
ExplorerFilePath
,ExplorerLabel
)useExplorer*Query
, gonna be useful for column view since each column will need its own query).Using this approach we can easily modify the behaviour of individual item types in the explorer, while keeping the ability to render multiple types of items at once (by providing multiple configs at once).
It will also mean that the explorer only loads functionality that it actually needs, as opposed to considering functionality for all item types all the time.
From SyncLinear.com | ENG-1565
The text was updated successfully, but these errors were encountered: