Create a way to evaluate arbitrary javascript #894

Current Situation

Currently, there is no method to transmit the results of a JavaScript function to the backend.

Proposed Actions

Develop some way to bridge the gap and allow server-side python to run/evaluate client side code within events and hooks. Since it relies on client/server communication, the interface either needs to be async-only or utilize a use_query-style interface.

Something to keep in mind, if technologically possible we should try to pre-populate this keyword with something that makes sense, depending on where the JavaScript was executed.

See this comment for traceability.

Example 1

This might look like a use_script hook that operates similarly to html.script, but can return a result.

This interface would be heavily inspired by our Django use_query hook.

@component
def example():
    executor = use_script("getComputedStyle(document.querySelector('#element'))", deferred=True)

    async def on_click(event):
        await executor()
        example_value = executor.data 

    return f"CSS Style Attributes: {script.data}"

This syntax might feel a bit unnatural though - there really isn't a useScript hook in ReactJS. There is an npm package @uidotdev/usehooks with a useScript hook, but it is for dynamically loading external JavaScript files.

Example 2

Another idea is ECMAScript-style eval(...). Technically this eval syntax always exists in JavaScript-land (ECMAScript), but is completely missing in ReactPy.

@component
def example():
    styles, set_styles = use_state(None)

    async def on_click(event):
        fetched_data = await eval("getComputedStyle(document.querySelector('#element'))")
        set_styles(fetched_data)

    return f"CSS Style Attributes: {styles}"

Open Question(s)

1. What happens if the user doesn't put a single callable into this interface, and instead puts a complex multi-line script? We probably should keep identical behavior to whatever ECMAScript eval does, which will require some probing.
2. These interfaces are likely to have the same limitations as ECMAScript eval, but they seem to be a necessary escape hatch... is there any alternative that would make more sense?
3. If we develop an alternative, should we still keep eval as an escape hatch? For perspective, all browsers retained the use of ECMAScript eval despite it not being a great solution for 99% of circumstances.