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

Need a standardized event naming syntax #75

Open
gbdrummer opened this issue May 1, 2019 · 4 comments
Open

Need a standardized event naming syntax #75

gbdrummer opened this issue May 1, 2019 · 4 comments

Comments

@gbdrummer
Copy link
Member

Various events within NGN are not named in a consistent way. I'd like to suggest a naming syntax to be used as standard for all events within NGN, JET, and any project in which we use either:

<event-namespace>.<event-target>.<event-name>

For example, if we have an app app which has a sidebar sidebar, and we want to show or hide it, we would use the following events:

app.sidebar.show or app.sidebar.hide

Each part of the event name is delineated with a ..

These events might fire additional events to indicate they are in a state of processing, in which case they should use the same <event-name> but in present tense:

app.sidebar.showing or app.sidebar.hiding

They also might fire additional events to confirm their completion, in which case they should use the same <event-name> but in the past tense:

app.sidebar.shown or app.sidebar.hidden with "hidden" used as a verb.

Event names should not reflect state, only actions, ie app.sidebar.visible or app.sidebar.hidden with "hidden" used as an adjective.

As another example, if we have a data model model, and we want to update a field, we might use this event:

model.field.update, and the completion event fired would be model.field.updated

@coreybutler
Copy link
Member

I think a standard naming syntax makes sense as long as it is just a part of the project. Developers should have a choice in which syntax they follow.

The <event-namespace>.<event-target>-<event-name> syntax works well for JET, but the event namespace seems redundant and unnecessary within the core NGN lib. Each of the components are their own namespace. The exception to this are data stores, which relay events from models to the store. In this case, they are already namespaced, though they use record. instead of model..

@gbdrummer
Copy link
Member Author

Agreed on the first point.

I didn't mention it, but my intent was for the first two portions to be optional, ie only added when necessary. I just want to make sure that any events that do fire are descriptive enough that its obvious what they are doing, ie I don't wanna see a random event called "update" for example (maybe that is already the case).

The only other thing I want to look at is what we're actually naming things, and then make sure we are consistent. For example, in NGNX we have this common pattern:

this.properties.on('field.update', change => {...})

This makes total sense with NGN Data Models v1, although without knowledge of those, an event called "property.update" would make more sense to a user in this instance. I'd like to open up some discussion about the overall nomenclature so that we have synchronicity between all these different elements (again, mostly specific to JET).

@gbdrummer
Copy link
Member Author

On that note, should this issue be moved to JET?

@coreybutler
Copy link
Member

I think an overview of the current event naming syntax is warranted. Your point about this.properties makes sense. That particular event would be relevant to JET, but it originates in the data model. In NGN 2, we can also have stores to represent properties, and we now have a relay function. The relay function would be more appropriate in this case because it would allow us to rename events within the context of how they're being relayed "up the chain".

I think this issue is a good place to keep track of our conversation. As we conclude around specific points, they should be added to the original issue. In the meantime, I will add this issue to the roadmap for NGN 2.

Additionally, for discussion purposes, I could extract all the events from NGN 2 via metadoc.... but it would be alot nicer if the doc site was done :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants