Comments (34)
OK, I went spelunking to see how hard it would be to fix things to be able to use Handlebars comments. Turns out I am dumb and it was simply not fully implemented in HTMLBars / Glimmer, but is not a hard restriction on the Handlebars parser side. I am working up a PR to Glimmer to enable the following for us (will still need a bunch of work in ember-template-lint after the upstream fixes land).
Current proposal:
This proposal has the following additional benefits:
- We can deprecate
<!-- template-lint
, and rely only on Handlebars comments (this has irked me for quite some time). - We do not have to worry about changing semantics (i.e. changing the comments to be block scoped by default)
from ember-template-lint.
@bendemboski - Love it! Note: the element modifier approach will only work for actual DOM elements, not component invocations (mostly because I cannot even reason about what that would mean). I also think I would definitely still want the original proposed syntax also.
Current proposal:
Everyone on board with that?
from ember-template-lint.
from ember-template-lint.
I like it.
from ember-template-lint.
I like this a lot too. However, I have a different use case in mind that is maybe related that I'd like to mention. If it better belongs in a separate issue, I'll happily take it there, but it's related so I think at least worth considering at the same time as this initially.
The current mechanism allows users to disable rules for a range of lines in a file. Embracing the structure of HTML and allowing a disabling mechanism that operates on DOM nodes/trees rather than lines of text is a fantastic idea. This proposal provides a mechanism for disabling a rule for a given sub-tree of the DOM, but often rather than that I just want to disable it for a given DOM element (and not its descendants).
This is especially relevant when the rule addresses element attributes. For example, I recently had a discussion about invalid-interactive where sometimes I want to disable it for a specific element, but make no assumptions about if/how the rule should apply to the elements it contains.
In order to make this syntax support this, I think we'd need to support something like this (a very small variant of the examples shown in this issue and the jsbin):
This would work, but seems overly verbose for what I think might be a fairly common use case of disabling a rule for an element rather than a DOM sub-tree. What do folks think about supporting some other syntax for disabling rules for a single element? Maybe the syntax could be something like:
Or perhaps there's a better syntax? I suppose if we're doing that we could also support a recursive
(or subtree
or something) flag in addition to or instead of the original proposal in this issue:
Thoughts?
from ember-template-lint.
@bendemboski Your proposal is very similar to the element modifiers RFC. I quite like your final iteration but I believe that all three invocation patterns should possibly be supported.
from ember-template-lint.
Oh yeah, thinking about it, we'd definitely still want to support the originally proposed syntax because you might not always want to disable for a single DOM sub-tree, but maybe:
or even
from ember-template-lint.
lol:
I'm quite pleased with the current recommendation from @bendemboski and thank you for succinctly summarizing it, @rwjblue. 👍
from ember-template-lint.
I'd prefer to see as much of this as possible done in comments, HTML or handlebars. This is partially b/c comments already communicate that the meta-data will be stripped from final output.
For example if someone not super familiar with this system sees: {{#template-lint}}foo{{/template-lint}}
Ember has taught them elsewhere they should expect output of <div>foo</div>
. However that isn't actually doing to happen.
Furthermore, linter config in JavaScript (eslint, jshint) has always been based on comments. This seems worth mirroring just to be consistent.
I think an alternative could be arrived at using either HTML comments or HBS comments.
from ember-template-lint.
An example using HBS comments:
Or using HTML:
The block case is a bit more tricky.
from ember-template-lint.
Anybody care to specify block comments in Handlebars as part of this effort? 😜 It seems like that could be:
And then you can name them if you want to allow for nested directives which don't end at the nearest block (adopts requirement for matching beginning and ending):
from ember-template-lint.
We cannot use HBS comments, they are stripped by Handlebars parser and not available at the AST plugin stages. HTML comments would be fine I suppose, but because we cannot get a block form I would want to scope them to the "current block" level.
Using HTML comments is (and has been) annoying, because we have an explicit rule disallowing them for everything OTHER THAN template linting control comments. This has been ok so far, so maybe its fine to keep going that way...
Follow up proposal using HTML comments that are stripped:
Note: this does not allow @bendemboski's suggestion, because HTML comments are not allowed inside an element:
from ember-template-lint.
We cannot use HBS comments, they are stripped by Handlebars parser and not available at the AST plugin stages.
That's right, I knew I must have been forgetting something 😢
from ember-template-lint.
We cannot use HBS comments, they are stripped by Handlebars parser and not available at the AST plugin stages.
That's right, I knew I must have been forgetting something
FWIW, I am pestering @mmun to see if he has any insight in if this is possible to change/fix, but we should not assume it is possible just yet...
from ember-template-lint.
If we're unwilling to use element modifiers then I have one other thought for how to support my use case. Something like:
and then if we want:
I don't like it as much as using element modifiers but @mixonic has some good points.
from ember-template-lint.
Only limitation, the latest proposal doesn't allow for:
{{!#template-lint invalid-interactive=false}}
{{#foo-bar as |baz|}}
{{! invalid-interactive is disabled here }}
{{/foo-bar}}
{{#foo-bar as |baz|}}
{{! invalid-interactive is disabled here }}
{{/foo-bar}}
{{!/template-lint}}
Want to make sure we're explicitly opting into that.
from ember-template-lint.
I think it also no longer supports a case that is currently supported:
I am 1000% on board with deprecating that because I think we should be operating on DOM nodes/trees not lines of text, but just wanted to call it out to be explicit.
from ember-template-lint.
FYI - Submitted glimmerjs/glimmer-vm#340 as a WIP Glimmer PR to add the support we need.
@nathanhammond - RE: https://github.com/rwjblue/ember-template-lint/issues/79#issuecomment-258972873, we could make the following work properly:
@bendemboski - RE: https://github.com/rwjblue/ember-template-lint/issues/79#issuecomment-258974260, agreed but that confuses the heck out of me and I think not supporting it is a feature 😝 . The following would be supported though:
Its more verbose, but I feel it is more obvious. Also, the only reason the original snippet in your comment worked was because we do a depth first traversal. If we instead changed the traversal to be breadth first, that would break.
from ember-template-lint.
@rwjblue I'm assuming that you mean for your example in your last post to follow the convention of "must be at the same level" which you imply in the second half of your comment to Ben?
from ember-template-lint.
@nathanhammond - Yes, exactly.
from ember-template-lint.
@rwjblue I entirely agree, just wanted to be clear that if anybody is using the structure in https://github.com/rwjblue/ember-template-lint/issues/79#issuecomment-258974260 they'll have to make a not-quite-mechanical change to update it.
So, the principle behind this (i.e. how we think of it applying to the DOM tree) is that we're providing two ways of configuring the linter in a template:
- Add an instruction as an element attribute that applies to it and (optionally) to its descendants.
- Add an instruction as a child-less node that applies to all of its later siblings nodes and (mandatorily) to their descendants.
And we're abandoning @rwjblue's original thought about adding an instruction as a node that can have children and applies only to its descendants ({{#template-lint}}...{{/template-lint}}
) so that we can more easily implement this using handlebars comments for clarity. Or maybe someday we'll do https://github.com/rwjblue/ember-template-lint/issues/79#issuecomment-258942645 and hope that we haven't made the linter so smart that a cyborg from the future comes back to destroy it.
Sound right? It's gotten a little more intimidating, but I'm still willing to take it on unless anybody thinks I shouldn't.
from ember-template-lint.
Sound right?
Yes, I believe this is a good summary of my current line of thinking. I've updated the main description above to reference the current state of the proposal.
It's gotten a little more intimidating, but I'm still willing to take it on unless anybody thinks I shouldn't.
Nah, it'll be easy. We can work on some mockup JSBin's as soon as glimmerjs/glimmer-vm#340 lands.
from ember-template-lint.
In the meantime we should decide what the interface for the inline HBS comments are. I suspect that we want the ability to do more than just set rules to true
and false
(or disable all), so we will need to decide what the serialization format is. The easiest thing to do is just JSON.parse
, but I'm not sure that feels natural...
The strawman (we would use JSON.parse
to get the values back out):
Note: I think ^^ looks like garbage 😈
from ember-template-lint.
https://github.com/rwjblue/ember-template-lint/pull/130 should make things a bit easier when glimmerjs/glimmer-vm#340 lands.
from ember-template-lint.
I don't really like spreading state around, but one option would be to allow inline configuration of simple key/value pairs, and then support more complex configurations with named configurations in the global config file that can be applied from comments.
// .template-lintrc.js
module.exports = {
rules: {
"nested-interactive": true,
"invalid-interactive": true,
"bare-strings": true
},
localConfigs: {
"interactive-divs": {
"nested-interactive": {
ignoredTags: ["div"]
},
"invalid-interactive": {
ignoredTags: ["div"]
}
},
"i-do-what-i-want": {
"nested-interactive": false,
"invalid-interactive": false,
"bare-strings": false
}
}
};
from ember-template-lint.
Actually I think something like that will be required if we ever want to support rules who are configured with non-serializable values such as functions, which seems reasonable. In that case we either have to move the configuration out of the template into a Javascript file, or else work out some syntax where we parse the comments and throw the results at eval
, which makes me feel dirty to even contemplate.
from ember-template-lint.
It seems like named states are a good escape hatch and inline config can either be foo=bar
or a simple JSON hash. I don't have a ton of preference here...
from ember-template-lint.
@bendemboski - To aid in working on this, I made a branch that you can target that has the required upstream changes (by publishing that PR as rwjblue-glammer-engine
):
https://github.com/rwjblue/ember-template-lint/tree/handlebars-comments
from ember-template-lint.
@rwjblue thanks! I still don't quite get the significance of that change, though. Does it give me new/different AST APIs to use or something? Or is it just a code organization change?
from ember-template-lint.
@bendemboski - There will be a new MustacheCommentStatement
visitor that runs for the Handlebars comments (there is already a CommentStatement
visitor you can use, but that is only for HTML comments).
from ember-template-lint.
Okay, so then I propose three different instruction syntaxes (inspired by eslint):
Enable/disable all rules:
Enable/disable one or more rules:
Configure one rule at a time:
Note that care has to be taken in the last one to not have the rule JSON accidentally end the handlebars comment prematurely. Fortunately, if that were to happen, the JSON would not parse so it would definitely not fail silently.
Also, because JSON the last one would support an alternate rule toggling syntax for free:
So we could do without the second, but I think it's a nice syntax to have anyway.
Sound good? @rwjblue @nathanhammond
from ember-template-lint.
Sounds perfect.
from ember-template-lint.
Hrm, I just realized, that's problematic for supporting the 'recursive' flag on in-element instructions. How about we do away with that, and to support that case you'd just have to do the slightly more verbose
or
Unless somebody has an idea for a clean semantic for parsing options meant for "rule scoper" as separate from the JSON meant for the rule itself.
from ember-template-lint.
@bendemboski - I didn't think that we were talking about template-lint-enable
/ template-lint-disable
parsing JSON? If that is true (that they will not be JSON, just a space separated list of rule names) then the more verbose version will only be needed when you need to do {{! template-lint-configure bare-strings ['.'] }}
.
We should also queue up a deprecation for the <!-- template-lint
style comments (since we won't need them any more).
Also, the changes needed upstream to support Handlebars comments landed in [email protected] and that was merged here in https://github.com/rwjblue/ember-template-lint/pull/133, so you should be good to go...
from ember-template-lint.
Related Issues (20)
- Incorrect no-redundant-role on img HOT 5
- Improve builtin-component-arguments rule to lint against "radio" inputs HOT 1
- ARIA-compliant disabled link communication raises errors on default config
- allow no-invalid-link-text to be configured for custom link component names
- Drop Recommended Rules for Deprecated Ember 3.x Features HOT 4
- New rule: no-jsx-attributes
- New rule: No chaining `this` to itself HOT 2
- [no-action-on-submit-button] Do not handle `<form method="dialog">`
- Autofix of block-indentation crash
- require-input-label false positive HOT 3
- Revamped gjs/gts support HOT 2
- [gjs]: no-unknown-arguments-for-builtin-components incorrectly assumes an `<Input>` is the ember `<Input>`
- [gjs]: require-input-label incorrectly assumes an `<Input>` is the ember `<Input>`
- Migrate off Jest HOT 3
- no-black-params-for-html-elements failes with dot-separated angle bracket invocation
- Plan v7 Release
- overrides do not apply to gts
- Running `--fix` when enabling `attribute-order` rule hangs process HOT 1
- Bug: autofix of `attribute-order` removes empty string attribute/argument values HOT 1
- Contradictions from no-potential-path-strings and no-unnecessary-curly-strings HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ember-template-lint.