Curious as to why the Firmata requirement?

[abritinthebay]

Surely this ties the application to a host process? In something like the Espruino you would just call a lot of the code directly.

Is supporting something like the Espruino possible? Would love the advantage of using React and Components as a architecture for it...

[iamdustan]

Hey @abritinthebay, thanks for checking out the project and asking the question!

I do not know enough to answer that well. It seems Firmata is the standard protocol to control hardware from an external process.

I don’t have an Espruino so have never looked into what it would take to this running on their board(s). A quick googling about seems to say that Johnny-five also does not work on Espruino (links I read were a few years old).

Exploring support for Espruino is not out of the question, though this is only a side-project so without external research and contributions I wouldn’t expect to see much on this front in the foreseeable future.

[abritinthebay]

Ah I see the difference. It's about external vs internal control.

So Espurino runs JS on the board. Firmata is about a host computer controlling it.

It would be lovely to have a renderer that worked with the JS and API that is running on the board instead of via a host.

Not sure if that's within the scope of this project though. Seems a little different. That said - there are more and more JS powered hardware boards coming out. There's the Espurino, the Tessel, and a few others.

Would basically be like running a long-running Node version of React but with no DOM mounting, just "mounted and listening to events".

[iamdustan]

Yeah, I think that would be feasible. Right now the internal API is definitely dependent on the Firmata API. I believe Johnny-five has the ability to interop with non-firmata boards by having a bridge layer. For something like the espruino I think it would be ideal to actually write a smaller and tighter custom implementation like preact or inferno. API compatible with React, but built for only a single domain.

[abritinthebay]

Yeah, that could work. The main thing would be no-dom really I guess, which you obviously already have.

I wonder if abstracting the internal API to be independent of the call state could work. You would then have the "render" layer that interfaced with the protocol layer (be it Fermata, hardware JS implementation, C lib calls, whatever).

something like...

import ReactHardware from "react-hardware"';
import EspruinoRenderer from "espruino-react-hardware";
ReactHardware.use(EspruinoRenderer); // otherwise defaults to Firmata

If that makes sense. Probably way out of scope right now but... wondering if it's even possible. I imagine it would require major internals changes.

[iamdustan]

I want to handle rendering to multiple boards at once. See #10.

I also added a commit that supports wrapping johnny-five components and rendering to a johnny-five board yesterday (cc2677f)

An API like the following is what I’ve been imagining:

ReactHardware.render(<Board bridge={EspruioBridge} />);
ReactHardware.render([
  <Board bridge={BluetoothBridge}><App /></Board>,
  <Board bridge={EspruinoBridge} /><App /></Board>,
]);

[iamdustan]

If you have experience with espruino or C lib calls or anything I’d love any POCs or PRs or whatever! Thanks for being interested and engaging in this conversation 😄

[abritinthebay]

Espruino I do! As it's JS - for others I'm quite a C novice :)

The board thing is interesting... not sure Espruino would work for that tho - again, external vs internal. I mean it would be possible to write something that you communicated to... but at that point it's just a JS api, and that code would have to be running on the Esprunio... which seems to defeat the purpose tbh. Especially as they are supposed to not always be slaved to a host.

Might just not be quite within the goals of this project...