I'm definately with Wouter on this one.
Using tasks to do something that isn't a side-effect sounds much more like
a code smell than using plain old function calls and function return values
to compose your logic (when that is possible, which I would imagine would
be true most of the time, if n
Hi, I am on Wouter side on this. As a newcomer, I was not aware of these
things. I figured out a way to do this sendMsg function (which I called at
the time msgToCmd ^^) because I needed it at some point. And since it was
"so convenient" I ended up using it all the time instead of calling the
a
>
> The log then shows that between the DoStuff message and the DoMore
> message, a Tick message comes in.
>
Well, that's troubling and undermines my assumption. That's for looking
into this.
For those skimming through this post, *race conditions are possible when
doing something like `*Task.
For those interested: here is the example I refered to:
import Html exposing (..)
import Html.Events exposing (onClick)
import Time exposing (Time, second)
import Task
main =
Html.program
{ init = init
, view = view
, update = update
, subscriptions = subscriptions
}
-- MODE
Op dinsdag 22 november 2016 14:49:47 UTC+1 schreef Charlie Koster:
>
> My assumption is a race condition here wouldn't be possible since calling
> `sendMsg MyMsg` is a synchronous action
>
I have tried it out in elm-lang.org/try, which suggests that it is
asynchronous, in a simple setup
- button
> but I have seen terrible bugs being introduced by improper use, caused by
> Cmd messages being created based on model state A, and because of race
> conditions (e.g. fetch results coming in in the meantime)
>
My assumption is a race condition here wouldn't be possible since calling
`sendMsg
Op dinsdag 22 november 2016 13:47:55 UTC+1 schreef Charlie Koster:
>
> I respectfully disagree. Depending on the application, this either may not
> be possible or would be a terrible code smell. I honestly think the above
> suggestion would be worse than chaining another Cmd msg. Sending another
>
> One reason is what Evan says at
> https://github.com/elm-lang/core/blob/master/CONTRIBUTING.md#adding-new-functions:
>
> new functions are not so quickly expected to go into core, instead to be
> accumulated in *-extra packages first.
>
I didn't realize that was the case. Thanks for the in
My 2c: I kind of like it that there is NOT such a function in the core.
Because it *prevents me from grabbing it when I really shouldn't*.
Especially if the `Cmd` has no side effects, it is better to do a recursive
call to the `update` function, or better yet: call the function that your
comman
2016-11-22 4:04 GMT+01:00 Charlie Koster :
I don't see any reason why not have a function in Task that takes a msg and
> returns a Cmd msg.
One reason is what Evan says at
https://github.com/elm-lang/core/blob/master/CONTRIBUTING.md#adding-new-functions:
new functions are not so quickly expected
👍👍👍
On Mon, Nov 21, 2016 at 7:04 PM, Charlie Koster wrote:
> I'm a fan of the changes to Task.perform in Elm 0.18. However, I'm still
> finding that I'm writing a lot of boilerplate in some situations. For
> example, there are several instances when I want to send a msg which has no
> payload.
>
I'm a fan of the changes to Task.perform in Elm 0.18. However, I'm still
finding that I'm writing a lot of boilerplate in some situations. For
example, there are several instances when I want to send a msg which has no
payload.
Task.perform (\_ -> GoToLoginPage) (Task.succeed Nothing)
I do thi
12 matches
Mail list logo
