DEV Community

Michal Bryxí
Michal Bryxí

Posted on

Component Arguments vs HTML Attributes bug hunt

In Ember Octane together with angle bracket components we got a syntax that allows us to distinguish between Component Arguments and HTML Attributes. Which is great, because it allows following syntax:

{{!-- app/components/sent-message/avatar.hbs --}}

<Avatar
  @title="Zoey's avatar"
  @initial="Z"
  class="current-user"
/>
Enter fullscreen mode Exit fullscreen mode
{{!-- app/components/avatar.hbs --}}
<aside ...attributes>
  <div class="avatar" title="{{@title}}">{{@initial}}</div>
</aside>
Enter fullscreen mode Exit fullscreen mode

Unfortunately during one of my big refactors I either did a manual mistake or hit a bug in angle brackets codemod and suddenly I got a code:

<Comments @postId={{this.model.id}} pageSize={{50}} />
Enter fullscreen mode Exit fullscreen mode

Where pageSize should have been a Component Argument, i.e: prepended with an "at" symbol:

<Comments @postId={{this.model.id}} @pageSize={{50}} />
Enter fullscreen mode Exit fullscreen mode

Since the change in the codebase was huge and test coverage is not great, I was thinking about a way to easily uncover such a mistake. The requirements were:

  1. Quick & easy solution that anyone can run.
  2. No 100% solution needed, just a sanity check.
  3. Ignore known HTML attributes. In my example class.

I came up with following solution, which needs ripgrep or any grep with negative lookahead capability (not available in native OSX grep):

❯ rg -t hbs --pcre2 '<[A-Z][A-Za-z:]*[^>]* ((?!class)[^ @]*)=[^>]*'

app/post/comments/template.hbs
22:<Comments @postId={{this.model.id}} pageSize={{50}} />
...
Enter fullscreen mode Exit fullscreen mode

So it seems to do it's job. Playground available on regex101. If you have an idea to improve this, please let me know, I am happy to update.

Top comments (0)