[elm-discuss] Re: http "middleware" options

[Fa Qing]

I understand, and appreciate the suggestion. But I'm looking for a more 
generic solution here. I can't work around cookie restraints in all of my 
use cases, unfortunately (maybe using an auth token as an example was bad 
idea).

Think about that problem of handling http errors at the root level (letting 
them "bubble up"). It's essentially the same sort of problem. 

I need to learn more about how commands actually work. Are command return 
values all fed back through a single message dispatcher (considering the 
manner in which the messages flow back down our UI hierarchy)? 

Although I think it's current hard to get a clean abstraction, it's hard to 
think of a good solution to fix it...

RootLevel _ PageLevel
  \   |
   \_> ServiceLevel

The PageLevel is calling the service level for a command. We want 
intermediate effects, before the final command. But we don't want to just 
issue intermediate commands either, because the state that is reacting to 
the final command (the only one we have currently) could also be affected 
by the intermediate command. Also, it doesn't help us refactor out the 
(common) inputs into the service layer, such as a header value we need to 
write out.

It seems like there's a missing abstraction from the Elm architecture.

But this is tricky. Effectively, I'm wishing that a service module could 
maintain some state of it's own that doesn't need to be threaded through 
the entire UI hierarchy. Or perhaps the state could still be maintained at 
the root, but the service modules would have a way of fetching state and 
communicating state change messages to the root, without passing through 
the UI hierarchy. I recognize that this puts me in dangerous territory 
though, because that is also the essence of much talk about inter-component 
communication, which I think usually heads down the wrong path (for 
understandable reasons, but wrong all the same). 




On Thursday, October 13, 2016 at 1:08:22 AM UTC+9, Rupert Smith wrote:

> On Wednesday, October 12, 2016 at 2:13:16 PM UTC+1, Fa Qing wrote:
>>
>> Let's say that every response includes a dynamic "token" header value, 
>> and every request needs to return that token in the headers.
>>
>
> Don't forget that you can use a cookie or secure cookie for this purpose. 
> Its hard to see that using a bearer token in an Authorization header is 
> better than a secure cookie, because - the browser enforces some extra 
> constraints around secure cookie to make them more secure and the cookies 
> are shared accross a domain meaning if the user pops up a second tap by 
> ctrl-clicking a link in your application, authentication can flow accross. 
> However, it seems not to be the done thing for REST APIs.
>

-- 
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: Teaching children Elm

[Tanya Bouman]

No, we don't have any video recordings of our sessions.

Tanya

On Monday, October 10, 2016 at 4:18:37 AM UTC-4, Fedor Nezhivoi wrote:
>
> Thank you for your answers.
>
> @Javis, do you have any plans of having an English translation?
>
> @Tanya, do you have any video recordings of your sessions?
>
> On Thu, Oct 6, 2016 at 1:43 PM Will White  > wrote:
>
>> And if someone yelled "Five" I'd say
>>
>> -- MISSING PATTERNS  
>> counter.elm
>>
>>
>> This `case` does not have branches for all possibilities.
>>
>>
>> 36|>case msg of
>>
>> 37|>Increment ->
>>
>> 38|>model + 1
>>
>> 39|>
>>
>> 40|>Decrement ->
>>
>> 41|>model - 1
>>
>> You need to account for the following values:
>>
>>
>> Main.Five
>>
>>
>> Add a branch to cover this pattern!
>>
>> Or words to that effect.
>>
>> On Thursday, October 6, 2016 at 11:36:44 AM UTC+1, Will White wrote:
>>>
>>> I've been thinking about how I'll give a talk about Elm (at a JS event 
>>> in Nottingham, UK). To demonstrate Model-Update-View, I think I'll start 
>>> with the Counter example, but instead of in code, in real life. So I'd say 
>>> "I'm a counter, I'm on 0. Increment and Decrement me." and end up with a 
>>> room of people yelling "Up" and "Down" with me going "4! 5! 4! 3!". Then 
>>> we'll code it.
>>>
>>> Just thought your 14-16 yos might find that fun and illustrative.
>>>
>>> On Tuesday, October 4, 2016 at 6:33:04 AM UTC+1, Fedor Nezhivoi wrote:

 Hello folks,


 Evan, Richard and the whole community as well as Elm language itself do 
 a great job in teaching community. If you are staying with this community 
 for a long time, you probably already can notice some improvements in your 
 understanding of programming, API design, abstractions and etc. How can we 
 take it even further?


 Recently I got an opportunity to share some knowledge about functional 
 programming and programming in general. However target audience are 
 children (mostly 14-16 y.o.) and I am a little bit stuck. Not only I've 
 never been a teacher, but with children I expect it to be even harder 
 because of curse of knowledge. On the other hand trying to teach some 
 boring basics doesn't feel right, to be interesting it should be kind of 
 journey.


 Previously there was some information about courses in USA where 
 children are thought programming with Elm. So I am kindly ask people who 
 are doing this to share your experience, tips, tricks and whatever may be 
 helpful. It would be even better if you can share some actual 
 content/topics/lessons/exercises. If you know exact person, but they are 
 not here, please, provide me with contacts.


 *I am kindly ask you to abstain from discussions and only participate 
 if you have something concrete.*


 Have a nice day!

>>> -- 
>> 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/DjsnRPfHYN8/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> elm-discuss...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> Best regards,
> Fedor Nezhivoi
>

-- 
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] http "middleware" options

[Fa Qing]

Somehow at that point it seems like we have effectively given up on a clean 
architecture though.

We extracted out our API layer (or at least our transport layer), yet we're 
still having to take both inputs and return values and pass them through 
(every) unrelated entity that calls the API layer. At which point I'm not 
sure I would even want to abstract out the API layer beyond creating a few 
common helper functions. I can shake the feeling that this is a messy 
architecture that doesn't lend itself a clean abstraction with regard to 
these sorts of service modules.

It's a trivial thing, I suppose, to drop down to JS and do this (or as 
Rupert mentioned, use cookies for use cases where cookie restrictions 
aren't too constraining), but I think it would be strongly preferable to 
have a generic  way of doing this directly in Elm.



On Thursday, October 13, 2016 at 1:07:44 AM UTC+9, Peter Damoc wrote:

>
>
> On Wed, Oct 12, 2016 at 6:50 PM, Fa Qing  > wrote:
>
>> Goal
>> [AppRoot] -> [UsersPage] --> ask api for users, and upon success, 
>> 1. send the UsersFetchSuccess message (attaching the users); so far so 
>> good, but then also I need to...
>> 2. replace the token by sending the BumpToken message at the root level 
>> of the app.
>>
>
>  
> I would approach this by making UserFetchSuccess incorporate the token. 
>
> type Msg 
> = UserFetchSuccess Token UserData
>
> and handle the bumping of the token afterwards by maybe extending the 
> update signature with a Maybe Token
>
>
>  
>
> -- 
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>

-- 
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: Function equality again

[Mark Hamburg]

I gather there has been trepidation about implementing an equatable built in 
"type class" akin to the existing "comparable", but I agree that if the plan is 
never to support function comparison, then equatable seems to be necessary if 
Elm is to live up to its "no runtime errors" goal.

As for examples of where this matters, easing functions are an example. Needing 
to keep tagger functions around would be an example. (For example, a web socket 
based request/response system would send the request and then watch the message 
subscription for a matching response and post it back as a message using a 
tagger function much as HTTP-based commands do.) There are a lot of places 
where hanging onto a function in the model is useful and the alternatives are 
convoluted. Note that all of those would likely work fine with reference 
equality and would be even more likely to work fine with one level of reference 
equality checks on the code and the closure values. Most of those cases also 
don't inherently need equality checks, but without compiler support to prevent 
them, such checks can come further up in the model logic possibly in an effort 
to suppress updates that didn't change anything.

Mark

> On Oct 12, 2016, at 1:04 PM, Joey Eremondi  wrote:
> 
> A compile-time error is definitely possible. Haskell has it, but it uses the 
> full power of type classes.
> 
> To catch it at compile time, we'd either need to treat equality like 
> comparable, which sucks for user-defined types, or do something that looks 
> more like Haskell's type classes, with a bunch of automatic deriving. I'd 
> advocate the latter, although I think it could be done in a way that hides 
> most of the typeclassy stuff from the user.
> 
>> On Wed, Oct 12, 2016 at 12:59 PM, Kasey Speakman  
>> wrote:
>> For context for future readers, this has to do with animation easing 
>> functions from another thread. I have not constructed such a library, so I 
>> won't comment.
>> 
>>> On Wednesday, October 12, 2016 at 2:43:58 PM UTC-5, Zinggi wrote:
>>> I also think that comparing functions should just compare them by 
>>> reference, this should cover the most common cases.
>>> 
>>> Another possible solution: What about a compile time error? Is this 
>>> possible?
>>> 
 On Wednesday, 12 October 2016 18:48:12 UTC+2, Mark Hamburg wrote:
 As discussed elsewhere, the runtime exception related to function equality 
 comparisons is a lurking time bomb for code that is really only addressed 
 on a multi-developer project by being paranoid both about functions in 
 data structures and use of the equality operator. Both points of paranoia 
 get in the way of writing "good" code. There are other arguments around 
 things like serialization for avoiding using functions in some places, but 
 there are lots of other places where it is extremely useful to put 
 functions in data structures. (Imagine writing an effects manager if it 
 couldn't store functions in its data structures.) 
 
 Full equality tests are, as I understand it, undecidable. That doesn't 
 mean, however, that some limited analysis can't prove equality in most of 
 the conditions that matter. In fact, the existing code doesn't always 
 throw an exception. It only throws an exception if an "allocation 
 identity" test fails. One could extend this to looking at the "code 
 pointer" and allocation identity for the closure values and probably get 
 many of the remaining cases that mattered. It's just a matter of how far 
 one wants to push when trying to prove or disprove equality and I'm not 
 arguing for a particular limit here. 
 
 Rather, I think the central issue is around what happens when we give up. 
 At that point, there are two choices: throw a runtime exception as happens 
 now or return false. As mentioned above and discussed at further length 
 elsewhere, the runtime exception leads to paranoid coding. What are the 
 issues with returning false? The big problem with returning false is that 
 this means that some compiler optimizations might then change cases that 
 returned false without the optimizations into cases that returned true and 
 people become understandably uncomfortable with the possibility that 
 compiler optimizations could change the meaning of programs. And with 
 that, I've more or less wanted a "return false" answer but convinced 
 myself that throwing an exception wasn't unjustified and that maybe what 
 we needed instead was type system support to avoid the issue. 
 
 But then this morning's discussion of the virtual DOM had me realizing 
 that runtime optimizations around when the render-diff-patch algorithm 
 gets run create significant potential for variable program behavior. We 
 embrace these optimizations even though they introduce non-determinism. 
 Now, 

[elm-discuss] elm-google-geocoding - An Elm interface to the Google Geocoding API

[Sasha Voynow]

http://package.elm-lang.org/packages/labzero/elm-google-geocoding/latest
https://github.com/labzero/elm-google-geocoding

Bugs, PRs, comments, API design suggestions extremely welcome!

-- 
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] Proper want to detach Elm from DOM node embedded in

[kanishka azimi]

I grabbed the Elm DOM node and set innerHTML to empty. Is that correct? 
Should I be grabbing the parent of the Elm node and erasing the Elm node 
and adding it back to the DOM? Is there anything else I need to do to 
reverse the "embed" action?

I know this isn't typical. I am trying to keep my Elm app simple and not 
introduce a port and message to invoke reseting behavior for now. Instead, 
I am calling embed whenever I need a my Elm app displayed. In this way, I 
can just rely on the fact that the Elm app is started in a clean state 
every time it is displayed.

-- 
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] Re: Function equality again

[Zinggi]

I also think that comparing functions should just compare them by 
reference, this should cover the most common cases.

Another possible solution: What about a compile time error? Is this 
possible?

On Wednesday, 12 October 2016 18:48:12 UTC+2, Mark Hamburg wrote:
>
> As discussed elsewhere, the runtime exception related to function equality 
> comparisons is a lurking time bomb for code that is really only addressed 
> on a multi-developer project by being paranoid both about functions in data 
> structures and use of the equality operator. Both points of paranoia get in 
> the way of writing "good" code. There are other arguments around things 
> like serialization for avoiding using functions in some places, but there 
> are lots of other places where it is extremely useful to put functions in 
> data structures. (Imagine writing an effects manager if it couldn't store 
> functions in its data structures.) 
>
> Full equality tests are, as I understand it, undecidable. That doesn't 
> mean, however, that some limited analysis can't prove equality in most of 
> the conditions that matter. In fact, the existing code doesn't always throw 
> an exception. It only throws an exception if an "allocation identity" test 
> fails. One could extend this to looking at the "code pointer" and 
> allocation identity for the closure values and probably get many of the 
> remaining cases that mattered. It's just a matter of how far one wants to 
> push when trying to prove or disprove equality and I'm not arguing for a 
> particular limit here. 
>
> Rather, I think the central issue is around what happens when we give up. 
> At that point, there are two choices: throw a runtime exception as happens 
> now or return false. As mentioned above and discussed at further length 
> elsewhere, the runtime exception leads to paranoid coding. What are the 
> issues with returning false? The big problem with returning false is that 
> this means that some compiler optimizations might then change cases that 
> returned false without the optimizations into cases that returned true and 
> people become understandably uncomfortable with the possibility that 
> compiler optimizations could change the meaning of programs. And with that, 
> I've more or less wanted a "return false" answer but convinced myself that 
> throwing an exception wasn't unjustified and that maybe what we needed 
> instead was type system support to avoid the issue. 
>
> But then this morning's discussion of the virtual DOM had me realizing 
> that runtime optimizations around when the render-diff-patch algorithm gets 
> run create significant potential for variable program behavior. We embrace 
> these optimizations even though they introduce non-determinism. Now, its 
> non-determinism at the level of the physical DOM rather than the values 
> produced in Elm itself — i.e., runtime v linguistic non-determinism — but 
> its non-determinism in one of the most fundamental parts about how Elm is 
> generally used so that distinction seems somewhat arbitrary. 
>
> I think Elm makes the right call on the DOM. Maybe it should log cases 
> where the DOM logic can recognize that there might be a problem, but I 
> think this is overall a tradeoff worth making. 
>
> But by the same argument, I think Elm programs would be better if the 
> runtime exception for function equality comparisons was replaced with a 
> false result even though it might actually be true. And if it's really 
> irksome, then it could generate a log statement as well. 
>
> Mark 
>
>
>
>

-- 
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] Re: Pure Elm contenteditable rich text editor

[RGBboy]

You should read this article to see why existing solutions generally do not 
work very 
well: https://medium.engineering/why-contenteditable-is-terrible-122d8a40e480

I am pretty sure draft.js has a good underlying data model that copes with 
mapping to the DOM well. Perhaps looking into how that works could give you 
some direction.

Like Luke says, you will need to use the selection API via a port.

When I first started looking into Elm this was something that I was 
interested in creating so I am keen to see how you get on. 

Good luck.


-- 
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] Re: Function equality again

[James Wilson]

I basically agree - something as basic as using an equality test should not 
have any chance to cause a runtime error in any case; in the case of 
functions it should be based on referential equality, which I think does 
the right thing in any sane case.

On Wednesday, 12 October 2016 17:48:12 UTC+1, Mark Hamburg wrote:
>
> As discussed elsewhere, the runtime exception related to function equality 
> comparisons is a lurking time bomb for code that is really only addressed 
> on a multi-developer project by being paranoid both about functions in data 
> structures and use of the equality operator. Both points of paranoia get in 
> the way of writing "good" code. There are other arguments around things 
> like serialization for avoiding using functions in some places, but there 
> are lots of other places where it is extremely useful to put functions in 
> data structures. (Imagine writing an effects manager if it couldn't store 
> functions in its data structures.) 
>
> Full equality tests are, as I understand it, undecidable. That doesn't 
> mean, however, that some limited analysis can't prove equality in most of 
> the conditions that matter. In fact, the existing code doesn't always throw 
> an exception. It only throws an exception if an "allocation identity" test 
> fails. One could extend this to looking at the "code pointer" and 
> allocation identity for the closure values and probably get many of the 
> remaining cases that mattered. It's just a matter of how far one wants to 
> push when trying to prove or disprove equality and I'm not arguing for a 
> particular limit here. 
>
> Rather, I think the central issue is around what happens when we give up. 
> At that point, there are two choices: throw a runtime exception as happens 
> now or return false. As mentioned above and discussed at further length 
> elsewhere, the runtime exception leads to paranoid coding. What are the 
> issues with returning false? The big problem with returning false is that 
> this means that some compiler optimizations might then change cases that 
> returned false without the optimizations into cases that returned true and 
> people become understandably uncomfortable with the possibility that 
> compiler optimizations could change the meaning of programs. And with that, 
> I've more or less wanted a "return false" answer but convinced myself that 
> throwing an exception wasn't unjustified and that maybe what we needed 
> instead was type system support to avoid the issue. 
>
> But then this morning's discussion of the virtual DOM had me realizing 
> that runtime optimizations around when the render-diff-patch algorithm gets 
> run create significant potential for variable program behavior. We embrace 
> these optimizations even though they introduce non-determinism. Now, its 
> non-determinism at the level of the physical DOM rather than the values 
> produced in Elm itself — i.e., runtime v linguistic non-determinism — but 
> its non-determinism in one of the most fundamental parts about how Elm is 
> generally used so that distinction seems somewhat arbitrary. 
>
> I think Elm makes the right call on the DOM. Maybe it should log cases 
> where the DOM logic can recognize that there might be a problem, but I 
> think this is overall a tradeoff worth making. 
>
> But by the same argument, I think Elm programs would be better if the 
> runtime exception for function equality comparisons was replaced with a 
> false result even though it might actually be true. And if it's really 
> irksome, then it could generate a log statement as well. 
>
> Mark 
>
>
>
>

-- 
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] Re: Function equality again

[Kasey Speakman]

So what's the specific case where you need to verify function reference 
equality?

I suspect that needing this is a symptom of some other problem.

On Wednesday, October 12, 2016 at 11:48:12 AM UTC-5, Mark Hamburg wrote:
>
> As discussed elsewhere, the runtime exception related to function equality 
> comparisons is a lurking time bomb for code that is really only addressed 
> on a multi-developer project by being paranoid both about functions in data 
> structures and use of the equality operator. Both points of paranoia get in 
> the way of writing "good" code. There are other arguments around things 
> like serialization for avoiding using functions in some places, but there 
> are lots of other places where it is extremely useful to put functions in 
> data structures. (Imagine writing an effects manager if it couldn't store 
> functions in its data structures.) 
>
> Full equality tests are, as I understand it, undecidable. That doesn't 
> mean, however, that some limited analysis can't prove equality in most of 
> the conditions that matter. In fact, the existing code doesn't always throw 
> an exception. It only throws an exception if an "allocation identity" test 
> fails. One could extend this to looking at the "code pointer" and 
> allocation identity for the closure values and probably get many of the 
> remaining cases that mattered. It's just a matter of how far one wants to 
> push when trying to prove or disprove equality and I'm not arguing for a 
> particular limit here. 
>
> Rather, I think the central issue is around what happens when we give up. 
> At that point, there are two choices: throw a runtime exception as happens 
> now or return false. As mentioned above and discussed at further length 
> elsewhere, the runtime exception leads to paranoid coding. What are the 
> issues with returning false? The big problem with returning false is that 
> this means that some compiler optimizations might then change cases that 
> returned false without the optimizations into cases that returned true and 
> people become understandably uncomfortable with the possibility that 
> compiler optimizations could change the meaning of programs. And with that, 
> I've more or less wanted a "return false" answer but convinced myself that 
> throwing an exception wasn't unjustified and that maybe what we needed 
> instead was type system support to avoid the issue. 
>
> But then this morning's discussion of the virtual DOM had me realizing 
> that runtime optimizations around when the render-diff-patch algorithm gets 
> run create significant potential for variable program behavior. We embrace 
> these optimizations even though they introduce non-determinism. Now, its 
> non-determinism at the level of the physical DOM rather than the values 
> produced in Elm itself — i.e., runtime v linguistic non-determinism — but 
> its non-determinism in one of the most fundamental parts about how Elm is 
> generally used so that distinction seems somewhat arbitrary. 
>
> I think Elm makes the right call on the DOM. Maybe it should log cases 
> where the DOM logic can recognize that there might be a problem, but I 
> think this is overall a tradeoff worth making. 
>
> But by the same argument, I think Elm programs would be better if the 
> runtime exception for function equality comparisons was replaced with a 
> false result even though it might actually be true. And if it's really 
> irksome, then it could generate a log statement as well. 
>
> Mark 
>
>
>
>

-- 
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: Integrating Elm with Web Components / Polymer

[Peter Damoc]

On Wed, Oct 12, 2016 at 6:57 PM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

> This limitation means you can't have UI elements defined outside of a
> component affect its state. Suppose you had a video component and a video
> control bar compnent, you could not make those separate components, you'd
> always have to embed the control bar inside the video component.
>

To my understanding, Html elements are treated as stateless so, there is no
semantic to tell a certain Html element anything just like you cannot tell
the integer number 42 to do something. It's just data. It's not an object.

If someone wants to say something to the actual html element, they have to
give that element an ID in Elm and go to JS in order to give it a message.





-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
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] http "middleware" options

[Peter Damoc]

On Wed, Oct 12, 2016 at 6:50 PM, Fa Qing  wrote:

> Goal
> [AppRoot] -> [UsersPage] --> ask api for users, and upon success,
> 1. send the UsersFetchSuccess message (attaching the users); so far so
> good, but then also I need to...
> 2. replace the token by sending the BumpToken message at the root level of
> the app.
>


I would approach this by making UserFetchSuccess incorporate the token.

type Msg
= UserFetchSuccess Token UserData

and handle the bumping of the token afterwards by maybe extending the
update signature with a Maybe Token




-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

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

Element continuity (was Re: [elm-discuss] Re: Html.Keyed)

[Mark Hamburg]

On Oct 11, 2016, at 1:09 PM, OvermindDL1  wrote:
> 
> And as for cocoa, unlike the DOM anytime something like, say a checkbox is 
> checked, cocoa sends a message to the application to handle the change, if 
> unhandled then no update would happen... and the app would be frozen as the 
> event loop would not be processing, unlike the DOM in a browser that would 
> just keep on puttering along even if no handlers for any events were 
> registered in javascript at all.  They are entirely different programming 
> domains.

Actually, no, with respect to Cocoa. If a Cocoa view sends out a message that 
the value changed, the controller is not required or even expected to echo that 
change back. The message can disappear into the aether and the state will 
remain. (Caveat: It's been a while since I've coded against the Cocoa APIs.) 
So, it is essentially an identical situation of there being extra state that is 
tied to the existence of a Cocoa view object or a DOM element.

The problem this poses for all render-and-diff-based virtual DOM systems — and 
you are correct that React shouldn't be immune — is that the diffing algorithm 
has to infer when to keep using an existing element and when to create a new 
element. The only truly reliable way around that would be to require attaching 
unique identifiers to rendered nodes that the diff algorithm to use to 
recognize continuity and that's messy in broader practice (though see below). 
That said, that's exactly what Html.Keyed does so if there is a problem here it 
isn't in Html.Keyed but rather in the documentation around how the virtual DOM 
relates to the physical DOM and how in particular that plays out for Html.Keyed.

What should perhaps be more worrisome is that the render-and-diff algorithm can 
produce different results depending on how often we render. Render frequently 
and maybe an element goes away and then a new element gets created. Render 
infrequently and maybe the existing element gets reused. Html.Keyed can be used 
to work around this by using a new key to force creation but again 
understanding that work around takes understanding the relationship between the 
virtual and physical DOM at a deeper level than the documentation for Elm (or 
React?) tends to cover. (For those who are a bit performance obsessed, 
Html.Keyed also has the annoyance of introducing an extra div element, but 
that's just a niggle.)

The work on web components touches on this issue as well. The point to using 
web components is often to allow them to encapsulate private state but then we 
need to manage the lifetime for that private state.

This really comes down to a question of managing when the DOM diff algorithm 
should consider two elements the same and when it shouldn't. As noted, we could 
simply require that all elements have unique ID's and continuity would be based 
on ID equality but then we would have the problem of managing a global ID 
space. Not wanting to go there, let's look at what we've got available:

* Normal nodes manage their children positionally. This should argue for 
treating such nodes as always having a fixed set of children and the DOM diff 
algorithm could complain when they don't noting that changing the set of 
children introduces risks that the diff algorithm will make the wrong choice or 
will miss a change by not running often enough. (There are also risks if 
children change their kind because if the change is seen it will result in 
element destruction and creation and if it is not seen because the kind changes 
back, it will likely result in element reuse.)

* Keyed nodes manage their children based on keys. These work well for identity 
provided one understands the implications of that identity. Keyed nodes can be 
used for lists but also for forced destruction and creation of DOM elements.

What seems like it bears some further investigation is looking at more ways to 
use keyed nodes to manage non-homogenous lists, changeable lists of sub-views.

Another interesting point to investigate would be debugging tools that compare 
the number of elements created and destroyed depending on how often the 
render-and-diff algorithm is run.

Mark

-- 
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] http "middleware" options

[Wouter In t Velt]

Personally, I like the setup for as it is used in the time tracker SPA 
example (here) 
.

They have a separate file (Util.elm) with the following function:
cmdForRoute : Model -> List (Cmd Msg)

(This function is called inside the update function)
It generates a list of Cmd Msg.

inside cmdForRoute, various API functions are called.

The API is in a separate file, with specific functions for certain read or 
write calls, like: 
fetchProjects : Model -> (Http.Error -> Msg) -> (List Project -> Msg) -> Cmd 
Msg
fetchProjects model errorMsg msg =
get model "/projects" Decoders.projectsDecoder errorMsg msg

Each of those functions calls a more generic "get" or "put" function, which 
does the actual calls to server:
get : Model -> String -> JD.Decoder a -> (Http.Error -> Msg) -> (a -> Msg) 
-> Cmd Msg
get model path decoder errorMsg 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.

Re: [elm-discuss] Re: Integrating Elm with Web Components / Polymer

['Rupert Smith' via Elm Discuss]

On Wednesday, October 12, 2016 at 1:55:02 PM UTC+1, Peter Damoc wrote:
>
> I did however became aware of a big limitation to this approach: ports. 
>
> ports seam to be needed in order to implement triggering events in order 
> to communicate with the outside of the component. 
>

I'll have to correct you here. The event is triggered by using an on-event 
on the custom components html element:

onCountChanged : (Int -> msg) -> Attribute msg
onCountChanged tagger =
on "count-changed" <| Decode.map tagger detailCount

This is actually very neat, since ports are not needed.

But the port does need to be used to push the part of the state that the 
component wants to make public from the Elm program, into the component as 
javascript, so that it can trigger an on-event to pass it to the consumer 
of the component.
 

> This limits the usefulness of the method because it bans the components 
> from package.elm-lang.org. 
>
> what do you think about this?
>

I think eventually package.elm-lang.org has to figure out its process for 
bringing in new native stuff, but I understand the caution. Its not such a 
problem for me right now as I'm interested in building and consuming my own 
components, can push stuff out through github, and need to experiment with 
stuff a lot more before anything is really releasable.

-- 
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] http "middleware" options

[Peter Damoc]

On Wed, Oct 12, 2016 at 4:13 PM, Fa Qing  wrote:

> I'm just curious how everybody approaches their API service layer in
> complex applications.
>
> Right now, I have a shared API module that I call from various
> elements/pages/components/children... in a pretty flat architecture. That
> module abstracts out the common request composition, etc.
>

This is also what I had in my app: an API module that exposes a Cmd
producing interface to the rest of the app.

All API callers provide:
1. `success` and  `failure` message constructors
2. the auth_token (if needed)
3. the rest of the data required for the request

The extraction from the header and injection in the header can be
abstracted in some custom `get` and `post` functions.


Right now I have an Api.sendJson call that returns a task


This sounds like a good approach (similar to the custom `post` that I
mentioned earlier) but I would not expose this to the rest of the app.
I would use something like this internally to do the job.

In using my API module, I would always use only functions that produce Cmd
(I avoid using the tasks).
To give you an example. I had a User object that had a list of Companies.
The list is saved a set of IDs and to get the final Elm object I had to
first get the user data and then go through each of the IDs in the
Companies field and request the Company data for that company.
All these details are not the concern of the rest of the program. The rest
of the program just gets the final User with a list of Companies, nicely
wrapped in a message.
Internally to API, there are various functions that help with constructing
the final Task that first fetches the user and then fetches the rest of the
data but these tasks are not exposed outside the module.

If the database storage changes or I decide on another strategy, the rest
of the app is isolated from these changes because it talks in the higher
language of the API not in the lower language of the Http that the API uses
to implement the functionality.


-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
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] http "middleware" options

[Fa Qing]

I'm just curious how everybody approaches their API service layer in 
complex applications.

Right now, I have a shared API module that I call from various 
elements/pages/components/children... in a pretty flat architecture. That 
module abstracts out the common request composition, etc.

What I want is to also have that module (or some shared abstraction) that
1. extracts an incoming response header
2. injects an outgoing request header

Let's say that every response includes a dynamic "token" header value, and 
every request needs to return that token in the headers. This directly 
analogous to the need to let http errors "bubble up to the root," which was 
discussed elsewhere, but not effectively resolved.

Right now I have an Api.sendJson call that returns a task, then I convert 
it to a command with local messages. But ideally those local messages are 
handling the error, or else the locally relevant model. Looking only to the 
successful response, mixing the returned data with the updated value 
extracted from the header, and doing it at every api call site, seems 
inefficient and clunky. I think I might be missing something obvious. Could 
anybody recommend an elegant solution to having a common service module 
that could wrap the http calls in both directions (requests and responses 
... a la middleware) cleanly? Any help would be greatly appreciated.

-- 
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: Integrating Elm with Web Components / Polymer

[Peter Damoc]

Needing to set state on a component feels like an anti-pattern.


I did however became aware of a big limitation to this approach: ports.

ports seam to be needed in order to implement triggering events in order to
communicate with the outside of the component.

This limits the usefulness of the method because it bans the components
from package.elm-lang.org.

what do you think about this?



On Wed, Oct 12, 2016 at 3:34 PM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:

>
>
> On Tuesday, October 11, 2016 at 11:07:46 AM UTC+1, Rupert Smith wrote:
>>
>> On Monday, October 10, 2016 at 10:40:25 PM UTC+1, Peter Damoc wrote:
>>>
>>> Now, the next challenge is to figure a way to declare all this in Elm
>>> and automate as much as possible the process of creating the custom
>>> components. :)
>>>
>>
>> I think rolling these Elm web components by hand should continue for a
>> while until issues are ironed out and the pattern becomes well established.
>>
>
> So there is an issue with being able to change the state of the component,
> post initialization, from the consumer of the component. Because if there
> is a port used to set state on the component... which component?
>
> We set the port up for setting its value like this:
>
> app.ports.setCount.subscribe(count => {
> this.count = count;
> });
>
> I exposed this port in my API module, so the user of the component could
> call it:
>
> port module API exposing (counter, initialCount, onCountChanged, setCount)
> ...
>
> port setCount : Int -> Cmd msg
>
> Calling setCount from within the components program works, but calling it
> from within the consumers program? It does not have a way to know which
> component to 'setCount' on, if there was >1 of them on the screen.
>
> I'll try it.
>
> But this means that there is a limitation on what I can do with
> webcomponents so far:
>
> Can initialize state using attributes on the component, by
> serlizing/deserializing init data in and out of Elm.
> Can trigger events on the Component and on the Consumer.
> Cannot make a call from the consumer to set state on the component
> dynamically.
>
> Perhaps this limitation is even useful as it will tend to lead to
> component designs that are declarative as they have to be built up front
> and live independently after that.
>
> I can also see some evil way of doing this... also passing an id down the
> port, then using it on the other end to figure out which component to
> 'invoke the port' on. I suppose you could even pass javascript as a string
> down a port and run it on the other end so there are definitely going to be
> ways of overcoming limitations.
>
> --
> 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.
>



-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
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: Integrating Elm with Web Components / Polymer

['Rupert Smith' via Elm Discuss]

On Tuesday, October 11, 2016 at 11:07:46 AM UTC+1, Rupert Smith wrote:
>
> On Monday, October 10, 2016 at 10:40:25 PM UTC+1, Peter Damoc wrote:
>>
>> Now, the next challenge is to figure a way to declare all this in Elm and 
>> automate as much as possible the process of creating the custom components. 
>> :) 
>>
>
> I think rolling these Elm web components by hand should continue for a 
> while until issues are ironed out and the pattern becomes well established.
>

So there is an issue with being able to change the state of the component, 
post initialization, from the consumer of the component. Because if there 
is a port used to set state on the component... which component?

We set the port up for setting its value like this:

app.ports.setCount.subscribe(count => {
this.count = count;
});

I exposed this port in my API module, so the user of the component could 
call it:

port module API exposing (counter, initialCount, onCountChanged, setCount)
...

port setCount : Int -> Cmd msg

Calling setCount from within the components program works, but calling it 
from within the consumers program? It does not have a way to know which 
component to 'setCount' on, if there was >1 of them on the screen.

I'll try it.

But this means that there is a limitation on what I can do with 
webcomponents so far:

Can initialize state using attributes on the component, by 
serlizing/deserializing init data in and out of Elm.
Can trigger events on the Component and on the Consumer.
Cannot make a call from the consumer to set state on the component 
dynamically.

Perhaps this limitation is even useful as it will tend to lead to component 
designs that are declarative as they have to be built up front and live 
independently after that.

I can also see some evil way of doing this... also passing an id down the 
port, then using it on the other end to figure out which component to 
'invoke the port' on. I suppose you could even pass javascript as a string 
down a port and run it on the other end so there are definitely going to be 
ways of overcoming limitations.

-- 
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] Pattern matching on aliased types

[Wouter In t Velt]

Op dinsdag 11 oktober 2016 23:35:27 UTC+2 schreef Duane Johnson:
>
> toString is a bit magical in Elm, and can convert any type to a string.
>

Also note that if you apply toString to something that is already a String, 
it will add double quotes at the start and end.

-- 
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] Re: Another documentation item I think is needed

[Wouter In t Velt]

Op dinsdag 11 oktober 2016 23:36:49 UTC+2 schreef J. E. Marca:
>
> On first read I laughed out loud --- I don't know what <| does, and it 
> seems a random application of head and drop.  Reading closer, it *is* 
> straightforward as you say... drop first n items (one based count), then 
> get the next one (via List.head) and return that (which ends up being the 
> traditional zero based index count).  Clever, but not something I can come 
> up with on my own.  
>

Touché! my background is also in javascript (React + Flux). For me all the 
"|>" "<|" ">>" symbols where confusing at first as well. I guess I am 
already used to them :)
 

> Regardless, I wanted to *assign* to that element in the update loop, so 
> Array works better for me.  This is what I'm doing.  My view has a bunch of 
> buttons that onClick send a message and an index.  (The index value is 
> built into the html element via  Array.indexedMap).  
>

I pattern that I took with me from javascript as well is similar to your 
example:

   - Get one item from some collection (Array)
   - Apply a change function the item = make a new item
   - Put the new item back in the collection = make new collection with 
   updated item

But I ended up with a lot of "case someMaybe of" etcetera, and a lot of 
code lines.

What I do nowadays is different: pass an index + a change function to a 
collection, and get back the whole collection with the updated item in it.
Array.Extra 

 
has an Array.update function which allows you to do that.

Note however, that with Array.update, you do not know *if *an update has 
taken place, you just get the new Array back.
So the example below is slightly different from your original, because it 
will also call the getColorJson if the pvars did not change.
 
DetectorPlotVars ->
let
changePvars pvars = { pvars | on = not pvars.on }  -- 
local function that takes pvar and toggles "on" parameter

newArr = Array.update index changePVars model.detectorPlotVars

newModel = { model | detectorPlotVars = newArr }
in
( newModel
, getColorJson newModel 
)

-- 
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] control structure

[Eduardo Cuducos]

Hi Patricia,

Elm, as a functional language, doesn't have for and while as declarative
languages. There a lot of paradigms to have in mind: the sort of problem
loops address in declarative languages usually is addressed with recursion
in Elm and other functional languages (as Duane said).

IMHO a really good introduction to these new paradigms is this series of
articles
https://medium.com/@cscalfani/so-you-want-to-be-a-functional-programmer-part-1-1f15e387e536

Hope you enjoy and come back with more doubts ; )





Eduardo Cuducos
http://cuducos.me/

On Wed, Oct 12, 2016 at 8:29 AM, Peter Damoc  wrote:

> What do you need repetition for?
>
> If you give us some examples of what you are trying to achieve, maybe we
> can give you some examples of how that would look in Elm.
>
> If you want to process each element of a list, `map` is the best option.
> If you want to extract a sub list based on some criteria `filter` is
> needed
> If you want to create a value from a list (like adding all elements in a
> list of ints) then foldl or foldr are the functions to use.
>
>
>
>
> On Wed, Oct 12, 2016 at 12:44 PM, Patricia Nicole Benedicto <
> patriciabenedict...@gmail.com> wrote:
>
>> hi can i ask what is the repetiton control structucture of this
>> programming languages?
>>
>> --
>> 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.
>>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
> --
> 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] Re: Html.Keyed

[Max Froumentin]

Thanks OvermindDL1, that's very helpful. I now understand it's down to the 
lack of two-way binding. Makes sense.
Wouldn't it be useful to use a change of id attribute as a change of key?


On Tuesday, October 11, 2016 at 6:11:15 PM UTC+1, OvermindDL1 wrote:
>
> The ticked checkbox is because the user ticked it, it is some of the 
> implicit DOM state.  When the view changed to remove a checkbox but it 
> still had another one after, since they were not keyed it just did a 'diff' 
> between states.  The vdom has no information on any implicit state in the 
> actual DOM, in fact it does not access the actual DOM at all except to 
> apply patches, thus when it saw from its point of view that the checkbox 
> label had its name changed but nothing else different about it then it sent 
> a patch to change the text and that is all.  By changing the 'key' of it 
> then it knows that it is an entire tree change and will not even attempt a 
> patch but will instead rather re-generate the entire tree.
>
> Basically if a tree were to be regenerated just because some text changed 
> than that would make a virtual-dom extremely slow, its whole point is only 
> to generate a set of differences between two virtual-doms and apply those 
> differences to the real dom without ever reading anything from the real dom 
> (as that is very slow).
>
> It would indeed be preferable for checked-state to be controlled 
> exclusively via the model and view, however only an event is sent for those 
> changes and there is no way for the vdom to update its internal information 
> otherwise, and registering an event everywhere, even bubbled events, would 
> again make the vdom very slow and force the user to have to handle a lot of 
> extra cases (imagine checked state, text values, even focus and all being 
> controlled like this).
>
>
> On Tuesday, October 11, 2016 at 11:01:57 AM UTC-6, Max Froumentin wrote:
>>
>> Hi there,
>>
>> Today I raised https://github.com/elm-lang/virtual-dom/issues/37
>> Given there's no consensus on whether it's a bug, I'm bringing the 
>> discussion here.
>>
>> The reason why I think it's a bug is that the second time the view 
>> function runs it generates a ticked checkbox, although nowhere in the view 
>> function is there any indication that a ticked checkbox should be generated.
>>
>> The alternative view is that the checkbox that's been clicked on has only 
>> been mutated with new data. That's why it remains ticked. You need to use 
>> Html.Keyed to tell elm that it is an entirely new checkbox.
>>
>> I must say I'm not convinced why the view function should generate Html 
>> that depends on the previous state of the model.
>>
>> Thanks for any insight.
>>
>>

-- 
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] Re: Subscribe to a model value then call update function when condition is met

[Wouter In t Velt]

Op woensdag 12 oktober 2016 06:17:37 UTC+2 schreef hoang...@gmail.com:
>
> But if I do it this way, it's gonna return both the player's move and the 
> AI's move at the same time. What I want to have is that the game displays 
> the player's move THEN call minimax function on current model and THEN 
> display the AI's move
>

The recursive call still needs a separate Msg (AIMove) for the AIMove. This 
separate Msg is not needed: there is no outside event (user click or server 
or subscription) that calls this message. It is the update function itself 
(during processing of user moves) that calls this. So in that case, it 
would be better to use setup from Luke, to limit all Msg to outside events, 
and remove the AIMove message.

But it sounds like you want something else: you need 2 discrete model 
states (1 after player move, 1 after AI move), because you want *both model 
states to be displayed separately*.

And for that (as far as I know) you need the setup with subscription (+ 
some 'isProcessing' flag like OvermindDL1 suggested), and you also need to 
keep the AIMove message for the subscription command to call.

-- 
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] control structure

[Duane Johnson]

Recursion is the basic principle on which repetition is based in functional
languages like Elm. However, in most cases, recursion is not needed for day
to day programming, because functions such as List.map and List.foldr will
accept functions, and repeat the application of the passed-in function over
each element of a list. Does that help?

On Oct 12, 2016 6:52 PM, "Patricia Nicole Benedicto" <
patriciabenedict...@gmail.com> wrote:

hi can i ask what is the repetiton control structucture of this programming
languages?

-- 
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] Extracting and Injecting headers in an Http service helper/module

[Fa Qing]

I need to extract a header when an http response comes in, and inject a 
header when a request goes out. These headers are not specific to the lower 
level pages/modules/components/children...

I have an API module that formats requests, checks responses, extracts 
headers, etc. Currently I pass the header value to inject into the API 
module from each child who makes an API call, and receive back the 
extracted header value within each child API call, to pass those up to the 
root?

It's not so much the passing through the hierarchy at issue (it's a pretty 
flat hierarchy as it is) that concerns me. It's more about the coupling of 
concerns. I feel like I'm missing something.

What I want is hit an api, such as Api.sendJson modelToSend, which creates 
a task which is performed with the local messages such as 
(modelSendFailedMsg error) and (modelSendSuccess responseVal). But the 
coupling mentioned above means I have to do Api.sendJson modelToSend 
globalValueToInjectIntoHeader, and then coming back, rather than having a 
single task with local messages, I need a local task with the local model, 
and I need a global/root task to handle processing the extracted header 
values.

I have read the other related threads, but nothing stood out as a more 
cleanly architected solution. Has anybody come up with a more elegant 
solution for these global service layers?

-- 
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] Html/Svg -> String for data:-URI download?

[Alexander Klink]

Hi,

in elm-lsystems (see http://0x90.eu/ls/ and 
https://git.alech.de/alech/elm-lsystems/),
I render an inline SVG. I would like the user to be able to download this SVG, 
for
example by providing a link to a data:-URI of the content.

For this, I would need a function that converts the given Svg into a String, but
I couldn't find anything ... Ideas anyone?

Best,
Alex

-- 
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] control structure

[Patricia Nicole Benedicto]

hi can i ask what is the repetiton control structucture of this programming 
languages?

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