Closed bob2517 closed 2 years ago
Pardon my confusion but is trigger
an event like click or hover? How is that specified in this shortened syntax?
Is this one trigger example or three separate trigger examples?
trigger: #myDiv click; trigger: ~custom something; trigger: .someDivs cleanup;
Trigger is a way to run any event, without actually having an event. It kinda turns events into regular functions.
Like if you had this event:
#myDiv:draw {
render: "hi there";
}
Let's say later on, while you are doing an event in #myOtherDiv, you wanted to render "hi there" in #myDiv.
You've already got the code for that, so you could do this:
#myOtherDiv:click {
#myDiv {
trigger: draw;
}
}
And that would call the draw event on #myDiv.
You can trigger any event again at any time, even body:init, by using the trigger command.
It's like a way to treat events as ACSS "functions" (which I haven't started working on yet and I can't remember if I even wrote up an issue on it yet).
So these are actually three completely different function calls:
trigger: #myDiv click;
trigger: ~custom something;
trigger: .someDivs cleanup;
I use the trigger command a fair amount when I code - it's in quite a few of the concept examples in the docs too. It would be worthwhile to know that it exists.
Actually, looking at it a bit more, this one might get a bit confusing to people:
trigger: .someDivs cleanup;
Following the current syntax, that would run the cleanup event on all elements with the class of someDivs.
Hmmm... actually, that might be fine. I just need to make sure that the new syntax will match the early behaviour but to be aware that the first parameter actually defines the target selector that the event will run on.
Don't worry about the new syntax though. You can check out the docs page for what's there now - it's not too complicated:
Note to self: Check that this doesn't conflict with the scope() issue proposal for all action commands, which may be a better option for consistency.
Actually, thinking about it some more scope() may be a better option. The confusion lies in having target selectors in the action command itself. It works ok for something like the remove command, but for trigger it could get a bit confusing what is happening where. So I think scope() could be a better option, but then if you use scope() you may as well type the whole target selector.
I'm going to mull on it over the next few days and maybe close this issue. I was just trying to save having to write some curly brackets, but the existing syntax may be the most sensible and readable way to proceed.
Sorry to add confusion to what is probably already confusing. Basically you can ignore this issue completely.
I'm going to mull on it over the next few days and maybe close this issue.
Where's an iron when you need one...
I am Ironman!
Lol :)
Closing this - when the scope() option is implemented (or whatever the syntax ends up to be), then this will be covered.
Triggering an event manually tends to need at least three lines of code.
Eg.
It gets mildly irritating doing this after a while, and feels a bit messy.
Doing this other alternative doesn't particularly feel like an improvement:
Actually, this whole thing can be shortened to:
Where the last word is always the event itself -- custom event (makeCheese) or a standard DOM event (mouseover) -- and everything before that last word is either the selector or the root name of the custom event selector (eg. ~custom).
There would even be a slight performance benefit, due to not needing to go through the target selector command sequence.