How to use Async and make react apps?

[daninus14]

How can we produce async and wait code with JSCL?

Also, is there a way to produce react and jsx or tsx components?

[daninus14]

Adding links here to previous discussions: #298

Note that the components seem to use the old class components instead of the function components.

See also https://github.com/jscl-project/jscl-react

[kchanqvq]

I'm not a web developer myself but I'm happy to help. I'll ask very dumb question about web development, though!

Is async/await orthogonal to React? IIUC React does not strictly depend on async/await, it just (presumably) uses Promise, and async/await is a syntactic sugar for promises. Can I get a sense of how heavy Promise is used in React? Is it just for say network operations, or you also need it for basic UI?

It looks like render in the linked jscl-react would correspond to jsx/tsx components. The syntax is quite rough. I would want something compatible with say spinneret. I'm sure the 5 years old project uses outdated API (JavaScript APIs are short lived). Does it make sense to write a new version from scratch?

[davazp]

Promises and await is difficult in jscl because of special variable bindings.

it is not clear when an asynchronous operation should preserve them.

Fortunately this has been done before with asynchronous local storage in node

https://nodejs.org/api/async_context.html

However this is not available in browsers.

if it were, special variables could be stored into a single Weakmap stored in there that maps symbols to their values.

[davazp]

This might help in the future https://github.com/tc39/proposal-async-context

[kchanqvq]

Maybe it's not that problematic. IIUC the problem mentioned in the linked proposal only happens when a function invokes an asynchronous function and not await it. This is conceptually similar to forking a new thread, and it's expected that dynamic binding don't get preserved.

try/catch inside an async function does seem to have normal semantics. So if we have a chain of async/await, our special bindings will work correctly. This might even be a viable strategy to support green threads/blocking operations if we convert all our functions to async/await (the efficiency is another issue).

[davazp]

Our special bindings rely on just mutating globally scoped variables, so they would get leaked to other threads. For example

// Bind a special variable for this function

async function f () {
  let old_value = symbol.value
  try {
     symbol.value = new_value;
     ....run code...
  } finally {
     symbol.value = old_value
  }
}

If I do await f(). f might work. But it will fail as soon as I do

Promise.all([f(), f()])

to run two instances asynchronously

[davazp]

Global scopped variables are okay with this kind of behaviour, but the lisp equivalent of this is

(defun f ()
  (let ((*symbol* new-value))
     (print *symbol*)
     -- wait
     (print *symbol*) -- might have a new value
     ...))

So it is quite incorrect for me if anything not invoked by f itself can have an effect on the value of *symbol. The whole point of binding the variable is to create that scope of what can affect it.

[kchanqvq]

Ah, that does make sense, thank! I'll think more about it...

[hemml]

I have made a simple macro to work with promises:

(defmacro with-promise (p &key then catch)
  (let ((pv (gensym)))
    `(let* ((,pv ,p)
            ,@(if then `((,pv ((jscl::oget ,pv "then") ,then))))
            ,@(if catch `((,pv ((jscl::oget ,pv "catch") ,catch)))))
       ,pv)))

It works the following way:

  (with-promise (funcall (jscl::oget (jscl::lisp-to-js (jscl::%js-vref "DeviceMotionEvent")) "requestPermission"))
    :then (lambda (res)
            (format t "OK: ~A" res))
    :catch (lambda (err)
            (format t "ERR: ~A" err)))
  ;; Equivalent to: DeviceMotionEvent.requestPermission().then((res)=>{console.log(res)}).catch((err)=>{console.log(err)})

[davazp]

That works of course but special variables won't interact very well with them right now.
And CL relies heavily on them.

[hemml]

May be it is possible to implicitly restore local bindings in lambdas, passed to JS functions?