Separate components from service/features

[aubreypwd]

The way you are supposed to build features/components out is that each component should work somewhat independent of one another. Pulling in another component into another creates a dependencies between the two.

So the way I've been doing it is that there is always a conductor of sorts that connects all the components together and is usually the base feature class that does it, and this is usually what builds out the main feature of the component....

E.g. in a component called example it's class-example.php that does the conducting and uses the various other components creating a dependency with most other components.

All this said, I'd like a way to identify it as so somehow. Idea(s):

• You create a component called components/conductor/class-conductor.php

The attachment would look like:

new Conductor()

This doesn't make sense actually because you could have many conductors, maybe we do:

• You have both components/ and features/ folders. features/ do the conducting (maybe name conductors/?) and use the components/ which have less dependencies.

I LIKE THIS!

Will have impact on #7

[aubreypwd]

Per a call with Eric, this structure may work with more modern PHP frameworks:

Eric's point is that service in the PHP community and components also works for the same thing. My pushback was that a "component" should have one class, but the way I'm doing it you could use multiple classes, so we went with component.

Ping #7 and #10

[aubreypwd]

Some notes after talking to Jeremy:

• features is usually a name for testing things in PHP community
• components could also be packages (not as in a name, but as in a concept, and should be installed like so via composer). Note, the structure would allow for it, we would need to get composer to install things there
• Expecting a src/ folder (not sure I would want to do that)
• Directory structure is not deep enough (we're intentionally steering away from deep structures to reduce complexity)

[aubreypwd]

• The official name for "components" can be components/ but maybe make this filterable so someone can name it somethings else?
• The official name for "features" should be services/ but can also be called features/ for backwards compatibility
• The includes/ folder should be renamed to app/ as in #11

So what you end up with is:

• services|features/ (can either name services/ or features/ but services/ is what's right be default)
  • name/ (e.g. migrate-subsite)
    • class-name.php (e.g. class-migrate-subsite.php)
• components/
  • name/ (e.g. cli)
    • class-name.php (e.g. class-cli.php)
• app/
  • class-app.php (always this name for the app() function)

Note some interesting changes w/ Namespace thinking:

• components/ should be namespaced independent of the plugin framework so they can be mobile
  • Document this in the folder that they should be attached by their root namespace or using a use statement in-file
• services/ should be namespaced the same as the rest of the plugin framework