New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
prototype of jekyll hooks, encapsulated #3553
Conversation
Don't worry about the circleci failure. This looks pretty good! @envygeeks? |
👍 I like it! |
Sorry about the 👎 I actually meant to do 👍 |
Great. I'll flesh out the rest of it and add some test coverage. |
This is a bit more fleshed out now, although still lacking in tests and docs. I did do some one-off tests and it all seems to be working pretty well. Every hook receives the object being "hooked into" as the first argument. One major difference from octopress-hooks worth pointing out is how I'm dealing with the payload objects just before rendering. In octopress-hooks, there's a special hook for merging in new payload params. But I took a different approach and just pass the payload as an argument to each of the pre_render hooks. Anyone who implements a pre_render hook will receive the payload object and can modify it there if necessary as well as do any other things that need doing before rendering. pre_render is the only hook that receives a second argument at the moment. @imathis: let me know if you have any thoughts on this, especially if you already rejected this idea for some reason. Next up is tests and docs, but I'll give this PR a few days to bake in case there's more feedback. |
3dd9a3a
to
960960e
Compare
I'm working on cucumber tests now. How thorough do these tests need to be? Do we want each hook for every container to have its own test scenario? |
I say just write them and if there is a problem we'll point it out! |
8e42949
to
c63551c
Compare
@envygeeks / @parkr I've got cucumber tests and docs written. Do you have any feedback? |
@@ -469,6 +469,179 @@ module Jekyll | |||
end | |||
{% endhighlight %} | |||
|
|||
## Hooks | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add an "unreleased" note here? Check out #3556 for an example.
Unless you have some thoughts, @envygeeks, let's merge and get this out there in a new beta so people can start building for it. Best way to fix bugs is through actual use of the platform. |
c63551c
to
ab3f782
Compare
Amended commit to include "unreleased" note in the docs |
👍 Nice work on this! We're missing hooks for Documents but that shouldn't be a huge issue. |
I'm sorry I'm a bit late to this. Unless I've overlooked it, this does not include:
For reference here's Octopress's hook timeline. |
@imathis That's correct. I removed pre_read from my PR while writing the test cases because I couldn't come up with a use case to test that wasn't already covered. There may be some good ones, but I didn't think of any. As for merge_payload, I did depart from the octopress-hooks approach which is why I was interested in your feedback. I tried to cover the use case of altering the payload using pre_render which passes the payload to the callback as its second parameter. There's less code and less to test in this approach and it seems more flexible, but I'd be interested to know if I missed a good reason to implement it the way you already did. |
ab3f782
to
b1660ec
Compare
@imathis ^^? |
I'm going to create a branch of octopress-hooks that translates hooks to be based on this. If my tests pass. 👍 Let's see how long this takes :) |
Can we focus more on what we need and less on what we have? |
@envygeeks I'm focusing on what I need. I built the features in Octopress hooks because I needed them. If I can keep that functionality, I'll be good to go. Otherwise I'll have to keep monkey patching my own hooks. |
@imathis Well if you run into trouble then please do post the hooks that are failing and where they originate and are used at so I might be able to help you two come to compromise by possibly reworking both sides to see if we can fit your hooks into his hook system or if we need to truly have him change his hook system. |
This should address all the feedback @imathis. Just in time for JekyllConf! |
@@ -175,11 +175,15 @@ def destination(base_directory) | |||
# | |||
# Returns nothing. | |||
def write(dest) | |||
Jekyll::Hooks.trigger self, :post_render |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not put this at the end of render?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fine with me. It's here just to match the behavior of octopress hooks:
https://github.com/octopress/hooks/blob/master/lib/octopress-hooks.rb#L256
I'm fine with moving it though. Do you still want me to do that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think it'd make more sense. :)
Thanks for all your work on this, @stevecrozz!! ✨ Any other thoughts, @jekyll/core and @imathis? |
My only complaint is that defaults aren't on the surface API, we are seeping nil through the stack into internal API's and then setting defaults. I think that's obscure design and we should surface every default we have on the layer that is public making everything obvious. |
I would tend to agree, Jordon! Which defaults, specifically? |
- change site:reset to site:after_reset - raise an exception when registering uncallable hook - set default hook priority at the public API level
@parkr it was originally on line 53 of hooks.rb but it looks @stevecrozz caught what I meant and correct it so 🎉 I'm liking this so far! |
Lookin' good! I'll give another go at rebuilding some plugins based on this. |
@gjtorikian: would you mind trying out this branch on a big site you have access to? Interested in performance change, if any. ❤️ |
@imathis You could potentially author a shim to make your current octopress-hooks based plugins work with these new hooks. Here's a totally untested start at something like that. |
@stevecrozz I'll give it a try, thanks for the guidance. |
I kept trying it out and thought it would be a quick discovery, but kept running into problem. First, most plugins aren't Jekyll 3 compatible yet; I've logged a few issues for them. But even with them commented out, I discovered so of my own plugins/hacks are incompatible, too. It'll take me some time to upgrade those, in order to be able to test performance on Jekyll 3/this branch. |
@stevecrozz Is this ready to go? |
Merging. Feel free to add further feedback as we approach the final release! |
I just pushed an octopress-multilingual pull-request for merging Jekyll hooks support. It worked really well and was nice to integrate. Thanks for your work on this @stevecrozz and everyone else who helped! 👍 |
Hooray!!! 🎉 |
Very cool. Thanks for all the help, everyone. I know there were a bunch of other ideas up there that didn't make it into this first round but it doesn't have to end here. I'll look forward to seeing and reviewing more hook-related work. |
This is a second attempt at #3498 (adding hooks to Jekyll). In my last attempt @envygeeks had some complaints about the lack of encapsulation. This PR is an attempt to address those concerns and try out a new idea. This is definitely not ready to merge, but I wanted to get some eyes on it before I implement and write tests for the whole thing. The hooks concept is inspired by, but in this instance not perfectly compatible with octopress-hooks, so it's a bit of a departure from #3392 by @parkr, but I think it nicely encapsulates the hook logic.
Here's a practical example of how you could use one of these hooks to do something useful: https://github.com/stevecrozz/featherblade