Skip to content
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

Event namespacing and naming convention #54

Closed
gregpabian opened this issue Mar 18, 2015 · 4 comments
Closed

Event namespacing and naming convention #54

gregpabian opened this issue Mar 18, 2015 · 4 comments

Comments

@gregpabian
Copy link

I'd like to propose a small change in our event naming convention.
Right now, as it's stated in #15 we decided to use lowerCamelCase for event names, but I think it would be much better if we had a simple way to also namespace them using a colon, because:

  1. Namespacing events would help us determine what module/feature/operation triggers them.
    Example: transactionStart, transactionEnd vs transaction:start transaction:end - in the second case you can clearly tell what we're listening to.

  2. Having namespaced events along with a way to listen to the entire namespace, e.g. change:* would allow us to catch all changes in a model, besides we wouldn't have to trigger another change event after that. We may also agree that a namespaced event will trigger a namespace event, something like this:

    t.trigger( 'transaction:start', args );
    // it would automatically trigger the following:
    t.trigger('transaction', 'start', args);

What do you think?

@mlewand
Copy link

mlewand commented Mar 18, 2015

Sounds reasonable.

When it comes down to triggering, do we need 2 ways of triggering them? Can't we just simplify it down to one?

@Reinmar
Copy link
Member

Reinmar commented Mar 18, 2015

I like the idea in general, although I don't have a strong opinion on the implementation. The one with ability to listen to change:* does not require firing another event (change), so it may be more optimal in this sense, but at the same time implementing listening to change:* may not be optimal. I would be also curious about listener priorities if listening to change:* was possible (my guess is - general listeners are executed after specific listeners). And finally - if change:foo was stopped by its listener, will change/change:* listeners be executed?

@gregpabian
Copy link
Author

@mlewand Ok, I think you missed the point of my example - this would automagically trigger the second event, under the hood.

@Reinmar
Copy link
Member

Reinmar commented May 5, 2017

We implemented namespacing and even the ability to listen to foo when someone fired foo:bar:bom. It proved to be useful in cases like firing conversion of element:p. You can listen on a specific element conversion (element:p) or conversion of any element.

@Reinmar Reinmar closed this as completed May 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants