Convert author, image, and JSON-LD to dedicated drops

[benbalter]

I began this PR by trying to simplify the author, author_string_or_hash, and site_author_hash methods by moving the author logic to its own dedicated drop with smaller methods.

Having done that, I saw that the image could be similarly pushed into its own drop and that or existing JSON-LD implementation, was essentially a drop (although we were including it in the main class, rather than subclassing it).

In the end, this PR (or potentially three PRs, I made the commits distinct) should be fully backwards compatible, but should move the author, image, and json_ld logic out of the already-very-long Jekyll::SeoTag::Drop and into their own drop-based classes.

A few things to call out:

• I wrote the author drop, such that, it could be pulled out into its own library, and theoretically, be a drop-in replacement for page.author, in that PageDrop#to_s will return the author name, as if it were a string (e.g. via liquid), and it can also be accessed as a hash to retrieve additional metadata, when present.

• The tests pass almost entirely unchanged. All I did was move the tests from drop_spec to foo_drop_spec and update the method calls form e.g., subject.author to just author.

• The integration spec was unchanged, save the order of the elements in the JSON output.

• In the long run, I'd ideally like Jekyll SEO to expose really good drops to the HTML template, and allow users to override the template with their own if they want logic/optimization beyond the majority use case (but have the tools to do so without starting from scratch).

Thoughts? Is this easier to maintain? Harder? Too much for one PR? Won't be offended either way, but wanted to push up the idea.

[pathawks]

@twitter made me look twice. When Ruby and Twitter semantics collide.

[pathawks]

This is fantastic!

I love that you have setup AuthorDrop so it could be easily extracted into its own helper gem.

[pathawks]

If the goal is backwards compatibility, do we need to keep this method as well?

[benbalter]

Drop extended JsonLD (which is where I moved this method to). Theoretically, if someone extended the module into another class, this would be a breaking change. I'll can duplicate it here with a note that it should be removed at the next major release.

[DirtyF]

Seems like a smart move, really appreciate the effort you make to share your vision @benbalter.

The code is more modular and it's great if this helps provide more extensibility to the developers.

Didn't know much about Drops before, but starting to get the big picture.

Best branch name ever on 🔝 of that.

[benbalter]

Didn't know much about Drops before, but starting to get the big picture.

Learning the power of drops myself. They're intended to be lazy loaders, but essentially act as super smart hashes. The TL;DR is that any public method is exposed to liquid as both foo.bar and foo["bar"] with fallback_data providing a hash of defaults if no public method matches. It's a really elegant/simple way to expose discrete pieces of calculated content to the user without giving them direct access to lower-level Ruby functions.