[elm-discuss] Re: Draft blog post - "How to Use Elm at Work" - looking for feedback

I think this is super awesome. We tried to create some Elm components that could live as part of the React view and really struggled. I echo the other sentiments, however, that the tone of the post feels a bit prescriptive (perhaps by design) and that the specific case of an Elm component that

Re: [elm-discuss] Sending messages up the component tree in Elm 0.17

I wrote about a generalization of that pattern a week or so ago, in case you're interested: https://medium.com/@alex.lew/the-translator-pattern-a-model-for-child-to-parent-communication-in-elm-f4bfaa1d3f98 Another pattern that seems very popular is to have the child's update return the signal

Re: [elm-discuss] Sending messages up the component tree in Elm 0.17

Yes, the view would return Html parentMsg. The signature would be something like: view: (ChildMessage -> parentMsg) -> parentMsg -> ChildModel -> Html parentMsg Note that parentMsg is parameterized. Mark > On Jul 7, 2016, at 3:27 PM, Sandi Dušić wrote: > > Thank you

Re: [elm-discuss] Sending messages up the component tree in Elm 0.17

Thank you Mark! One way to do this is to extend the view function with two arguments: one > is a function to map the counter messages to the parent message space and > the other is the parent message that the remove button should send. Would the child view then return Html ParentMsg? In reality,

Re: [elm-discuss] Bubbling Http Errors from Nested Components

Here's one way to achieve the all-http-errors-should-go-to-root functionality described by OP. I'm not sure I love it, but thought I'd throw it in. A general idea of what's going on: every component, rather than just returning a `Cmd Msg`, produces a `Cmd (Wrapped Msg)`, where a `Wrapped Msg`

[elm-discuss] An Evidence-Oriented Programming approach to designing Elm

I watched a video from StrangeLoop 2015 and it made assertions that I think are worth considering when making decisions about Elm's future design. In summary, the presenter asserted that programming language design should be guided through the

Re: [elm-discuss] Sending messages up the component tree in Elm 0.17

We're still awaiting an official answer from Evan. In the meantime, the best answer I've seen from the standpoint of not contaminating the counter messages and update function with something that they don't care about is to put the complexity in the view function which is, I would argue, where

[elm-discuss] Sending messages up the component tree in Elm 0.17

In Elm 0.16 the Architecture tutorial had one more button list example (I dug that up from an old commit), aside from this one

Re: [elm-discuss] Re: Authentication & Session Management

I wrote this a short while ago http://simonh1000.github.io/2016/05/phoenix-elm-json-web-tokens/ On Wednesday, 6 July 2016 21:48:58 UTC+2, Erik Lott wrote: > > Yup, I understand passing down config (context) data down through the > update methods so they can be used in http requests. > > What's

Re: [elm-discuss] Bubbling Http Errors from Nested Components

Mark: That's lead me to think about but not yet write a command alternative that > could also handle tasks that didn't need to be routed back to the > originator and that could be used to send messages to the top-level (or > elsewhere). I think you've nailed it. The suggested ELM