Yeah not in Elm, nor are Dicts able to go through ports. Could pass in a record, do string parsing, etc...
On Friday, August 12, 2016 at 1:06:07 PM UTC-6, Kasey Speakman wrote: > > Hmm, union types are JSON-serializable elsewhere (e.g. JSON.NET, although > they are uuuugly in JSON), so just something that eventually needs doing I > suppose. > > What conversion method did you have in mind that's not hard? > > On Friday, August 12, 2016 at 1:59:43 PM UTC-5, OvermindDL1 wrote: >> >> I entirely missed that. ^.^ >> >> Hmm, is interesting. Flags take Json'able types so those would not be >> passable there, would need to convert first, but not hard. >> >> >> >> On Friday, August 12, 2016 at 12:53:36 PM UTC-6, Kasey Speakman wrote: >>> >>> I did that if you look at link to marcosh's github I posted above. >>> >>> On Friday, August 12, 2016 at 1:50:12 PM UTC-5, OvermindDL1 wrote: >>>> >>>> Hmm, I'd be curious if you could whip up a full compileable example, >>>> say a Multi-Counter project example we could paste into elm-try. Perhaps >>>> mark things that are boilerplate and could be hoisted out to a parent >>>> library too so we can ignore those? :-) >>>> >>>> >>>> On Friday, August 12, 2016 at 12:15:20 PM UTC-6, Kasey Speakman wrote: >>>>> >>>>> Skimming through the code, it looks like batch commands will happen in >>>>> order. The mentioned `mailbox.push` was from the Elm source code. >>>>> >>>>> Also, I fleshed out an example with both a clean separation and using >>>>> event sourcing. I posted it with some commentary on marcosh's github >>>>> <https://github.com/marcosh/marcosh.github.io/issues/1>. >>>>> >>>>> I like the terminology in this example much better than my previous >>>>> examples, especially because `Action` was a previous concept in Elm. >>>>> >>>>> type Act = Increment | Decrement >>>>> >>>>> type Fact = Incremented Int | Decremented Int >>>>> >>>>> type Msg = Perform Act | Apply Fact >>>>> >>>>> perform : Act -> Model -> Cmd Msg >>>>> >>>>> apply : Fact -> Model -> Model >>>>> >>>>> update : Msg -> Model -> (Model, Cmd Msg) >>>>> update msg model = >>>>> case msg of >>>>> Perform act -> >>>>> (model, perform act model) >>>>> >>>>> Apply fact -> >>>>> (apply fact model, Cmd.none) >>>>> >>>>> >>>>> The Facts here are also idempotent >>>>> <https://en.wikipedia.org/wiki/Idempotence> (no dependency on >>>>> previous values). That's not as important in this example, but can as its >>>>> extended. >>>>> >>>>> On Friday, August 12, 2016 at 9:15:23 AM UTC-5, OvermindDL1 wrote: >>>>>> >>>>>> Will your pushed command appear after or before a potentially pushed >>>>>> 'other' command, say from an incoming port, or button click? That is >>>>>> the >>>>>> part I am not sure about yet (not read enough Elm internals 'quite' yet). >>>>>> >>>>>> On Thursday, August 11, 2016 at 6:31:06 PM UTC-6, Kasey Speakman >>>>>> wrote: >>>>>>> >>>>>>> Checked the current implementation of Cmd.batch and it appears >>>>>>> sequential (`mailbox.push`). Ordering guarantees are not documented so >>>>>>> I >>>>>>> suppose they shouldn't be depended on. But otherwise, the one I coded >>>>>>> above >>>>>>> that guarantees Act doesn't change the model and Evt doesn't have >>>>>>> effects >>>>>>> would work. >>>>>>> >>>>>>> On Thursday, August 11, 2016 at 6:33:39 PM UTC-5, Kasey Speakman >>>>>>> wrote: >>>>>>>> >>>>>>>> Yes, that's why I said back to square one if Cmd.batch isn't >>>>>>>> ordered. The only thing this is guaranteeing (and the only intended >>>>>>>> guarantee) is that the messages which only update the model are >>>>>>>> separated >>>>>>>> from the ones which cause effects. The ones which cause effects >>>>>>>> produce >>>>>>>> ones which update the model, same as always. >>>>>>>> >>>>>>>> It occurs to me that some of the benefit of event sourcing the UI >>>>>>>> could be gained by adding features to the TTD, since it has the magic >>>>>>>> which >>>>>>>> ignores Cmds on replay. Some are already listed as ideas at >>>>>>>> http://debug.elm-lang.org/. I'd still have to keep the messages in >>>>>>>> my model and provide a way for the user to transmit them in a bug >>>>>>>> report. >>>>>>>> But if I could load them in the TTD, that would make repro a snap. >>>>>>>> >>>>>>>> On Thursday, August 11, 2016 at 5:22:05 PM UTC-5, OvermindDL1 wrote: >>>>>>>>> >>>>>>>>> Isn't `doSideEffects` basically just the current `update` >>>>>>>>> function though? Except it is returning a list of changes (via >>>>>>>>> message) to >>>>>>>>> perform to a model instead of doing it in-place? What is this saving >>>>>>>>> precisely? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thursday, August 11, 2016 at 4:05:57 PM UTC-6, Kasey Speakman >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Actually, I'd probably use a List instead of Maybe on the >>>>>>>>>> immediately returned event(s). >>>>>>>>>> >>>>>>>>>> doSideEffects : Act -> Model -> (List Evt, Cmd Evt) >>>>>>>>>> doSideEffects act model = >>>>>>>>>> case act of >>>>>>>>>> UpdateCustomer customer -> >>>>>>>>>> ( [ CustomerUpdateRequested ] >>>>>>>>>> , callServerWithCustomer customer >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> updateModel : Evt -> Model -> Model >>>>>>>>>> ... -- implementation as previous >>>>>>>>>> >>>>>>>>>> update : Msg -> Model -> (Model, Cmd Msg) >>>>>>>>>> update msg model = >>>>>>>>>> case msg of >>>>>>>>>> Action act -> >>>>>>>>>> let >>>>>>>>>> (events, command) = doSideEffects act model >>>>>>>>>> in >>>>>>>>>> (List.foldr updateModel model events, Cmd.map Evt command >>>>>>>>>> ) >>>>>>>>>> >>>>>>>>>> Event evt -> >>>>>>>>>> (updateModel evt model, Cmd.none) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thursday, August 11, 2016 at 4:26:03 PM UTC-5, Kasey Speakman >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Yes, that was the goal. That way the UI state is utterly >>>>>>>>>>> deterministic / reproducible in isolation of all outside services. >>>>>>>>>>> >>>>>>>>>>> That's a good point on the race conditions. I only use Cmd.batch >>>>>>>>>>> because it's the facility that came to mind. (I'm still getting >>>>>>>>>>> acquainted >>>>>>>>>>> with Elm.) I don't know if Cmd.batch makes any ordering guarantee. >>>>>>>>>>> >>>>>>>>>>> If not we'd be more or less back to square one. Abuse `update` >>>>>>>>>>> to do both things. >>>>>>>>>>> >>>>>>>>>>> doSideEffects: Act -> Model -> (Maybe Evt, Cmd Evt) >>>>>>>>>>> doSideEffects act model = >>>>>>>>>>> case act of >>>>>>>>>>> UpdateCustomer customer -> >>>>>>>>>>> (Just CustomerUpdateRequested, callServerWithCustomer >>>>>>>>>>> customer) >>>>>>>>>>> >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> updateModel: Evt -> Model -> Model >>>>>>>>>>> ... -- implementation as previous >>>>>>>>>>> >>>>>>>>>>> maybeUpdateModel: Maybe Evt -> Model -> Model >>>>>>>>>>> maybeUpdateModel evtOpt model = >>>>>>>>>>> case evtOpt of >>>>>>>>>>> Nothing -> >>>>>>>>>>> model >>>>>>>>>>> >>>>>>>>>>> Just evt -> >>>>>>>>>>> updateModel evt model >>>>>>>>>>> >>>>>>>>>>> update : Msg -> Model -> (Model, Cmd Msg) >>>>>>>>>>> update msg model = >>>>>>>>>>> case msg of >>>>>>>>>>> Action act -> >>>>>>>>>>> let >>>>>>>>>>> (eventNow, command) = doSideEffects act model >>>>>>>>>>> in >>>>>>>>>>> (maybeUpdateModel eventNow model, Cmd.map Evt command) >>>>>>>>>>> >>>>>>>>>>> Event evt -> >>>>>>>>>>> (updateModel evt model, Cmd.none) >>>>>>>>>>> >>>>>>>>>>> So this should apply an event immediately if one is needed for >>>>>>>>>>> the action. But it still keeps the model updating events separate. >>>>>>>>>>> >>>>>>>>>>> These immediate events would be seen by a userland event-store >>>>>>>>>>> implementation (which is underneath updateModel), but I bet the TTD >>>>>>>>>>> wouldn't see it since it doesn't come from Elm. >>>>>>>>>>> >>>>>>>>>>> On Thursday, August 11, 2016 at 3:43:36 PM UTC-5, OvermindDL1 >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> So you really are wanting to hard device events into two >>>>>>>>>>>> different ones, those that can *only* alter the model, and those >>>>>>>>>>>> that can >>>>>>>>>>>> *only* send commands (which may call ones that alter the model). >>>>>>>>>>>> Unsure if >>>>>>>>>>>> it might actually happen but might have to take into account >>>>>>>>>>>> possible race >>>>>>>>>>>> conditions for if other messages appear before your other expected >>>>>>>>>>>> ones are >>>>>>>>>>>> processed through? Easier to do that atomically all at once? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thursday, August 11, 2016 at 2:25:22 PM UTC-6, Kasey >>>>>>>>>>>> Speakman wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> doSideEffects above would also have to map Cmd Evt to Cmd Msg. >>>>>>>>>>>>> >>>>>>>>>>>> -- 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.
