You are reading a single comment by @Gordon and its replies. Click here to read the full conversation.
  • Is that another thing that I could PR?

    Yes, absolutely! That'd be amazing! https://github.com/espruino/EspruinoWebTools is where Puck.js and UART.js are hosted...

    The library actually doesn't handle errors all that well, so it'd be amazing if it could for example reject Process.eval's promise if invalid JSON was returned (eg an error message).

    But actually UART.js might be the thing to improve. If the connection type could be set explicitly in order to avoid the popup (eg if you don't care about serial) I feel like it'd be the best thing to point new users at (if only because Puck.js as a library name is super confusing if you don't have a puck!).

    I can run async tasks on the puck

    Yes, that's a good point. It almost looks from how you use rpc that it could replace Puck.eval, but maybe it's better to keep it as a separate function, if that were something you wanted to add?

    The Puck library is definitely missing a nice way to handle getting async data easily - eg from sensors where you might have sensor coming in all the time... Even a Puck.on('x',callback) that actually added an event handler inside Espruino to E.on('x',...) would be nifty.

    Streams API could be a good thing to implement - especially where there's the 'connection' object. The write/eval stuff works well for simple sites and is a good way to get started, but it might be worth having something more flexible.

    Comlink looks neat! Actually I wonder if you could go one step further and have a general purpose worker script that you could include, and then just call with the function that you wanted to be executed in a worker...

About

Avatar for Gordon @Gordon started