[elm-discuss] Re: Discovery: Model /= Database

[Eric G]

This topic is a bit all over the place, but just wanted to chime in with a 
different approach that I've found works pretty well for updating 
database-backed state, especially in contexts where you aren't syncing with 
the backend via websockets or similar.

That is to follow the principle: no database-backed state gets updated 
directly in the frontend app. Updates are made via *commands *to the 
backend (like an extension of Msgs to the backend, essentially). New state 
is always loaded from the backend, not from a cache (unless you need that 
and can deal with cache invalidation cleanly), preserving the 
unidirectional flow of state.  In this way, you can minimize the need for a 
'store', and never need to directly update data in the 'store' based on 
user input.  I think this may be related to what Kasey was saying 
originally.

Eric

On Sunday, April 30, 2017 at 3:31:49 PM UTC-4, Oliver Searle-Barnes wrote:
>
> The pattern we use is to have our Page.update functions return
>
> (model, cmd, storeCmd)
>
> the main update then applies the storeCmd to the Store. (the actual code 
> supports a few other things but that's the basic gist of it). Hit me up on 
> slack if you want to chat about it.
>
>
>
> On Sunday, 30 April 2017 08:45:49 UTC+2, Dustin Farris wrote:
>>
>> I think I've just had an aha moment with this post.
>>
>> I am in the process of refactoring my monolith MUV into separate modules 
>> with their own MUV for each "page" of my SPA.  Up to this point, I have had 
>> a separate Store module with its own Model and Msg types and an update 
>> function (no view, obviously).  This has worked well up until now, but 
>> after splitting off the pages of my app, it is getting more cumbersome to 
>> update the Store in a way that looks nice.
>>
>> e.g. in my Main.elm I'm ending up with something like
>>
>> update msg model =
>> case msg of
>> UserProfilePageMsg msg_ ->
>> let
>> ( userProfilePageModel, userProfilePageCmd ) =
>> UserProfilePage.update msg_ model.userProfilePage
>> in
>> case msg_ of
>> UserProfilePage.StoreMsg msg__ ->
>> let
>> ( storeModel, storeCmd ) =
>> Store.update msg__ model.store
>> in
>> { model
>> | userProfilePage = userProfilePageModel
>> , store = storeModel
>> }
>> ! [ Cmd.map UserProfilePageMsg 
>> userProfilePageCmd
>>   , Cmd.map StoreMsg storeCmd
>>   ]
>> _ ->
>> { model | userProfilePage = userProfilePageModel 
>> }
>> ! [ Cmd.map UserProfilePageMsg 
>> userProfilePageCmd ]
>>
>>
>> and so on for every page that invokes Store.Msg—which is most pages.
>>
>> I am thinking that there is a better way, and perhaps Kasey's suggestion 
>> of forgoing an in-memory Store on the Model might be it.  I'm still not 
>> sure—I do like the snappy feel of a page loading instantly if the data is 
>> in memory—even if it might change after a brief consultation with the 
>> server.
>>
>> Dustin
>>
>>
>> On Wednesday, April 19, 2017 at 7:28:06 PM UTC-4, Kasey Speakman wrote:
>>>
>>> I'm probably slow, but in recent months I've discovered that trying to 
>>> use Elm's Model like a database or cache (as I have previously seen 
>>> suggested) has turned out to be pretty painful for me. An example 
>>> database-minded model where a section could display *either* a list of 
>>> employees *or* a list of courses.
>>>
>>> type alias Model =
>>> { employees : List Employee
>>> , courses : List Course
>>> , loadingError : Maybe Http.Error
>>> , route : MyRoute -- employee or course
>>> }
>>>
>>> The problem this runs into is having to worry about state management. I 
>>> have to remember to "reset" or "turn off" things when they are not active. 
>>> As my application grew, I had a lot of problems that boiled down to tedious 
>>> state management details. My cached data didn't turn out to be all that 
>>> useful because I usually had to reload it anyway, in case something changed.
>>>
>>> Instead, I have been moving toward the model only representing the 
>>> current state of my UI. The big difference here is the model representing 
>>> the current *visual* elements and their data. This leads more to using 
>>> union types to represent parts of the UI. When you switch to a different 
>>> case of the union type, the data from the previous case is *dropped on 
>>> the floor*. This leaves nothing to remember to "reset". RemoteData is a 
>>> good micro-example of this. If there was an error fetching the data, when 
>>> the user requests the data again, you switch back to 

Re: [elm-discuss] Literature reviews repo

[Max Goldstein]

Why don't you open a PR and see what people think? :)

I'm also in favor of having a folder of sample apps to demonstrate the current 
best practice, and anything else that would be useful. 

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

[Kurt Mueller]

I really like this list. I would also like authorization discussed as well.

Kurt

On Monday, April 24, 2017 at 10:24:05 AM UTC-4, Peter Damoc wrote:
>
> Scaling. 
>
> Most successful Elm adoption approach has been the NoRedInk approach of 
> implementing bits of the UI in Elm. 
> This effectively creates a self contained Component that one can interact 
> with from some container framework (e.g. React). 
>
> There is however another path, a more dangerous path, where one starts 
> with Elm and stays in Elm as much as possible. 
> On this path there is very little assistance. 
>
> Here are some topics: 
>
> - structuring large apps 
> - using build managers with Elm (webpack, gulp, etc.) 
> - options around responsibilities (e.g. using Elm with CSS libraries like 
> Bootstrap via webpack & SASS loaders) 
> - managing routing
> - non-hash SPA routing
> - managing authentication
> - storage interfaces (interfacing the code with the databases with some 
> kind of Store construct) 
>   
> Besides these topics, you could also explore integrating external 
> libraries with Elm
>
> - implementing a command processor that allows an Elm app to interact with 
> a bunch of JS libraries though a single pair of ports. 
> - interacting with famous UI libraries like CodeMirror or Google Maps 
> - using web-components 
>  
>
>  
>
> On Mon, Apr 24, 2017 at 5:06 PM, 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...@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.

[elm-discuss] elm-dnd 3.0.0

[Ilya Beda]

Hi, all!

Today I have published version 3.0.0. of my drag and drop library. 
http://package.elm-lang.org/packages/ir4y/elm-dnd/3.0.0

It is ready for production usage and I would like to introduce it to you.
There is a complex example of the library usage (chess board) 
https://github.com/ir4y/elm-chess

I will appreciate your feedback.

-- 
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] Literature reviews repo

[Oliver Searle-Barnes]

That's great! 

People have been pretty responsive with calls for examples of code from 
existing projects, would it be worth adding a section to the template?


On Monday, 1 May 2017 17:48:48 UTC+2, Max Goldstein wrote:
>
> Here, I've set up a repo:
>
> https://github.com/elm-community/literature-reviews
>

-- 
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] Literature reviews repo

[Wojciech Piekutowski]

Great idea! What can be done to ensure that these efforts wouldn't go in
vain?

On 1 May 2017 at 10:14, Oliver Searle-Barnes  wrote:

> In https://groups.google.com/forum/#!topic/elm-discuss/yHiAJ_wcG3c Max
> proposes that we put together some literature reviews. If we're to
> collaborate on this effort we'll need to consolidate our investigations
> somewhere. Having seen the success of the RFCS repos for Ember
>  and Rust
>  I wonder if we could use a similar
> model. RFCs for those languages are in the business of proposing a concrete
> API (along with supporting evidence) but the structure of a literature
> review could be a template based around the questions Max posed.
>
> I believe this would give us an open process that the community can
> contribute to collectively. It would allow newcomers to the language to get
> an overview of what the community is thinking about (saving on the
> countless reruns of feature discussions we have in here) while providing a
> structure and focus that will provide Evan with the information that he
> needs.
>
> --
> 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] Literature reviews repo

[Noah Hall]

I suggest making this repo part of the elm-community org, if it is to be made.

On Mon, May 1, 2017 at 10:14 AM, Oliver Searle-Barnes  wrote:
> In https://groups.google.com/forum/#!topic/elm-discuss/yHiAJ_wcG3c Max
> proposes that we put together some literature reviews. If we're to
> collaborate on this effort we'll need to consolidate our investigations
> somewhere. Having seen the success of the RFCS repos for Ember and Rust I
> wonder if we could use a similar model. RFCs for those languages are in the
> business of proposing a concrete API (along with supporting evidence) but
> the structure of a literature review could be a template based around the
> questions Max posed.
>
> I believe this would give us an open process that the community can
> contribute to collectively. It would allow newcomers to the language to get
> an overview of what the community is thinking about (saving on the countless
> reruns of feature discussions we have in here) while providing a structure
> and focus that will provide Evan with the information that he needs.
>
> --
> 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] Ports seem contrived when trying to format a value as money

[Dwayne Crooks]

No I haven't. Thanks for sharing. I'll keep an eye on it but I doubt I'd 
add it to the project.

On Sunday, April 30, 2017 at 9:03:09 PM UTC-4, Dustin Farris wrote:
>
> Also, have you seen elm-plot?
>
> https://terezka.github.io/elm-plot/
>
> I haven't played with it yet, but it looks pretty neat.  Might help with 
> some of your features that used highcharts?
>
> Dustin
>
>
> Sent from my iPhone
>
> On Apr 30, 2017, at 8:10 PM, Dwayne Crooks  > wrote:
>
> I posted here as the other thread seems to be closed off from replies.
>
> For this particular app I'm writing/porting the SPA from scratch to Elm 
> and the formatting issue was the first small hiccup I ran into. As 
> suggested in the other thread I went ahead and wrote the code I needed in 
> Elm.
>
> Here it is in case anyone else is interested:
>
> module Format exposing (asMoney)
>>
>> asMoney : Float -> String
>> asMoney value =
>> let
>> totalCents = round (value * 100)
>> dollars = totalCents // 100
>> cents = totalCents % 100
>> in
>> "$" ++ (groupBy 3 ',' dollars) ++ "." ++ (zeroPad 2 cents)
>>
>> groupBy : Int -> Char -> Int -> String
>> groupBy per sep n =
>> let
>> pow10 = 10 ^ per
>> in
>> if n < pow10 then
>> toString n
>> else
>> zeroPad 3 (n % pow10)
>> |> String.cons sep
>> |> String.append (groupBy per sep <| n // pow10)
>>
>> zeroPad : Int -> Int -> String
>> zeroPad k n = String.padLeft k '0' (toString n)
>
>
> *P.S.* *Dustin, I decided to write one for myself. But thanks.*
>
> My next task is to draw some charts using Highcharts. I expect ports would 
> be the approach here so I'm crossing my fingers and hoping it all works 
> out. I certainly won't want to be re-writing parts of Highcharts at this 
> point.
>
> -- 
> 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.

[elm-discuss] Literature reviews repo

[Oliver Searle-Barnes]

In https://groups.google.com/forum/#!topic/elm-discuss/yHiAJ_wcG3c Max 
proposes that we put together some literature reviews. If we're to 
collaborate on this effort we'll need to consolidate our investigations 
somewhere. Having seen the success of the RFCS repos for Ember 
 and Rust 
 I wonder if we could use a similar 
model. RFCs for those languages are in the business of proposing a concrete 
API (along with supporting evidence) but the structure of a literature 
review could be a template based around the questions Max posed. 

I believe this would give us an open process that the community can 
contribute to collectively. It would allow newcomers to the language to get 
an overview of what the community is thinking about (saving on the 
countless reruns of feature discussions we have in here) while providing a 
structure and focus that will provide Evan with the information that he 
needs.

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