-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Add VM TS mapping #1534
Add VM TS mapping #1534
Conversation
@nknapp Does this seem right? |
@nknapp would be useful to know if this is likely to get merged? Perhaps the typings should be added back to DefinitelyTyped? @zimmi88 what was the original reason for including the typings here? |
I missed this one, sorry about that... Honestly, I'm not sure if I want to support this. Adding those type definitions would make those internals an official API which means that we would not be able to change it without a major version increase. On the other hand, the The compromise I would be willing to accept is:
|
- Handlebars.VM is actually not part of the API, but Handlebars.VM.resolvePartial is mentioned in the documentation and is thus now treated as part of the API. Closes handlebars-lang#1534
- derived from the object structure seen in the debugger closes handlebars-lang#1534
Thank you. I have made some adjustments. The "options" object of "resolvePartial" seems to be different from the RuntimeOptions. Some options are missing and the "name" is new. I have used the debugger to inspect the object and decided that it should be its own type. I hope it was ok to force push on your branch. I neede to do that after squashing and rebasing the branch. |
- derived from the object structure seen in the debugger closes handlebars-lang#1534
Released in 4.2.0 |
That is fine, makes more sense now. Thanks for getting this in :) |
Actually @nknapp it seems that |
The "name" is indeed set to the runtime options, when a partial is called. But I would say this is a collateral effect, not intended. Passing "name" to a compiled template does not have any effect, in the template as far as I can see. Do you need the "name" to be in there? |
We are currently using it yes. It is an unusual use case, but we are checking the name against a map of Mustache templates and rendering it if it exists, otherwise just continue the normal handlebars render. |
I can see how you are using it? Where do you insert the logic that checks the name against the template map. Are you overriding the "compile" function? I'm asking because I don't think that this should be in the official API. Overriding any functions in the Handlebars-prototype is not intended and should not be promoted. Every addition to the API means that there is one more case where I would have to increase the major version of the library. But I would like to maintain compatibility, because that is least hassle for all users. You can send me a short fiddle that shows how you are doing it. I may change my mind and add it. Please create another issue for that, so that it is better to find. But after reading "Clean Code" by Robert C. Martin, and looking at the Handlebars source code, I feel the urge to do some refactorings. The code involving the "name" option. May also be subject to change in the future. If you give me a usage example, I might keep it in mind when changing that code. In any case, you can still add you own type definitions in your own projects, merging the "name" into the options. https://www.typescriptlang.org/docs/handbook/declaration-merging.html |
I am aware VM is not part of the public API. But, In one of our projects we are overridding the
resolvePartials
function in order to do some custom resolution, it would therefore be useful if it was mapped to TS to aid in that.Not sure if these typings are 100% accurate, I'm not particularly familiar with the structure of handlebars.js behind the scenes, but I took my best stab at it.
4.x
-branch contains the latest version. Please target that branch in the PR.