[buddypress-trac] [BuddyPress Trac] #7218: Only load component action and screen code when we're on the component's page

[buddypress-trac]

#7218: Only load component action and screen code when we're on the component's
page
-----------------------------+-----------------------
 Reporter:  r-a-y            |       Owner:
     Type:  enhancement      |      Status:  reopened
 Priority:  normal           |   Milestone:  3.0
Component:  Core             |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-patch early  |
-----------------------------+-----------------------

Comment (by johnjamesjacoby):

 I still don't like the changes proposed here, and 1% doesn't seem
 significant enough to me.

 It also seems like a "classes are better" approach that gets negated when
 PHP eventually improves the way files and/or functions are loaded. We'll
 have introduced classes we're stuck with maintaining that don't actually
 do what classes are intended to do.

 I also have a hunch the next bit of code we write to try to mask this
 complexity will probably negate the 1% improvement @boonebgorges found
 above.

 I'm still not convinced this is worth it, but I don't want to be a blocker
 towards motivation and/or progress.

 ----

 What I'd want to see:

 * A base class that provides some value to all these screens and actions
 * Consider renaming classes away from `Action` to avoid confusion with
 WordPress action hooks
 * Consider breaking mono-methods up into ones that: check permissions,
 check the correct screen/action are being called, call a display() method
 for their output, etc...
 * The `bp_actions` and `bp_screens` hooks are already abstractions of the
 `bp_uri` routing system. Is there anyway these classes can talk directly
 to that instead of being stubbed in the way they have been?

 ----

 Because of the functional nature of action & filter hooks, we'll never
 completely get to the point of conditionally loading
 code/files/functions/classes until we include a dictionary of hooks to
 files. Other projects (Woo, EDD) are thinking of trying this, and I'm
 cautioning them against it, too, at least today.

 A more complete, albeit totally insane, approach would be to:

 * Create wrappers for `add_action/add_filter/do_action/apply_filters` and
 hook everything into a central routing system
 * Listen for hooks to be executed
 * Magically include relative files just-in-time as their relative hooks
 are called

 To do this, we'd probably want to:

 * Create a script that generates an autoload-stuff.php file, based on what
 functions are hooked in where and when
 * Add that script to our grunt build process, so it stays up to date as
 new things are hooked in
 * Include that autoloader, which is basically just a big array of files to
 function calls

 ----

 My above hunch of overhead vs. value applies to the proposed patch and my
 terrible idea. After introducing this extra code complexity, what does
 BuddyPress (or it's community of users/developers) gain? Is anything
 actually easier to use/understand? Have we increased performance or
 reduced consumption by more than what it took to support it? Are these
 classes easier to interact with? Have we architected an inviting
 environment to increase BuddyPress adoption?

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7218#comment:53>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac