Event name is not parsed correct if fired with identifier instead string constant

[alexprey]

Event name is not parsed correct if fired with identifier instead string constant

import { createEventDispatcher } from 'svelte';
const dispatch = createEventDispatcher();

const CLOSE_EVENT_NAME = 'modalWasClosed';
dispatch(CLOSE_EVENT_NAME);

Actual result

{
    "events": [
        {
            "name": "****unhandled-event-name****"
        }
    ]
}

Expected result

{
    "events": [
        {
            "name": "click"
        }
    ]
}

UPD. At 4.0.0 point this issue are partially fixed.

• Support the top-level plain constants (EVENT_MODAL_CLOSE)
• Support the top-level object-level constants (EVENT.MODAL.CLOSE)
• Support the top-level object-level constants with accessing by index getter (EVENT['MODAL']['CLOSE']). Actually, I'm not sure that this are required

[alexprey]

The same issue for svelte3 syntax

import { createEventDispatcher } from 'svelte';
const dispatch = createEventDispatcher();

const CLOSE_EVENT_NAME = 'modalWasClosed';
dispatch(CLOSE_EVENT_NAME);

[TheComputerM]

Yeah, having the same problem with svelte 3

[TheComputerM]

If there is something like:

function dismiss() {
  visible = false;
  dispatch('dismiss', {
    visible,
  });
}

The event dismiss is properly shown in the doc, but if the function is exported:

export function dismiss() {
  visible = false;
  dispatch('dismiss', {
    visible,
  });
}

The event dismiss is not shown at all.

[alexprey]

@TheComputerM it looks like a new issue, I'm create a new one, thanks you for reporting!

[soft-decay]

Hi @alexprey. I Hope you had good holidays.

This is a very old issue, but I saw it was also affecting the v3 parser, so I worked on it and opened a PR (#46) for a fix.
It allows basic support for identifier parsing of events:

• can only recognize top level identifiers
• nested identifiers in MemberExpression have to be dot notation only (computed with brackets not supported)
• Supports only nested Literal and ObjectExpression

If you want to see support for more types of node, or if you think it should support bracket notation for identifier parsing, let me know. I also left some TODOs in the PR that I'm going to complete soon.

[alexprey]

At 4.0.0 point this issue are partially fixed. However to complete this issue we need more work. Not sure that supporting of left cases should be solved in the area of this library. For example - support of imported identifiers. Actually the library dont have any logic to resolve import files or analyze them. But if we can support that it will be nice.
I suppose that I can mark this isuue as low-priority, due we cover basic cases of identifier usage in event names.

[soft-decay]

The bracket notation support would be nice to have, but indeed it is not that important.

However, supporting imports parsing is a whole other story, and I feel like it should have its own separate issue. The way I see it, if the library supports the resolution and parsing of imported files, imported identifiers become top level identifiers, so the same logic can be applied to them.

What do you think about creating a new issue that is more specific to the new problem (Resolve imported identifiers)?

[alexprey]

You are right, the imported identifiers handling looks like a new story. Keep only bracets notation in this issue and create a new one to support external references