For actual subscription filters that I am using I have a lot of ports
Yes, I can see that that would be an additional case. Ports have not been
on my radar, since they were not relevant to the projects considered.
So Keyboard and ports.
For ports, that could motivate a similar change, where
port name : (Type -> msg) -> Sub msg
becomes
port name : (Type -> Maybe msg) -> Sub msg
But let’s not make this part of the current proposal.
In any case, that’s still only two cases (since all ports would be handled
equally), nothing spreading to all APIs.
Also, since my last email, more than 100 more lines total are gone.
That’s nice. But let’s not confuse it with anything meaningful about the
proposal at hand. You are obviously removing a lot of stuff. There’s no way
really for us to know why that stuff was there and what other strategies
might be applicable to remove it or to have prevented it from being there
in the first place. If that’s to be discussed, it belongs in the other
thread, about your “generic filtering of all kinds of events” proposal.
For the five concrete projects I pointed to, I say with confidence that the
Keyboard API proposal I brought up here achieves something which that other
proposal does not, in terms of simplifying the code.
2016-08-10 22:21 GMT+02:00 OvermindDL1 <overmind...@gmail.com>:
> On Wednesday, August 10, 2016 at 1:01:10 PM UTC-6, Janis Voigtländer wrote:
>>
>> Only one?
>>
>> Yes, indeed. Note what I wrote there. It talks about filtering
>> subscriptions. All the examples you mention do not seem to be about
>> subscriptions, but instead about updates that come from other sources,
>> probably from HTML events. Where (except keyboard handling) have you wanted
>> to apply a filter function to a Sub-typed thing? (Leading us away from
>> keyboard, so maybe this is more suitable to continue in the other thread
>> about generic subscription filtering.)
>>
> For actual subscription filters that I am using I have a lot of ports
> (integration with javascript code that I am not allowed to get rid of) and
> sometimes the port calls are useful and sometimes they are not. My Helpers
> library has both a `msg_ignore` and a `cmd_ignore` that I use heavily for
> such purposes (which my Helper library swallows thankfully). My
> subscriptions used to be fairly large and hairy because of all the checks,
> that is since gone and now replaced with:
> ```elm
>
> subscriptions : Model -> Sub Msgsubscriptions model =
> Sub.batch
> [ port_MessageOptionCB (\{ text } -> MessageOptionCB text)
> , onInfoConnect (\{ msg } -> InfoConnect msg.uid)
> , onRoomListInit (\{ msg, cb_data } -> RoomList_Init cb_data
> msg.roomlist)
> , onRoomListJoined (\{ msg, cb_data } -> RoomList_Joined cb_data
> msg.roomlist)
> , onRoomListParted (\{ msg, cb_data } -> RoomList_Parted cb_data
> msg.roomlist)
> , onRoomListNotif (\{ msg, cb_data } -> RoomList_Notif cb_data
> msg.msgs)
> , onRoomClosed (\{ msg, cb_data } -> Room_Part cb_data msg)
> , onRoomInfo (\{ msg, cb_data } -> Room_Info cb_data msg)
> , onRoomMsgsInit (\{ msg, cb_data } -> RoomMsg_Init cb_data msg)
> , onRoomMsgsNew (\{ msg, cb_data } -> RoomMsg_New cb_data msg)
> , onRoomUserInit (\{ msg, cb_data } -> RoomUser_Init cb_data msg)
> , onRoomUserJoined (\{ msg, cb_data } -> RoomUser_Joined cb_data msg)
> , onRoomUserParted (\{ msg, cb_data } -> RoomUser_Parted cb_data msg)
> , onRoomNotif (\{ msg, cb_data } -> RoomMsg_Notif cb_data msg.msgs)
> , onRoomSyncState (\{ msg, cb_data } -> RoomMsg_SyncState cb_data msg)
> , onRoomSyncJoin (\{ msg, cb_data } -> RoomMsg_SyncJoin cb_data msg)
> , onRoomSyncLeave (\{ msg, cb_data } -> RoomMsg_SyncLeave cb_data msg)
> , {- snip a *lot* more -}
>
> ```
>
> Although that call is in a module dedicated to ports and subscriptions so
> it is mostly out of sight, but when I had to touch it before it was quite a
> mess (and yes I should re-arrange the order of the cb_data, but meh, this
> way was more natural in the filter and update calls).
>
> Also, since my last email, more than 100 more lines total are gone. ^.^
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
