example data: Better support EVENT_NEW_MESSAGE. #4760

The new name `mkActionEventNewMessage` is a bit more annoyingly verbose... but it's more transparent about exactly what kind of action it produces. It also represents a completely regular way of naming such a function, suitable for use in the general example-data module `eg`.

We already use this in one spot outside the `unread` tests, and it'd be convenient to use it in more places too.

Small thing, not essential to do -- I'm not sure it's ever actually helped us catch a bug -- but easy, and so in this central library meant for wide reuse we make a practice of it.

This will let us use it in a wider range of tests.

In particular, drop the occasional `type: EVENT_NEW_MESSAGE` and `ownUserId: eg.selfUser.user_id`, which were already redundant with `eg.eventNewMessageActionBase`. On the other hand, there was one `ownUserId: selfUser.user_id`, referring to a *different* self-user defined in the specific test. Happily that now stands out better, making the test clearer. This should be nearly NFC; the exception is that by using `eg.mkActionEventNewMessage` we're now making sure `.message.flags` exists, as it always should on an EVENT_NEW_MESSAGE action. That change will in turn be helpful in letting us clean up the code that these tests are testing.

As seen in the one existing example of this idea, a factory function has the advantage that it can handle subtler bits of structure: here, the fact that the `Message` object found in an `EVENT_NEW_MESSAGE` action always has a `flags` property, even though other `Message` objects don't. As demonstrated in the preceding commit, where we converted uses of `eg.eventNewMessageActionBase` en masse to `eg.mkActionEventNewMessage`, it also produces shorter code at the call site. And the types sure are simpler to describe.

This should always be true in real life (as described at the `Message` definition), and we've just fixed our tests to make it true there too. So, simplify a bit the potential paths through this code by asserting the property is there before we try to use it, rather than giving it a bogus implicit default of all flags being unset.

Much like we did for the various `unread` sub-reducers in the previous commit, this simplifies a bit the potential paths through this code. There was a test for this impossible case; remove that. While we're here, also remove a similar impossible check on `messages` being falsy, as if we got an EVENT_UPDATE_MESSAGE_FLAGS action with no `messages` property.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

example data: Better support EVENT_NEW_MESSAGE. #4760

example data: Better support EVENT_NEW_MESSAGE. #4760

Commits on May 24, 2021