Jump to content

RockHookSnippets - automatically create VSCode snippets for all hookable methods of your PW installation


bernhard
 Share

Recommended Posts

This is a very early realease and at the moment more of a proof of concept that needs some more work (not a lot though!).

Currently it adds VSCode snippets for all hookable methods and adds proper variable type declarations so that we get intellisense automatically:

aRD1dv7.gif

This module was easy to build thx to @adrian's work on TracyDebugger (Tracy is a dependency for the module). What I'm missing at the moment and where @adrian could hopefully provide some help:

I'd like to list the arguments of the hookable method automatically. As you can see in the screencast I have to type $event->arguments(0) manually all the time. Does tracy's api explorer know something about the used arguments? If yes it would be trivial to add this to the snippets generator ? 

PS: It adds two versions of all hooks: One regular hook that adds a separate function and one inline hook that does the same inline (as shown in the GIF).

PPS: Currently the module does build the snippets file automatically only if it does not exist. It would be great if the module recreated the file whenever the api changed. @adrian any hints what the easiest way would be to achieve that?

https://github.com/BernhardBaumrock/RockHookSnippets

  • Like 6
Link to comment
Share on other sites

Hey @bernhard - nice work!

7 hours ago, bernhard said:

Does tracy's api explorer know something about the used arguments?

Yes, the API Explorer does, eg:

image.png.23c729054a8382e6e9d4f5ced80da0ce.png 

The "params" is what you're looking for. Those wrapped in <em></em> are optional. Now the catch is that I include the params key for the API explorer, but for the hook data for the Captain Hook panel, I am storing like this:

image.png.3bd14cf312a33e30a4be2d5c9ff3854e.png

which means you can't easily get those params/arguments as easily. 

I was going to suggest you could use the API Explorer data instead, but there are several hooks, eg $page->viewable which don't show up as hookable in the APIExplorer because of the way they are added in the PW core, which is partly why the Captain Hook panel uses different methods to get the PW core methods.

So, I have played around with adding these to the hooks API data:

image.png.b58491d7fe1064d7a791247a145f15fc.png

Would that work for your needs?

8 hours ago, bernhard said:

It would be great if the module recreated the file whenever the api changed.

I could make a method in the TracyPwApiData class hookable so that when it is called, your module could be triggered.

Link to comment
Share on other sites

16 minutes ago, adrian said:

which means you can't easily get those params/arguments as easily. 

Yeah, I didn't find it in that data, that's why I asked ?

16 minutes ago, adrian said:

So, I have played around with adding these to the hooks API data:

image.png.b58491d7fe1064d7a791247a145f15fc.png

That would be a step forward, but not enough. I've looked into the core code how things are defined... Most methods look like this:

public function ___saveReady(Page $page) {

And the snippet output should be this:

$this->addHookAfter('Pages::saveReady', function(HookEvent $event) {
  $pages = $event->object; /** @var Pages $pages */
  $page = $event->arguments(0); /** @var Page $page */
});

The important part is the typehint @var Page $page (all necessary info for $event->object is already there). In this case this information is already present in the hook definition: We know that the first argument is of type Page and its name is $page. That could then be transformed into a snippet. Unfortunately there are also cases where the parameter type is only declared in the phpdoc. If that is a lot more complicated I'd be fine with not supporting these cases ? It's a helper tool where it would be absolutely fine that it works in some cases but not in all. Where it does not work we'd have to do what we now do all the time: Write code on our own ^^

I have almost no idea how your api parser works, so I hope I'm not asking for too much here. It's nothing really important, but on the other hand it could maybe be really helpful... 

Link to comment
Share on other sites

That sounds great, thank you very much ? 

Hm... I think that is not the best option. Better would be to have the variable name as key and the type as value:

UOdndg6.png

PS: Sorry, this is taken from the Pages::saved() hook!

	/**
	 * Hook called after a page is successfully saved
	 *
	 * This is the same as hooking after `Pages::save`, except that it occurs before other save-related hooks.
	 * Whereas `Pages::save` hooks occur after. In most cases, the distinction does not matter. 
	 * 
	 * #pw-hooker
	 * 
	 * @param Page $page The page that was saved
	 * @param array $changes Array of field names that changed
	 * @param array $values Array of values that changed, if values were being recorded, see Wire::getChanges(true) for details.
	 *
	 */
	public function ___saved(Page $page, array $changes = array(), $values = array()) { 

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...