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

[Yonatan Kogan]

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 can 
live without needing any changes from the javascript data model is rare. I 
think fleshing out the "advanced usage" a bit more (maybe with one example) 
might help with that.

-- 
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.

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

[Alex Lew]

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 to the parent (in your case, a Bool might work -- should 
I or shouldn't I be removed?) -- Brian Hicks has a great & entertaining 
blog post about it 
here: 
https://www.brianthicks.com/post/2016/06/23/candy-and-allowances-parent-child-communication-in-elm/

best,
Alex

On Thursday, July 7, 2016 at 7:51:01 PM UTC-4, Mark Hamburg wrote:
>
> 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 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, my components 
> are more separated in depth, by four levels. Bit ugly, but seems it's all 
> we have right now. It actually appears elegant in contrast to my approach.
>
> 2016-07-07 21:18 GMT+02:00 Mark Hamburg 
> :
>
>> 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 
>> it belongs since this it's a view layout issue that forces the remove 
>> button to be included in the counter view. 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.
>>
>> Mark
>>
>> On Jul 7, 2016, at 10:50 AM, Sandi Dušić  
>> wrote:
>>
>> 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 
>> .
>>  
>> Each counter would have it's own remove button which would remove that 
>> exact one when clicked, unlike in the simpler example with a sole remove 
>> button that removes the first counter. This was accomplished by passing two 
>> addresses to the counter view, one for it's own actions and another which 
>> it's father component (CounterList) handled, used for signaling removal. 
>>
>> I did the exact same thing in my application. I have a bunch of small 
>> components in a big component, and the big component needs to know when one 
>> of the small ones has been clicked. How do you do this in 0.17? Is it 
>> impossible, since they removed the example which is supposed to implement 
>> it?
>>
>> This is the only thing I can think of: Add the message that needs to be 
>> sent upwards to the big component to the message union of the small 
>> component (in the CounterList, this would mean Counter.Msg has Remove). 
>> When the big component gets a small component action, it would first check 
>> with an if whether it's the one it needs to handle (if msg == 
>> Counter.Remove then ...). If so, it can handle it (remove the Counter), 
>> otherwise it would just regularly pass it to Counter.update.
>>
>> To me that seems like it goes against the principles of Elm Architecture. 
>> You can no longer treat components (and especially their actions) like 
>> black boxes, but rather you have to tear them apart in a way. They cannot 
>> fully define their interface. I don't know, it's just weird.
>>
>> If there's a way to define custom subscriptions they might be leveraged 
>> to solve this, but I don't see a way to do that in the API. I apologize if 
>> this is a silly question, 0.17 is still new to me.
>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Elm Discuss" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/elm-discuss/H1AUQelu78c/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> elm-discuss...@googlegroups.com .
>> For more options, visit 

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

[Mark Hamburg]

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 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, my components 
> are more separated in depth, by four levels. Bit ugly, but seems it's all we 
> have right now. It actually appears elegant in contrast to my approach.
> 
> 2016-07-07 21:18 GMT+02:00 Mark Hamburg :
>> 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 it 
>> belongs since this it's a view layout issue that forces the remove button to 
>> be included in the counter view. 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.
>> 
>> Mark
>> 
>>> On Jul 7, 2016, at 10:50 AM, Sandi Dušić  wrote:
>>> 
>>> 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. Each counter would 
>>> have it's own remove button which would remove that exact one when clicked, 
>>> unlike in the simpler example with a sole remove button that removes the 
>>> first counter. This was accomplished by passing two addresses to the 
>>> counter view, one for it's own actions and another which it's father 
>>> component (CounterList) handled, used for signaling removal. 
>>> 
>>> I did the exact same thing in my application. I have a bunch of small 
>>> components in a big component, and the big component needs to know when one 
>>> of the small ones has been clicked. How do you do this in 0.17? Is it 
>>> impossible, since they removed the example which is supposed to implement 
>>> it?
>>> 
>>> This is the only thing I can think of: Add the message that needs to be 
>>> sent upwards to the big component to the message union of the small 
>>> component (in the CounterList, this would mean Counter.Msg has Remove). 
>>> When the big component gets a small component action, it would first check 
>>> with an if whether it's the one it needs to handle (if msg == 
>>> Counter.Remove then ...). If so, it can handle it (remove the Counter), 
>>> otherwise it would just regularly pass it to Counter.update.
>>> 
>>> To me that seems like it goes against the principles of Elm Architecture. 
>>> You can no longer treat components (and especially their actions) like 
>>> black boxes, but rather you have to tear them apart in a way. They cannot 
>>> fully define their interface. I don't know, it's just weird.
>>> 
>>> If there's a way to define custom subscriptions they might be leveraged to 
>>> solve this, but I don't see a way to do that in the API. I apologize if 
>>> this is a silly question, 0.17 is still new to me.
>>> -- 
>>> 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 a topic in the 
>> Google Groups "Elm Discuss" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/elm-discuss/H1AUQelu78c/unsubscribe.
>> To unsubscribe from this group and all its topics, 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.

-- 
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.

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

[Sandi Dušić]

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, my components
are more separated in depth, by four levels. Bit ugly, but seems it's all
we have right now. It actually appears elegant in contrast to my approach.

2016-07-07 21:18 GMT+02:00 Mark Hamburg :

> 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
> it belongs since this it's a view layout issue that forces the remove
> button to be included in the counter view. 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.
>
> Mark
>
> On Jul 7, 2016, at 10:50 AM, Sandi Dušić  wrote:
>
> 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
> .
> Each counter would have it's own remove button which would remove that
> exact one when clicked, unlike in the simpler example with a sole remove
> button that removes the first counter. This was accomplished by passing two
> addresses to the counter view, one for it's own actions and another which
> it's father component (CounterList) handled, used for signaling removal.
>
> I did the exact same thing in my application. I have a bunch of small
> components in a big component, and the big component needs to know when one
> of the small ones has been clicked. How do you do this in 0.17? Is it
> impossible, since they removed the example which is supposed to implement
> it?
>
> This is the only thing I can think of: Add the message that needs to be
> sent upwards to the big component to the message union of the small
> component (in the CounterList, this would mean Counter.Msg has Remove).
> When the big component gets a small component action, it would first check
> with an if whether it's the one it needs to handle (if msg ==
> Counter.Remove then ...). If so, it can handle it (remove the Counter),
> otherwise it would just regularly pass it to Counter.update.
>
> To me that seems like it goes against the principles of Elm Architecture.
> You can no longer treat components (and especially their actions) like
> black boxes, but rather you have to tear them apart in a way. They cannot
> fully define their interface. I don't know, it's just weird.
>
> If there's a way to define custom subscriptions they might be leveraged to
> solve this, but I don't see a way to do that in the API. I apologize if
> this is a silly question, 0.17 is still new to me.
>
> --
> 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 a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/H1AUQelu78c/unsubscribe.
> To unsubscribe from this group and all its topics, 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.

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

[Alex Lew]

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` can either be a message-for-the-root-component or a 
message-for-the-component-itself. When the parent uses `Cmd.map` on these 
wrapped messages, it lets root messages through unchanged, but tags other 
messages as being for-the-child.

Here's the code. First, create a separate module called, e.g., 
`RootMessage`, that looks like this:

module RootMessage exposing (..)

type RootMessage = 
   LoginFailed Http.Error

type Wrapped msg = Internal msg | ForRoot RootMessage

tag : (childMsg -> parentMsg) -> Wrapped childMsg -> Wrapped parentMsg
tag tagger msg =
  case msg of
 Internal m -> Internal (tagger m)
 ForRoot r -> ForRoot r

Then, in each *non-root* module, you do something like the following. Here, 
we have a Child module that includes a Grandchild component.

module Child exposing (..)

import RootMessage exposing (..)

type Msg = GrandchildMsg Grandchild.Msg 
 | APIResponse String 
 | ButtonPressed 

update : Msg -> Model -> (Model, Cmd (Wrapped Msg))
update msg model = 
  case msg of
GrandchildMsg subMsg -> 
  let 
(newModel, cmd) = Grandchild.update subMsg model.grandchild 
  in
{ model | grandchild = newModel } ! [ Cmd.map (tag GrandchildMsg) 
cmd ]

ButtonPressed -> 
  model ! [ Task.perform (ForRoot << LoginFailed) (Internal << 
APIResponse) Http.get... ]

The trick here is in `Cmd.map (tag GrandchildMsg) cmd`. The `tag` function, 
defined in the RootMessage module, takes in a normal tag, like 
GrandchildMsg, but returns a "tagger" that only applies the `GrandchildMsg` 
tag to non-root messages. It leaves the root messages unaltered.

Finally, in the root, you can handle these generated root messages:

module Root exposing (..)

import RootMessage exposing (..)
import Child exposing (..)

type Msg = Something | AnotherThing | ChildMsg Child.Msg

update : Wrapped Msg -> Model -> (Model, Cmd (Wrapped Msg))
update msg model =
   case msg of
  ForRoot LoginFailed err -> ...
  Internal Something -> ...
  Internal AnotherThing -> ...
  Internal ChildMsg subMsg -> 
let 
  (newModel, cmd) = Child.update subMsg model.child 
in 
  { model | child = newModel } ! [ Cmd.map (tag ChildMsg) cmd ]


Sorry for the terseness -- happy to elaborate if something is unclear!

-Alex


On Thursday, July 7, 2016 at 11:30:08 AM UTC-4, Erik Lott wrote:
>
> 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 architecture doesn't easily 
> allow for application specific communication from the lower nested 
> components to the upper components. There are times when in the scope of an 
> overall architecture, you'd like to return some type of application wide 
> recognized event/message back up the update stack, and have any interested 
> ancestor component react to it... This is essentially how Commands 
> function. Commands are a globally recognized type, that are returned up the 
> stack, and although they may carry a local message type with them, the 
> command itself is never returned or reused. The Command reaches the 
> application root, and is processed by the core language.
>
> Like you said: I think what we need (or at least what I need) is our own 
> Application specific type to return up the stack instead of Cmd. An "Event" 
> union type possibly? And CmdEvt tag could wrap the native elm Cmd, and be 
> unwrapped at the root.
>
> type Event 
>   = CmdEvt Cmd
>   | MsgEvt
>   | Unauthorized
>   | LoggedIn User
>   | ConfirmPopup CancelMsg OkMsg
>
>
>
> On Tuesday, July 5, 2016 at 1:30:51 PM UTC-4, Mark Hamburg wrote:
>>
>> The first option feels repugnant from an encapsulation standpoint. I've 
>> built the second option and it works but it increases the amount of 
>> boilerplate in hierarchical systems because we now have three results to 
>> deal with in update functions. 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). That said, once one gets into replacing 
>> Cmd, the API request model makes a lot of sense.
>>
>> Mark
>>
>> On Jul 5, 2016, at 5:46 AM, Erik Lott  wrote:
>>
>> My app has several layers of nested components. Various components 
>> throughout the tree will need to interact with our API via http requests. 
>> If any API request returns a 401 - Not 

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

[Charlie Koster]

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 
scientific method. Are semi-colons useful? Are the traditional looping 
constructs confusing? Which syntax is easier for newcomers to pick up on 
vs. which syntax makes more experienced devs more productive? It's the idea 
of guiding language design based on measured evidence rather than 
historical convention or assumed subject matter expertise.

These questions are testable hypotheses. By incorporating control groups, 
we can more confidently say that certain aspects of the Elm language are 
actually better than alternatives. Or better than competing languages.

It goes farther than saying which is better. Taking a scientific approach 
should actually yield a better developer experience with Elm.

Anyway, I think there's enough community members that we can find 
volunteers and run these kinds of experiments, draw conclusions, and 
iteratively and objectively continue to improve Elm.

-- 
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.

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

[Mark Hamburg]

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 it belongs since 
this it's a view layout issue that forces the remove button to be included in 
the counter view. 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.

Mark

> On Jul 7, 2016, at 10:50 AM, Sandi Dušić  wrote:
> 
> 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. Each counter would have 
> it's own remove button which would remove that exact one when clicked, unlike 
> in the simpler example with a sole remove button that removes the first 
> counter. This was accomplished by passing two addresses to the counter view, 
> one for it's own actions and another which it's father component 
> (CounterList) handled, used for signaling removal. 
> 
> I did the exact same thing in my application. I have a bunch of small 
> components in a big component, and the big component needs to know when one 
> of the small ones has been clicked. How do you do this in 0.17? Is it 
> impossible, since they removed the example which is supposed to implement it?
> 
> This is the only thing I can think of: Add the message that needs to be sent 
> upwards to the big component to the message union of the small component (in 
> the CounterList, this would mean Counter.Msg has Remove). When the big 
> component gets a small component action, it would first check with an if 
> whether it's the one it needs to handle (if msg == Counter.Remove then ...). 
> If so, it can handle it (remove the Counter), otherwise it would just 
> regularly pass it to Counter.update.
> 
> To me that seems like it goes against the principles of Elm Architecture. You 
> can no longer treat components (and especially their actions) like black 
> boxes, but rather you have to tear them apart in a way. They cannot fully 
> define their interface. I don't know, it's just weird.
> 
> If there's a way to define custom subscriptions they might be leveraged to 
> solve this, but I don't see a way to do that in the API. I apologize if this 
> is a silly question, 0.17 is still new to me.
> -- 
> 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.

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

[Sandi Dušić]

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 
.
 
Each counter would have it's own remove button which would remove that 
exact one when clicked, unlike in the simpler example with a sole remove 
button that removes the first counter. This was accomplished by passing two 
addresses to the counter view, one for it's own actions and another which 
it's father component (CounterList) handled, used for signaling removal. 

I did the exact same thing in my application. I have a bunch of small 
components in a big component, and the big component needs to know when one 
of the small ones has been clicked. How do you do this in 0.17? Is it 
impossible, since they removed the example which is supposed to implement 
it?

This is the only thing I can think of: Add the message that needs to be 
sent upwards to the big component to the message union of the small 
component (in the CounterList, this would mean Counter.Msg has Remove). 
When the big component gets a small component action, it would first check 
with an if whether it's the one it needs to handle (if msg == 
Counter.Remove then ...). If so, it can handle it (remove the Counter), 
otherwise it would just regularly pass it to Counter.update.

To me that seems like it goes against the principles of Elm Architecture. 
You can no longer treat components (and especially their actions) like 
black boxes, but rather you have to tear them apart in a way. They cannot 
fully define their interface. I don't know, it's just weird.

If there's a way to define custom subscriptions they might be leveraged to 
solve this, but I don't see a way to do that in the API. I apologize if 
this is a silly question, 0.17 is still new to me.

-- 
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.

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

[Simon]

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 not clear to me is how you are using this technique in terms of 
> authentication. BTW: I'm generally a systems & server dev, so I'm likely 
> bringing that baggage with me.
>
> Here are some things that are not clear to me:
>
>1. Digging through elm app source code, I often see a "Maybe 
>currentUser" field stored directly on the root model, and I that's fine. 
>Let's say I also have a nested LoginComponent for my UI, and this 
> component 
>does not have access to that root model (this is sort of obvious). When a 
>user uses this component to successfully authenticate themselves (the 
>LoginComponent makes the http request with the server), how am I then 
>communicating a successful login back up to the root model? Should the 
>LoginComponent directly return some data from it's update method - like 
>this 
>
> 
>?
>2. If a nested component receives an 401 response back from the API, 
>how should I then propagate that response back up to the root so that the 
>current user can be logged out (currentUser = Nothing)?
>
> Am I thinking about this in the wrong way?
>
>
>
> On Wednesday, July 6, 2016 at 3:12:54 PM UTC-4, Scott Corgan wrote:
>>
>> Here's an article that elaborates a bit more: 
>> https://www.brianthicks.com/post/2016/07/05/duplicate-message-or-update-contexts-in-elm-components/
>> .
>>
>> Then, in each parent's update function, you are calling the child's 
>> update function. But, instead of just calling "ChildComponent.update msg 
>> model", you'll call "ChildComponent.update context msg model"
>>
>> Does that help?
>>
>>
>> On Wed, Jul 6, 2016 at 2:57 PM Erik Lott  wrote:
>>
>>> Can you explain how this works?
>>>
>>>
>>>
>>>
>>> On Wednesday, July 6, 2016 at 2:37:57 PM UTC-4, Scott Corgan wrote:

 It seems like the easiest approach at this point is a combination of 
 binding a context type as the first argument to your update functions and 
 sending the Navigation.newUrl command from the updateUrl function (used by 
 Navigation).

 urlUpdate : Context -> Navigation.Location ->  ( Model, Cmd a )

 and the rest of the update functions:

 update : Context -> a -> Model -> ( Model, Cmd a )

 On Wednesday, July 6, 2016 at 2:05:25 PM UTC-4, Erik Lott wrote:
>
> *Is there an idiomatic/proven way to approach Authentication in an Elm 
> single page app?* Sadly, there are very few resources online that 
> touch on authentication, yet it's an unavoidable part of SPA development. 
> It would be great if this discussion could serve as the best answer to 
> this 
> question.
>
> In our case, I am evaluating Elm for a Single Page Application. We 
> have a simple json api, as follows:
>
> The API:
>
>
>- POST /sessions  - post a username/password. If the credentials 
>are authentic, it returns 200 OK along with a secure http-only cookie.
>- GET /me - returns 200 OK with user record or 401 Unauthorized
>
>
> Our Elm requirements:
>
>- When the client app loads, it makes a request to /me to see if 
>the user is currently logged in. If 200 OK, store the current user in 
> elm 
>and display to the Dashboard page. If not, display the login page.
>- On a successful login, make a request to /me to retrieve the 
>current user record, store the current user in elm, and display 
>the Dashboard page.
>- If an API response ever returns 401 Unauthorized, remove the 
>current user record on the elm model, and display the login page
>
>
> I'm sure that any guidance from community would be appreciated by all!
>
>
> -- 
>>> 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...@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.

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

[Erik Lott]

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 architecture doesn't easily 
allow for application specific communication from the lower nested 
components to the upper components. There are times when in the scope of an 
overall architecture, you'd like to return some type of application wide 
recognized event/message back up the update stack, and have any interested 
ancestor component react to it... This is essentially how Commands 
function. Commands are a globally recognized type, that are returned up the 
stack, and although they may carry a local message type with them, the 
command itself is never returned or reused. The Command reaches the 
application root, and is processed by the core language.

Like you said: I think what we need (or at least what I need) is our own 
Application specific type to return up the stack instead of Cmd. An "Event" 
union type possibly? And CmdEvt tag could wrap the native elm Cmd, and be 
unwrapped at the root.

type Event 
  = CmdEvt Cmd
  | MsgEvt
  | Unauthorized
  | LoggedIn User
  | ConfirmPopup CancelMsg OkMsg



On Tuesday, July 5, 2016 at 1:30:51 PM UTC-4, Mark Hamburg wrote:
>
> The first option feels repugnant from an encapsulation standpoint. I've 
> built the second option and it works but it increases the amount of 
> boilerplate in hierarchical systems because we now have three results to 
> deal with in update functions. 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). That said, once one gets into replacing 
> Cmd, the API request model makes a lot of sense.
>
> Mark
>
> On Jul 5, 2016, at 5:46 AM, Erik Lott  
> wrote:
>
> My app has several layers of nested components. Various components 
> throughout the tree will need to interact with our API via http requests. 
> If any API request returns a 401 - Not Authorized error, or a Timeout 
> Error, the error needs to bubble up to the root component where is can be 
> handled appropriately.
>
> What is the most idiomatic way of dealing with this? 
>
> *1. Parent should pattern match against important child messages*: 
> Reference 
> 
> This could work, but would be unreasonable in this case. The root 
> component would need to match against every failing api http request made 
> by every child, grandchild, great-grandchild, etc, component in the tree. 
> If a single pattern is missed, the app would be in an error state, so this 
> is prone to mistakes.
>
> *2. Nested Components return additional info from the "update" function*: 
> Reference 
> 
> Each component returns an additional value from its update function like 
> this:
> update : Msg -> Model -> (Model, Cmd Msg, SomeInfo)
>
> The parent component could inspect the returned "SomeInfo" value from its 
> direct children, and act on that information if necessary.  In my case, any 
> nested component that makes http requests to our API would be responsible 
> for returning a APINotAuthorized and APITimeout value to its parent, and 
> its parent would do the same, until the error has bubbled up to the root 
> component.
>
>
> Option 2 is simple and robust, and can be used to pass messages of any 
> type, for any situation... but I'm wondering if I'm missing an obvious 3rd 
> solution?
>
> -- 
> 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...@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.