complexdatacollective / Interviewer

Simplifying complex network data collection.
https://networkcanvas.com
GNU General Public License v3.0
46 stars 19 forks source link

Multiple `Elements` folders are confusing and awkward to maintain. #174

Closed wwqrd closed 6 years ago

wwqrd commented 7 years ago

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 and components we have Elements, 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?

rebeccamadsen commented 7 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?

wwqrd commented 7 years ago

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>
);
wwqrd commented 7 years ago

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.

rebeccamadsen commented 7 years ago

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.

jthrilly commented 7 years ago

@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.

jthrilly commented 7 years ago

@wwqrd are you still interested in pushing forward with this? Just tidying up and wanted to resolve this somehow. Options seem to be:

wwqrd commented 7 years ago

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?

jthrilly commented 7 years ago

Understood. I've bumped it to Alpha-2, where we can think about its importance relative to other things.

wwqrd commented 7 years ago

Sounds fine to me, for the time being lets put anything new straight into the standardish component/container folders (minus Elements)