NGN icon indicating copy to clipboard operation
NGN copied to clipboard

Need a standardized event naming syntax

Open gbdrummer opened this issue 6 years ago • 4 comments

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

gbdrummer avatar May 01 '19 00:05 gbdrummer

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..

coreybutler avatar May 01 '19 23:05 coreybutler

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 avatar May 02 '19 05:05 gbdrummer

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

gbdrummer avatar May 02 '19 05:05 gbdrummer

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 :)

coreybutler avatar May 02 '19 22:05 coreybutler