Need a standardized event naming syntax about ngn HOT 4 OPEN

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

from ngn.

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

from ngn.

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

from ngn.

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

from ngn.