Add delay to nap present()s

[gunar]

I believe a small delay for nap present() would be great for the developer to understand what's going on.

How important this is? I'm not sure.

Simply using setTimeout has shown to produce a lot of problems with nap. I believe we should buffer all present() and process sequentially. If we do this, we could even stop in time right before nap's present(). Imagine how cool it would be to be able to change the code and see what nap will do, before actually updating the store.

[weepy]

But isn't it possible for the resultant action of nap-a to change which nap runs next ?
You could have a simple option that would break the automatic execution of a nap. Then a dev tool could provide a button to run it.

[gunar]

Great idea! I just created #8 for that. Let's leave this one for discussion on the delay (should it be implemented anyway).

Here, I've pictured the DevTools executing a sequence of naps with 500ms intervals. This seems important for chained/consecutive naps. Question being: How important/who often do we have these?

[weepy]

Difficult to know without a real world example ?
On Mon, 14 Mar 2016 at 12:13, Gunar C. Gessner notifications@github.com
wrote:

Great idea! I just created #8
#8 for that. Let's leave
this one for discussion on the delay (should it be implemented anyway).

Here, I've pictured the DevTools executing a sequence of naps with 500ms
intervals. This seems important for chained/consecutive naps. Question
being: How important/who often do we have these?

—
Reply to this email directly or view it on GitHub
#4 (comment).

[gunar]

Precisely. Let's come back to this in the future.