src/components cleanup and policy

crkn-rcdr / sapindale

Sapper/Svelte access platform administration interface

2 stars 2 forks source link

src/components cleanup and policy #76

Closed SaschaAdler closed 3 years ago

SaschaAdler commented 4 years ago

src/components is rapidly filling up with things and I'm concerned it'll get unwieldy. I think we should implement the following policy for how to organize it:

If your route component consists of a single component in this directory, and that component isn't reused elsewhere, copy the code in the src/components component into the route component.
If multiple components are needed to build a more complicated interface, and are only used for that interface, they should be collected in a subdirectory.
Generic components that can be used in multiple places should be documented to explain what they do and how to use them. I'm not sure where in the code this documentation should go, but we can discuss.

I think we should all agree on these points before we implement any changes to current components. Let me know what you think.

RussellMcOrmond commented 4 years ago

Does any of this impact any automatic code splitting that might be happening? Is there anything we should be doing to ensure that things are split in a way to keep the footprint on the browser-side clean?

I'm good with the change. I'll want clarity on which subsdirectory for the second point later. (components/subdir or elsewhere).

DivyaKrishnan26 commented 4 years ago

I am ok with restructuring of components as well. Is it a good thing to split the components to a file structure based on the components functionality and relativity? Eg: CollectionEditor goes to/components/Collection/CollectionEditor SlugResolver to/components/Slugs/SlugResolver Just a thought, not sure if it still becomes laborious.

RussellMcOrmond commented 4 years ago

I think a "yes, lets to it" was decided.

It may be appropriate to use this as the time to decide what to do with the /archivalmanifest route, and if a more permanent name should be chosen.

For allowing the "blame" and other history maintaining features to work, I wonder if we should rename the component to the route and modify, rather than cut-and paste the component into the route.

SaschaAdler commented 3 years ago

Closed by recent commits. When I moved "route components" to their route files, Git seemed to understand the process as a rename. I'm also in favour of renaming "Archival Manifest" into "Import from Preservation", at least in the interface, unless for some reason "Import" isn't a verb we want to use there. We can chat about that elsewhere.