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

[bernhard]

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:

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

[adrian]

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:

 

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:

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:

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.

[bernhard]

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:

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... 

[markus_blue_tomato]

@bernhard thx, your OS PW-module output is awesome ? 

[adrian]

@bernhard - does this work?

I can parse and provide the info from the phpdoc however you want, so if this still isn't correct, just let me know.

PS, if it helps, I can also return the values for @return and @throws

[bernhard]

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:

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()) { 

 

[adrian]

10 minutes ago, bernhard said:

Better would be to have the variable name as key and the type as value

or do you want them without the "$" at the start of the variable name?

[bernhard]

I think that does not matter and like this it might be more readable ? 

[bernhard]

v0.0.2 implements the changes that @adrian put into Tracy to have all hook parameters available in the hook ? A big THX to Adrian! This needs the latest version of Tracy which is not yet online, I think @adrian ?!

[adrian]

10 minutes ago, bernhard said:

This needs the latest version of Tracy which is not yet online, I think @adrian ?!

It's up now - 4.20.17