It is hurting elm in the long run as it makes people wrap js packages instead of creating pure elm solutions
Also if too many people is dependent of the target beeing js and the target changes you would see anger just like when native was removed from elm.
And using hacks not intended for the language might result in an impossible swich to the next elm where this is not available
Do you think that Tasks will be removed? I think that if they will they will come with a change that will make my patch unnecessary. For simple use cases where interop is limited, having Msg for every little thing can seem fine, but when creating Msgs becomes boilerplate, you know you need tasks.
Let me elaborate on that. In a single view we have different actions that have between 3 and 6 chained side effects (HTTP calls or JS INTEROP) and many of the side effects are shared between the processes. Let’s take one example chain of side effects:
GetAccessToken -> HTTP
Action1 -> JS INTEROP
Action2 -> JS INTEROP
Action3 -> JS INTEROP
Action4 -> JS INTEROP
StoreResults -> HTTP
Approaches we took:
- Create a different pair of ports for each different context in which we are using the same actions in the same view.
- Also, create a different message for the GetAccessToken depending on the path to initiate. For example,
- This leads to a very delicate update structure, in which you have most of the update function being a very uncomfortable way of managing a sorted sequence of steps.
- We created something we called
Procedure. You create a list of mini update functions that just cover one case. Whenever a message is received, first it is given to the procedures to see if there is a sequence waiting for the message, if not, is is passed to the main update function. It is much better, but still adds the need of having to create Msgs for every step, which are then ignored if they happen to reach the main update function. But at least we can reuse the same Msgs (and thus, the same subscriptions) in different procedures without having to add any
case to handle the different situations in which the same Msg could have been triggered.
- Type safety doesn’t help us here.
elm-effects-proxy, because it seems more meaningful.
- We have all the benefits of
elm/http: encoding, decoding, error handling, timeouts.
- We need only one Msg per operation we want to perform.