Event API Revisions

[rtfeldman]

Having spent some time with @rogeriochaves's awesome event triggering system, I have some ideas for how to revise the API:

Current API

test "input produces expected Msg" <|
    \() ->
        Html.input [ onInput Change ] [ ]
            |> Query.fromHtml
            |> Events.simulate (Input "cats")
            |> Events.expectEvent (Change "cats")

Proposed Change

test "input produces expected Msg" <|
    \() ->
        Html.input [ onInput Change ] [ ]
            |> Query.fromHtml
            |> Event.simulate (Event.input "cats")
            |> Event.expect (Change "cats")

The big change is making (lowercase) functions rather than (uppercase) union type constructors for the events.

Before:

|> Events.simulate (Input "cats")
|> Events.expectEvent (Change "cats")

After:

|> Event.simulate (Event.input "cats")
|> Event.expect (Change "cats")

This has a few benefits.

1. It's easier to tell at a glance which is the Msg (the uppercase Change) and which is the event (the lowercase input "cats" - as opposed to the previous Input "cats").
2. Each event helper can have its own documentation, which is especially helpful in the case of nontrivial ones like check.
3. Adding new helpers can be a minor version bump.

Other changes include:

• Renamed EventNode to Event and made the old Event a ( String, Value ) tuple. We never treat these as anything other than function arguments that get passed around without modification, so giving them their own type doesn't seem warranted.
• The module is called Event instead of Events - this makes Event.input read nicely ("an input event") and makes the module name correspond to the type - the Event module and the Event type, like the Maybe module and the Maybe type.
• Instead of Events.eventResult we can have the self-explanatory Event.toResult - which takes an Event and returns a Result!
• In a similar vein, renaming Events.expectEvent to Event.expect - which takes an Event (and a Msg) and returns an Expectation.
• Removing the formatting characters from the error message - those won't look great in a browser. 😉

Thoughts?

[rogeriochaves]

Cool! It crossed my mind using functions instead of union types for the events, but I haven't thought deeper on the advantages or disadvantages of it. You won me at "Each event helper can have its own documentation".

LGTM

[eeue56]

woa, hold up,I wanna review first

[eeue56]

I've putsuggested changes on #29 @rtfeldman

[rtfeldman]

Sorry @eeue56! Didn't realize you wanted to weigh in first. 😅