Closed wwqrd closed 6 years ago
So, are you referring to the "interfaces" with a capital "I" like NameGenerator, or interfaces as in user interfaces (e.g. buttons, menus, checkboxes)? I think I had just assumed Elements was for...smaller functions...or helpers...or something. It sounds like I was wrong, so a more clear name would be helpful, for sure.
Some of the files in both Elements folders access state. If you combine them, would we be more explicit in the file name whether it is a container or component? Or maybe have a container/component division within the upper level folder?
Could it make sense to go the other direction and break things down into smaller folders like Forms, Navigation, Nodes, etc?
Yes, these Elements are intended for direct use in the Interfaces.
I was kind of thinking from the point of view of a contributor making an interface out of our components, without necessarily needing any knowledge of how our state is structured. They could look in a single place for all the components (and documentation) they would need.
For our end-users I imagine they wouldn't be concerned (or want to be concerned with), knowing if something was a 'smart' or 'dumb' component. So I don't think more organisation would make it clearer, or adding Container/Component to the name of every item that is used in an Interface.
So what I'm essentially suggesting is a change from:
import { PromptSwiper, NodeProviderPanels, NodeForm } from '../../containers/Elements';
import { NodeList, NodeBin } from '../../components/Elements';
to:
import { PromptSwiper, NodeProviderPanels, NodeForm, NodeList, NodeBin } from '../../Wigets';
To be used like:
const MyShinyInterface = ({ prompts, panels, activeOriginNetwork }) => (
<div className="my-shiny-interface">
<PromptSwiper prompts={prompts} />
<NodeProviderPanels config={panels} />
<NodeList
network={activeOriginNetwork}
label={label}
/>
<NodeBin />
</div>
);
Not like:
const MyShinyInterface = ({ prompts, panels, activeOriginNetwork }) => (
<div className="my-shiny-interface">
<PromptSwiperContainer prompts={prompts} />
<NodeProviderPanelsContainer config={panels} />
<NodeListComponent
network={activeOriginNetwork}
label={label}
/>
<NodeBinComponent />
</div>
);
I think if there isn't a consensus on this, then we ditch Elements
all together and mix them in with the other containers
/components
until a clearer picture emerges.
Oh I think I see now. So these are the puzzle pieces the end user developers are trying to fit together in their own way. So I think I could get behind this change if we are thoughtful on which components we are separating, but if we aren't clear yet which things the user needs a handle on, I am fine with punting this and mixing together.
@wwqrd as you know, I'm not wedded to any kind of orthodoxy when it comes to project organization. As long as we document where things are, I think your suggestion of merging these makes perfect sense, and you should go ahead and do it.
@wwqrd are you still interested in pushing forward with this? Just tidying up and wanted to resolve this somehow. Options seem to be:
I definitely want this to happen at some point, but don't see it as being vital to the Alpha, perhaps something for the bottom of the pile?
Understood. I've bumped it to Alpha-2, where we can think about its importance relative to other things.
Sounds fine to me, for the time being lets put anything new straight into the standardish component
/container
folders (minus Elements
)
I want to have a rethink of the way our components are organised.
We’re using ducks/containers/components, which seems great.
However, inside both
containers
andcomponents
we haveElements
, which is intended to contain components for direct use in interfaces. I am now thinking is slightly confusing due to it being split across both folders.What I’d like to do is have a top-level (on the same level as containers and components), which contains all our interface elements (container or otherwise).
Are people cool with me making this change - any suggestions on what the folder should be called?