Event triggering syntax

[ziflex]

Changes

This proposal introduces:

• New keyword
• New runtime interface
• New runtime components

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:

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

type Dispatcher interface {
    Dispatch(ctx context.Context, event values.String, payload core.Value, options core.Value) (core.Value, error) 
}

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"]