Master event loop correspondence

[2Shaun]

---

name: "\U0001F4D6 New/Updated Documentation Content"
about: Adding a new docs page, or updating content in an existing docs page

PR Type

Does this PR add a new page, or update an existing page?
Updates an existing page.

Checklist

• Is there an existing issue for this PR?
• Have the files been linted and formatted?

What docs page is being added or updated?

• Section: Essentials
• Page: 1

For Updating Existing Content

What updates should be made to the page?

I think there should be more emphasis on the correspondence with the familiar event loop to mitigate the terminology learning curve.

Do these updates change any of the assumptions or target audience? If so, how do they change?

They assume a newcomer to Redux, which I believe is already the target audience for this page.

[netlify]

Deploy preview for redux-docs ready!

Built with commit 7a6411c

https://deploy-preview-3878--redux-docs.netlify.app

[markerikson]

Hey, thanks for filing this. I know we chatted about it a bit over on Twitter.

I'm not sure I agree with some of the changes here, though.

First off, the phrase "event loop" is wrong here. I think you mean "event emitter" instead.

Second, the table really doesn't belong in the "what you've learned", because it's not recapping something that was already taught earlier in the page.

Third, if anything, I feel like this maybe goes a bit more in the "data flow" section.

[2Shaun]

Assuming you were to agree with the change, do you think the reducer comparison belongs here? It seemed to fit with the other bolded comparisons in the doc.

As for the table placement, I agree with what you're saying. Honestly, the 'event loop' phrase choice came from a quick web search that returned this Wikipedia article, which seemed to describe a generic model for events. I can push with 'event emitter' used instead, but I'd have to reread the "data flow" section to figure out placement.

[markerikson]

The phrase "event loop" specifically refers to a tight while loop where a central driver application pulls events off a FIFO queue and executes them. Concrete examples of this are the Win32 event loop (handled by WndProc functions in user app code), or in the JS world, the JS interpreter loop where every DOM event, timer event, etc is handled by adding events to the queue and executing them sequentially.

One of the best explanations of this is the talk "What is the event loop, anyway?", which walks through how the JS event loop works.

This is a completely different than an event emitter, where arbitrary parts of an app can subscribe to some future event, and the emitter object runs all listeners when that event is triggered.

At the moment, I think I'm inclined to leave that "reducer" sentence alone, but just drop the table.

[2Shaun]

@markerikson Have you thought about this any further? I think it would help to relate the reducer to something familiar for new comers.

By the way, I did watch that talk and the event loop task queue definitely cleared up a couple of bugs I've had in the past.

[markerikson]

Sure, this works.