esp32/m5paper uses special Button implementation

[FWeinb]

Sorry, opening so many issues. But this is not a bug rather a question regarding the button implementation for the m5paper. I saw that there is a comment that hints at some outstanding refactoring here: https://github.com/Moddable-OpenSource/moddable/blob/e55fbbf8c9a450acb052fc1630171f04a11c25c2/build/devices/esp32/targets/m5paper/host/provider.js#L34-L36

I found another button implementation for the m5stack* devices that is a little more advance and easier to use as you can just provide a onChange-Callback to the Monitor. Looking though the targets there is a mixtures of custom Button classes and Monitor usage thought the targets.

Another thing I noticed is the host/provider.js and the setup-target.js are used quite differently for the m5paper target, without really understanding the differentiation between them. In most other targets the host/provider.js is just used to define the basic io ports and peripherals by GPIO. In case of the m5paper there are many classes defined and objects instantiated, which is normally done in the setup-target.js.

[phoddie]

Sorry, opening so many issues. But this is not a bug rather a question regarding the button implementation for the m5paper. I saw that there is a comment that hints at some outstanding refactoring here

No problem. As you note, this isn't a bug, but work in progress.

We are migrating the Moddable SDK to adopt Ecma-419. The goal is to provide a standards conformant API (Ecma-419) on top of a standards conformant language (Ecma-262 / JavaScript). That is a big project that is proceeding in steps.

The original suite of device hosts, including the M5 hosts, do not yet use Ecma-419. For example, to use a button in those hosts today you write something like:

button.a.onChanged = function() {
   const state = this.read();
}

The M5Paper host is more recent, so it applies some more of Ecma-419. That includes the Buttons class. Ecma-419 doesn't define a button, but the design for one is implied by what is there in the IO Class Pattern and Peripheral Class Pattern. An Ecma-419 button differs from the original device host style in a few ways:

• Any callbacks are passed as part of the constructor's options object rather than being set as instance variables. This works better for Secure ECMAScript.
• The button should not be instantiated until it is needed to avoids unnecessary work and memory use. It also allows replacing the built-in button class if desired.
• The button GPIO is exclusively owned by the instance (there cannot be multiple instances, the instance created can be kept private)

It is a little bit more code to use the Ecma-419 style, but not significantly so:

new device.peripheral.button.A({
   onPush() {
      const state = this.pressed;
   }
});

Coming back to your original question, there is some work remaining to move Button to a common module so it is shared across implementations. That will happen as we have more experience using it and applying it to other hosts.

[FWeinb]

Thank you so much for this in-depth explanation. Unifying the API around the Ecma-419 sounds like a lot of work, glad you are taking the time to to this. My takeaway is that I should use the API that is provided by the m5paper implementation as everything should follow that model in the future, right?

[phoddie]

Thank you so much for this in-depth explanation

I'm just glad the explanation seems to have made a little sense. ;)

My takeaway is that I should use the API that is provided by the m5paper implementation as everything should follow that model in the future, right?

Exactly.