search

WordPoints / hooks-api

A basic API for hooking into user actions https://github.com/WordPoints/wordpoints/issues/321
GNU General Public License v2.0
0 stars 0 forks source link

Explicit event types #111

Closed JDGrimes closed 8 years ago

JDGrimes commented 8 years ago

See https://github.com/WordPoints/hooks-api/issues/108#issuecomment-193969002:

In fact, event types aren't really a part of the API at all. But perhaps they should be, see #59.

JDGrimes commented 8 years ago

I was thinking of a child registry or something, but I don't think that would work since the args are already in a child registry by event slug, and then what we'd end up with is a grandchild registry for the args, wouldn't we? Anyway, I've been toying with the idea that different types of events should be registered separately somehow, but I'm not sure what the solution here is yet. Maybe as the API continues to unravel it will be come more clear. :-)

JDGrimes commented 8 years ago

In regard to the child registry, see #95 (which I'd honestly forgotten that I'd opened).

JDGrimes commented 8 years ago

In #129 and #128, we've basically come to the conclusion that what we have in the hooks API is a meta API for handling two fundamentally different types of events. However, we also had this to say in https://github.com/WordPoints/hooks-api/issues/128#issuecomment-217984036:

Perhaps that is partly why we haven't really introduced an event types API: the "event type" definitions aren't really derived from the events themselves, but from their args. I guess that we could really say that the args define the event, since we can't seem to define the events at all apart from them though. But it has still seemed strange that the arg info should "bubble up" to define the event types. It has seemed better to just let the args speak for themselves, and let each API interpret them, rather than defining explicit event types. And I suppose that makes some sense in terms of information integrity as well, because it precludes a developer from accidentally mixing an event type with the wrong arg behavior.

This means that I'm currently leaning toward not introducing event types, because what an event type is is a conceptual thing, and those concepts have to be created by the API consumers. It seems better to just let each consumer determine whether a particular event matches a particular concept based on the event's args, instead of creating definitions that different devs (and thus different consumers) end up interpreting different ways. It would likely just lead to event types being abused, rather than being useful.

JDGrimes commented 8 years ago

So ultimately what we do here will depend mostly on how we decide to resolve the fact that that the toggle events are likely going to be leaving one day, and at that point we may want to return to a much simpler API (where event types would really be unnecessary). It's still possible, I guess, that we'll want to introduce a slightly different form of event types than that in the interim however, to differentiate those events that will eventually be deprecated from the events that will likely become the main focus of the API one day.

JDGrimes commented 8 years ago

So let's not pursue this right now. It's possible that we'll revisit it as the API evolves in the future, but it doesn't seem like something that is needed for the initial version.

Some random notes, for posterity:

but would we event need the arg registry anymore then? because it wouldn't be needed for the primary entities, I don't think. but for the stateful args it would be, I guess. some of them could be in a global registry, but others don't come from teh current context exactly, but fromt eh action args or elsewhere. we could allow args to be supplied from a variety of different sources, maybe.

but how woudl the router work if the events registry was a child registry? how would it know what events were tied to whcih ations?