Add rule `require-event-prefix`

[marekdedic]

Motivation

In Svelte 5, all HTML element events are props starting with "on". Component events can have any name, so it is not clear, which props are events and which are not.

Description

I'd like to add a rule that requires that all props that are events (i.e. that are functions) start with "on"

Examples

<script lang="ts">
  /* ✓ GOOD */

  interface Props {
    regularProp: string;
    onclick(): void;
  }

  let { regularProp, onclick }: Props = $props;

  /* ✗ BAD */

  interface Props {
    click(): void;
  }

  let { click }: Props = $props;
</script>

Additional comments

I think this works even without TS, as the type would be in the parsed AST, right?

[ota-meshi]

Hmm. I think it would be useful to have that rule, but I'm worried about whether it's okay to judge all function props as event props 🤔.

What about implementing a rule that checks naming conventions for all props and provides examples for event names in the rule's documentation?
The rule could also disallow the on prefix for non-function props.

[marekdedic]

Well, in Svelte 5, IIUC there are no special event props - it's all just props, functions or not... I think in that case, it makes sense to treat function props as events...

Disallowing the on prefix for non-function props makes sense to me 👍

I don't really understand your point about naming convention for all props?

[ota-meshi]

I don't really understand your point about naming convention for all props?

For example, the following rule:

{
  "svelte/props-naming-convention": [
    "error",
    {
      "pattern": [
        "/^(?!on)/u" // Non-function props should not start with `on`.
      ],
      "overrides": [
        {
          "type": "function",
          "pattern": [
            "/^on/u" // Function props must start with `on`.
          ]
        },
      ]
    }
  ]
}

<script>
  /* ✓ GOOD */
  let { onclick = () => {}, num = 42 } = $props();
  /* ✗ BAD */
  let { onFoo = 42, bar = () => {} } = $props();
</script>

{
  "svelte/props-naming-convention": [
    "error",
    {
      "pattern": [...],
      "overrides": [
        {
          "type": "boolean",
          "pattern": [
            "/^is/u" // Boolean props must start with `is`.
          ],
        },
      ]
    }
  ]
}

<script>
  /* ✓ GOOD */
  let { isEnable = true } = $props();
  /* ✗ BAD */
  let { enable = true } = $props();
</script>

[marekdedic]

Uff. If we are doing a general naming convention rule in the style of @typescript-eslint/naming-convention, it would be probably good to apply it to things other than props (e.g. you could have a separate convention for all runes?)

That is a quite large undertaking and I am not sure it's something the users want (typescript-eslint has recently stopped adding features to stylistic rules altogether due to this...). So in this instance I would be inclined to add a much simpler rule that enforces events to start with on and possibly non-event props to not start with on. The more general naming convention rule is a can that should, in my opinion, kicked down the road.

[baseballyama]

Passing functions as props is not just for events but also for dependency injection (DI)-like use cases.
This rule feels too restrictive and lacks flexibility.

[marekdedic]

Hmm, I'm not familiar with that use case, could you please share an example? I'm trying to come up with a design that isn't too restrictive, yet at the same time isn't a full blown naming convention... Thanks!

[baseballyama]

This is example of it.
Then we can mock API calling for component test.

<script>
  const { fetchData } = $props();
  let data = $state({});
  const onclick = async () => {
    data = await fetchData();
  }
</script>

<button {onclick}>Click Me</button>

[marekdedic]

Thanks, I assume you mean onclick is an event and fetchData is not, right?

In your example, fetchData is async - to me, async functions don't feel like events (same for generator functions), but I suspect that isn't enough of a limitation.

I still think the proposed idea has value for some users, but you are right that it is subjective and there will be people who don't want this. At the same time, I don't really see a good way to distinguish what feels like an event and what doesn't. Do you have any things that make fetchData not an event in your mind?

[baseballyama]

I’m not sure😅. I often write frontend code at work, and it’s common to pass async functions as event handlers.

[marekdedic]

And do you then await them in the component? That seems very not-event-like to me...

[marekdedic]

Thanks for all the feedback, I'll try to move this forward:

1. It seems like not everyone would like to do this and that's OK, I don't propose this rule to be recommended, so it's up to the user to enable it or not
2. There was a good point about async functions, I think the rule shouldn't apply to them by default, but I can imagine adding a configuration flag to enable checking async functions as well (off by default).

Now what I'm wondering is whether there are any other special cases for functions that aren't conceptually event handlers and whether they can be detected by the rule. Other than that, I'd like to see some go/no-go for implementing this - I can make a PR, but I'd like to have some basic design agreed if I'm to do that :) Thanks!

[baseballyama]

Basically, ESLint is fully configurable, so I think it’s fine to add a new rule.
For example, I think it’s particularly useful in design system projects.
What do you think, @ota-meshi?