sample api for plugins#119
Conversation
|
Incomplete, but I wanted to get some buy in for my approach before I continued |
|
very very interesting. this looks like something I want to merge! |
|
I will. I just wanted to make sure the approach was what you wanted first. Especially to be sure you're ok with changing I'll start prepping it. |
|
The other changes were in files not currently being tested. This is most of the way there. I want to review and do some full stack tests. Anything else you want to see? |
|
I feel that it looks great, I'd be happy to help out with tests, I'll try to find a good block of time to do that this week -- but yea feels like this can bring a good chunk of genericness into Hygen! |
|
Running the plugins in the ops steps did not allow saving results to the params. I've moved the plugin resolution into the render promise chain. All the formal tests work, and informal tests using templates did as well. |
|
resolving the plugins during the ops phase did not allow results of the plugin to be used inside the template it's self. I moved it into the render promise change. This is complete from my point of view, but I'm happy to cleanup or add whatever you suggest. |
|
Is there something else you wanted from this? |
|
closing in favor of #149 |
A Follow on from #100
The main assumptions are that the plugins are meant to be run, and their results stored in the args to be used when the template is processed.
plugins are defined in
.hygen.jsand consist of a function that takes (action, args, config)pros: simple api, easy to add
cons: crude mechanism to insert result of plugin into args, not needed?