Use autoload instead of require/require_relative

[jhollinger]

Checklist:

• I have updated the necessary documentation
• I have signed off all my commits as required by DCO
• My build is green

Per #438, start using autoload for some things, and use require 'blueprint/... instead of require_relative in other places. This allows parts of the codebase to be loaded only if they're needed (Extensions, Transformers, V2, etc).

Based on feedback, the logic of autoload vs require is now:

• Use autoload for optional, top-level constants (Base, a future V2, Extension, Transformer, etc).
• Autoloaded files should require any constants they directly reference.
• Errors are an exception - we'll probably have an increasing number of them, so autoload makes IMHO.
• The above rules should ensure that nothing is autoloaded during render, except for errors.

[friscomm]

This autoload functionality is new to me, so this is likely a basic question - why is this autoload separate from the others in lib/blueprinter.rb?

Is it more of an organization thing? Like to avoid putting all of the required autoloads in one massive file?

Or is there some valuable functional difference by putting it here? Do we gain anything performance-wise by separating this out?

Just trying to further my understanding as I'm learning about it :)

[jhollinger]

Yeah, purely organizational.

[lessthanjacob]

I'd be curious to hear your thoughts on whether we should broadly use autoload everywhere, or if we should only focus on code/modules that will end up being optional, or truly "modular" in the future.

I definitely agree that being able to selectively (lazily) load functionality in future updates will be a fantastic add, but I imagine we'll likely find ourselves in a place where there's still consistent, essential dependencies (e.g. Blueprinter::Base will always leverage View). In those scenarios, I'd argue that require captures the intent more, and should be preferred over autoload.

Additionally, while our performance/efficiency margins are small within this gem, it's worth noting that we're optimizing for a smaller memory footprint and reduced start-up time at the expense of the first render. I'd argue that start-up time is less important than time to first render in the context of a production application, but I think there's a balance to be made here.

Essentially, my TL;DR here is that I think we should still use require for core dependencies, and focus on leveraging autoload for optional/modular functionality (the pattern for this might not be apparent yet, but we could always revisit in the future).

All that said, I'm open for to this approach if we're comfortable with the tradeoffs, and it aligns with our longer term vision.

[lessthanjacob]

Instead of adding another module, how do we feel about pulling forward this change and providing the configuration hooks in Blueprinter directly?

Same general intent, but I don't think we need to encapsulate this in another module. That said, if we feel strongly about this, I'm supportive!

[jhollinger]

I'd be curious to hear your thoughts on whether we should broadly use autoload everywhere, or if we should only focus on code/modules that will end up being optional, or truly "modular" in the future....

@lessthanjacob I went "whole hog" b/c I didn't love the idea of loading things two different ways. You make good points, though. How about:

• Base
• V2 (or however that shakes out)
• Extension?
• Errors:*?

[jhollinger]

Updated with a hybrid autoload/require approach (see updated description).