[elm-discuss] Re: 0.18 Chaining Http requests

[Dmitry Utkin]

I guess what you need here is 
Task.andThen 
http://package.elm-lang.org/packages/elm-lang/core/latest/Task#andThen

See this snippet I've found on 
github 
https://github.com/fpapado/elm-flickr-gallery/blob/c040f61575f4f47ce216df1820b42d1751ccdb7a/src/Main.elm#L56

Hope it helps.

On Monday, February 6, 2017 at 10:46:08 AM UTC+2, Kingsley Hendrickse wrote:
>
> Thanks
>
> I don't quite understand how to chain using Task
>
> I want to first do getCurrentUser Http request and then do 
> notifyOnLocationChange a regular task - but I can't understand how Task 
> could do this.
> Even chaining 2 http requests I don't understand since in order to fire a 
> Task you have use Task.perform or Task.attempt giving them the Msg - this 
> doesn't seem doable with Task
>
> getCurrentUser : Cmd Msg
> getCurrentUser =
>   Http.toTask (Http.get "/currentUser" decodeLogin)
>   |> Task.attempt CurrentUserResponse
>
>
> notifyOnLocationChange: Cmd Msg
> notifyOnLocationChange location =
>   Task.perform OnLocationChange (succeed location)
>
>
> any help appreciated 
>
>
>
> On Sunday, 5 February 2017 20:34:56 UTC, John Kelly wrote:
>>
>> Take a look at toTask: 
>> http://package.elm-lang.org/packages/elm-lang/http/1.0.0/Http#toTask
>
>

-- 
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: Do the counters in the Guide teach us a wrong scaling approach?

[Dmitry Utkin]

Josh, this is great! Thanks for this idea

Textfield.onInput <| ProjectMsg' << SetNewProjectName



On Monday, August 29, 2016 at 11:03:12 PM UTC+3, Josh Adams wrote:
>
> Here's what I've been working on.  The recent git history is all about 
> refactoring.  Haven't introduced 'sub-components with state' or w/e and 
> don't see it coming soon.  It's an Elm-SPA with a Phoenix backend: 
> https://github.com/knewter/time-tracker
>
> On Monday, August 29, 2016 at 11:37:10 AM UTC-5, Rex van der Spuy wrote:
>>
>>
>>> For newcomers to Elm, *wouldn't it be better to change the scaling from 
>>> 1 to multiple counters in the guide in a different way? *
>>> E.g.
>>>
>>>1. Build everything in 1 module, e.g. save a copy of counter.elm as 
>>>counter-list.elm
>>>2. Change every building block (Model, Msg, update, view) one at a 
>>>time, and upgrade each to handle multiple counters
>>>   - Suggested order: Model, view, Msg, update
>>>3. After that, separate out the view (and only the view) of an 
>>>individual counter, with signature like "msg -> msg -> Int -> Html msg"
>>>   - with the two msg's being for increment and decrement
>>>
>>>
>>>
>> I would love to know how to do this!
>> Can anyone point me to a brain-dead-simple practical and working example 
>> for a non-expert Elm user like myself?
>>
>> I, like Wouter, have modelled all the Elm apps I've built over the last 9 
>> months on the counter-list example - commonly nesting 3 layers deep.
>>
>>

-- 
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: Do the counters in the Guide teach us a wrong scaling approach?

[Dmitry Utkin]

Hi

On Sunday, August 28, 2016 at 2:02:04 PM UTC+3, Wouter In t Velt wrote:
>
> Something I have been struggling with for quite some time (coming from 
> React and Flux) is how to scale. There are various posts on this forum 
> related to the topic, e.g. Design of large elm apps 
> , parent 
> child communication 
> ,
>  
> components 
> 
> .
>

I'm struggling with this also, like most of us does. All of the approaches 
I've stumbled upon so far have their issues unfortunately.


> On structuring apps, I found the elm-sortable-table and the autocomplete 
> video - shared by Peter Damoc in this thread 
>  - 
> to be very helpful, as well as advice here 
> .
>
> My summary of the advice is more or less:
>
>- Forget about about "components": the term is very confusing, means 
>very different things in different contexts.
>- Start to build with 1 Model, 1 Msg, 1 update, 1 view
>- As soon as one these becomes too big, seperate that one out to a 
>view-helper, or update-helper etc
>
> This very much feels like a "top-down"  approach: the module you start 
> with remains on top. Put everything in there, and split out if needed.
> I keep reminding myself to stop trying to keep pieces of each of the 4 
> building blocks (Model, Msg, update, view) bundled as I separate out. That 
> it is fine to e.g. just put a piece of view code in a separate place - 
> *without 
> trying to bundle it with corresponding pieces of Model, Msg, and update.*
>

I'm not sure why all this `let's not call components "components"` thing 
started recently. I thinks it's perfectly fine to think in the terms of 
`components`, `widgets`, parent-, child- and all that stuff. Almost 
anything on a webpage can be named as a component, having child components 
and a parent component. It's natural to group and name those things this 
way, imho. Context matters, of course and it's OK.

The issue we have with terminology is `stateful components`(in OOP terms) 
vs `stateless components`. In React world, this is an issue since React 
components implemented as classes can contain state.
Elm nature tells us that there's not such thing as a `stateful Elm 
component`. So we always use this term without being misinterpreted - great!

So in the Elm world, component is a piece of code that
1) takes some props\params\input
2) generates html as a visible output to the input given
3) pipes the user-generated events up to the appropriate handler

In pre-0.17 world we had an easy way to pass the handler(signal address) 
down by providing some context to the `view` like this 

 
The simplest thing, like passing a callback in JS.
But nowadays(if we're going the fully-featured component path), we need to 
handle all of the events by generating a Msg, handling that Msg inside the 
`update` function of the component and then just return some kind of 
`OutMsg`(or `Dispatch` or `Whatever`) up to the parent.
If parent is not interested in this kind of event, but knows that his 
parent IS, it has to still has to convert it to some `ParentOutMsg` and 
bubble up the event to it's parent. Now *this* is the real issue that 
brings ideas like `stay flat for as long as you can` to life, imho.
 

>
> Now I am not sure that my take on "how to do stuff"  is the right way, but 
> it does seem that the *multiple-counters example in the guide teach us 
> exactly the opposite pattern*. 
> *Do the multiple counter examples in the guide put us on the wrong foot?*
>

Still waiting on this page 
 of the guide 
to update. Maybe Evan will come up with a nicer way to handle the wiring 
and Elm apps could be claimed to scale up easily.
I don't think the examples are bad because I'm not sold on the `stay flat` 
or `start flat` and the best argument against that idea is how clear and 
self-contained Conter.elm 

 is, 
and how easily it's being reused in two different apps in the `/nesting` 
folder.
 

>
> We start out with one counter being the top module, and then we add a 
> wrapper *on top* to handle multiple instances of this counter.
> To make matters worse: the multiple counter examples introduces the kind 
> of opaque nesting and messaging structure that is being discouraged here:
> The parent does not know anything about each child counter, parent has its 
> own Msg structure etc.
> After 

[elm-discuss] Re: How do you handle dependencies between updaters?

[Dmitry Utkin]

I've came up with solution very similar to Oliver's :)

Top `Page`(or `Screen`) update functions are getting the `Store` which is a 
top level app model. Alternative way is to have `mapToContext` function 
that receives some `Props` and `Store` and maps those to some useful 
context(it might be useful for both view and update functions, btw).

Each top-level `Page` update fn also returns an instance of `Action` that 
helps modifying the store.

On Monday, March 20, 2017 at 1:58:38 PM UTC+2, Eirik Sletteberg wrote:
>
> In larger Elm apps, it makes sense to divide Updaters so you can 
> package-by-feature.
> For example, a single page application could have updaters like this:
>
> - Configuration updater
> - Session updater
> - User Profile updater
> - User Settings updater
> - Content updater
> - Some other business specific updater
>
> The challenge is when there are dependencies between Updaters, for example 
> the User Profile model might need data from the Session model, the Session 
> updater might need to send messages to the User updater (Load user profile 
> when session is updated), or the Content updater may need to check for the 
> Session updater (get session ID to send as parameter to the API when 
> fetching content), or some business-specific updater may need to interact 
> with both the Content updater, the User updater, and the Configuration 
> updater.
>
> In Redux, one would use combineReducers to mount each reducer under its 
> own path, and then one can trigger actions across reducers. How would you 
> solve this in 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.

[elm-discuss] Re: Unsafe mechanism

[Dmitry Utkin]

Hi Oliver,

Your code sample looks very similar 
to 
https://github.com/eirslett/elm-task-port-example/blob/master/example/Main.elm

That's a repo related to proposal on adding `Task-based ports`. They were 
proposed more than once already, but I'm not aware of any opinion on the 
subject in the core team.

Having a tool like that would solve lots of issues with 3rd-party libraries 
interop.

This feature might be even better if we could get these new two-way ports 
with `Result err val` for sync operations and `Task err ok` for async 
operations.

> You're using a shared library now though so whenever you replace a 
javascript implementation with a safe Elm version everyone benefits.

I'm not sure that it's true if we take Firebase client as an example.
You can find *three *Firebase-related libraries on the graveyard of 
http://package.elm-lang.org/

I'd prefer to use the original JS library via ports. Having some kind of a 
wrapper library or even a pure Elm version of Firebase client that lacks 
support from the Google\Firebase company itself, might be abandoned by the 
author(s), lacks some features that I need... that's just much worse than 
wiring things up with ports, imho.

On Monday, March 13, 2017 at 11:06:44 AM UTC+2, Oliver Searle-Barnes wrote:
>
> (prompted by discussion of firebase integration on elm-dev)
>
> Given that it would be really helpful to have more integration libraries 
> available for Elm (auth0, firebase, aws...) I've been wondering if the 
> current state of affairs is ideal for achieving:
>
> 1) Maximum number of integration libraries available for Elm
> 2) All of those implemented in pure Elm
>
> Currently the path to get there appears to be:
>
> 1) Use an existing javascript library and wrap it using ports
> 2) Reimplement the library in Elm
>
> 1 to 2 often represents a significant amount of development. Because ports 
> preclude a library from being published in http://package.elm-lang.org/ 
> and elm package doesn't support installing them from anywhere else there's 
> a social pressure to not implement effect managers or release libraries 
> that make use of ports. 
>
> Another path get to pure Elm libraries might be
>
> 1) Use an existing javascript library and wrap it using ports or native 
> functions
> 2) Release it as a library
> 3) Gradually migrate the library over to pure Elm with the help of any 
> members of the community that need it
>
> The concern here is obviously that your Elm code can now blow up and 
> there's no way of knowing which code is unsafe. 
>
> What if unsafe because a first class concept in Elm? You could mark 
> functions as "unsafe". Any function that calls an unsafe function would 
> also be required to be declared as unsafe  e.g.
>
>
> unsafe attemptAuth : LoginDetails -> Task String AuthStatus
> unsafe attemptAuth loginDetails =
> Native.WrappedLibrary.attemptAuth loginDetails
>
>
>
>
> type Msg
> = unsafe AuthResponse (Result String AuthStatus)
>
>
>
> unsafe update : Msg -> Model -> (Model, Cmd Msg)
> unsafe update msg model =
> case msg of
> AuthResponse status ->
>
>
>
>
> This would make it possible to do a first pass on integration by just 
> delegating to the javascript implementation. It's now very clear which of 
> your Elm code is safe and unsafe. Having that unsafe keyword not only let's 
> you know which code carries the Elm safety guarantees (if a function isn't 
> marked unsafe) but you now also have this unsafe keyword stinking up your 
> code encouraging you to reimplement it in pure Elm. You're using a shared 
> library now though so whenever you replace a javascript implementation with 
> a safe Elm version everyone benefits.
>
> What do you think, does this offer a practical route to a greater number 
> of pure Elm integration libraries?
>
>
>
>
>
>
>
>

-- 
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: Poll for Intermediate to Advanced topics that people struggle with

[Dmitry Utkin]

- Interacting with 3rd party libraries that use DOM and have multiple 
event-related callbacks
- `Chaining` Cmds and Msgs
- Fighting the lack of interfaces while designing own data structures

On Monday, April 24, 2017 at 5:06:53 PM UTC+3, Jeff Schomay wrote:
>
> Hello,
>
> I am considering doing some training material on working with Elm in 
> production.  I want to focus on areas that people struggle with after they 
> are already familiar with Elm.  What concepts continue to confuse you? 
>  What product requirements have been difficult to achieve with Elm?  What 
> is most painful about your Elm codebase?
>
> Some topics I have already thought of:
>
> - decoders
> - debouncing (http autocomplete input field for example)
> - scroll to element
> - testing
> - unwieldy update functions
> - api design
>
> If you have anything you'd like me to consider, please add it to the list. 
>  Thank you!
>

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