onInit and running code on initialisation

[gfwilliams]

Posted at 2015-09-30 by @gfwilliams

Hi,

I've hit a few things recently where it's been a bit annoying to run code on initialisation. For instance say you have two bits of code:

A

function onInit() {
  require("my_lcd").connect(...., drawStuff);
}

function drawStuff() {
}

B

function onInit() {
  require("my_wifi").connect(...., function() {
   requestStuff();
  });
}

function requestStuff() {
}

You can't just copy and paste those bits of code - if you do the second onInit will overwrite the first silently and only the second will get executed. You've got to merge the two onInit.

So to me, a good solution would be to have a init event - just like you have for Serial1.on('data', ...);

Any thoughts about what the event should come from? I guess one thought is the global object - so you could do:

global.on('init', function() {
  require("my_lcd").connect(...., drawStuff);
});

Or I could put it on the E object, like:

E.on('init', function() {
  require("my_lcd").connect(...., drawStuff);
});

Any preferences? I guess for me, E is edging out, because it's nice and short :)

[espruino-discuss3]

Posted at 2015-09-30 by tve

I like the extensible event...

Related to this, I'm wondering how to implement a bit of a "supervisor" on Esprunio. This is in the context of the esp8266 and what I'd like to have is a small web server that allows me to configure the wifi, but also other settings, so I don't have to include that into each sketch. Basically a couple of web pages for scanning networks, associating, etc.

Maybe this has to be built-in in C, but it would be nice if it didn't have to be. But I also don't want to add the 100+ lines of code to every sketch. So some notion of being able to store more persistent code would be nice. Thoughts?

---

Posted at 2015-09-30 by DrAzzy

Are you saying that you can define multiple callbacks with the xxx.on(...) type handlers? I would have expected that if I defined one, it would overwrite the old one... So how do you remove a handler? Or are those handlers only removable by reset?

---

Posted at 2015-09-30 by alexanderbrevig

As with typical javascript you would not override an existing one by adding a new one. Much like setTimeout etc they all usually return an id pointing to the callback itself. This is also the way jQuery works (whether or not you like it; it's the way most people know callbacks especially in the global sense.

$(function(){ somethingToDoAtDOMLoad();}

$(function() { alsoExecuteAtDOMLoad(); }

EDIT: @gfwilliams I'm also in favor of E. I guess global.init is kind of old. 13.799 ± 0.021 billion years old in fact.

---

Posted at 2015-10-01 by the1laz

@gfwilliams - I was thinking about this the other day! There's definitely good uses for having it as an event. I'd go with E as well, my thinking is that you can treat E as a placeholder object representing the board, and you can then add other things later like events for sleeping, waking, maybe some properties of the hardware (like E.pins[]). EDIT: If going for some sort of javascript standardisation, Johnny Five uses .on('ready') which I think would work here.

@tve - I'd like something like that too. My use case is being able to telnet into boards, reset them and then load new code without wiping the code that connects to the network and starts a server.

---

Posted at 2015-10-01 by @gfwilliams

Ok, great! Looks like a consensus - E it is.

Are you saying that you can define multiple callbacks with the xxx.on(...) type handlers?

The others have said, but yes (same with Serial.on('data',...) too). You can use .removeAllListeners('init') to remove. There should be a specific one too, but I never implemented that :)

The other cool thing this would allow is for modules like the ones for LCD to auto-initialise themselves, so you no longer need to explicitly initialise them at all.

@the1laz - yes, more events in future would be great.

It'd be nice to have a way to handle other events in an extensible way - for instance Capture/compare timers or stuff like that.

@tve - Yes, I was wondering about that as well. I think it's work a separate post - I just added one

---

Posted at 2015-10-01 by @gfwilliams

Ok, just implemented. It'll be in 1v81 or up to date GitHub builds

---

Posted at 2015-10-01 by @allObjects

...quick... for me a bit too quick, because sequence / dependencies are not covered.

There are for sure things where the sequence and dependencies do not matter... on the other hand, returns from one modules are needed to setup other modules, and therefore, an uncontrolled sequence may become an issue.

In the other hand, one can always resort to a custom on init...

---

Posted at 2015-10-01 by @gfwilliams

I think it's good not to overcomplicate...

on('init', ...) is there to provide an easy way of initialising things. As you say, if you care about the order then you can just put all items in one function, in the correct order.

However if you've got multiple on('init', ...) then they'll be called in the order that they were added, which I think is reasonable.

---

Posted at 2015-10-01 by @allObjects

fair enough.... support the KISS - with Espruino redefining it too: Keep It Simple and SMART!