You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since FQL is intended to help users interact with web pages by writing declarative query language, it makes sense to come up with more consistent and built-in way to express this interaction.
One of the most common interactions are:
Typing text into a textbox
Selecting a value from a dropdown
Pressing a button
At this moment, all these actions have their own functions in standard library. That means that every time you write a new functionality for communication with a web page (or any external system) you always have to provide a function that acts as a bridge between the runtime and your domain objects (like HTLMElement).
This makes writing modules and extensions more time consuming, difficult and cumbersome. We can do it better.
Proposal
This proposal offers an optional alternative approach - provide a uniform approach of sending events/actions to remove systems.
Instead of doing:
CLICK(element)
we could do the following:
DISPATCH click IN element
Instead of doing:
INPUT(element, "My text")
we could do the following:
DISPATCH input IN element WITH "My text"
Instead of doing:
SELECT(element, "my-option")
we could do the following:
DISPATCH select IN element WITH ["option1", "option2"]
Instead of doing:
INPUT(page, "#search", "Ferret")
we could do the following:
DISPATCH input IN page WITH "Ferret" OPTIONS { selector: "#search", delay: 50 }
And etc.
So, the general syntax would be:
DISPATCH event IN target [WITH payload] [OPTIONS opts]
All runtime values that could be used the syntax with, must implement the following interface:
I'm not fully sold on the DISPATCH keyword, so it's open for discussion (Could be TRIGGER, CREATE EVENT, SEND, DO, ACTION). Also, the interface name can be changed too.
But the idea is this: generic syntax and the runtime contract.
P.s. since some of the actions return a value, the dispatcher can return an optional result. Thus, such syntax is totally valid too:
LET values = DISPATCH select IN element WITH ["option1", "option2"]
The text was updated successfully, but these errors were encountered:
Changes
This proposal introduces:
Background
Since FQL is intended to help users interact with web pages by writing declarative query language, it makes sense to come up with more consistent and built-in way to express this interaction.
One of the most common interactions are:
At this moment, all these actions have their own functions in standard library. That means that every time you write a new functionality for communication with a web page (or any external system) you always have to provide a function that acts as a bridge between the runtime and your domain objects (like HTLMElement).
This makes writing modules and extensions more time consuming, difficult and cumbersome. We can do it better.
Proposal
This proposal offers an optional alternative approach - provide a uniform approach of sending events/actions to remove systems.
Instead of doing:
we could do the following:
Instead of doing:
we could do the following:
Instead of doing:
we could do the following:
Instead of doing:
we could do the following:
And etc.
So, the general syntax would be:
All runtime values that could be used the syntax with, must implement the following interface:
I'm not fully sold on the
DISPATCH
keyword, so it's open for discussion (Could beTRIGGER
,CREATE EVENT
,SEND
,DO
,ACTION
). Also, the interface name can be changed too.But the idea is this: generic syntax and the runtime contract.
P.s. since some of the actions return a value, the dispatcher can return an optional result. Thus, such syntax is totally valid too:
The text was updated successfully, but these errors were encountered: